【原创】RHEL7-PPTP-VPN-Server排错

第一次写博客，明显不知道如何下笔。

    昨天6月21日，突然发现往日运行一切正常的pptpvpn服务器怎么也连不上了，错误代码是619。这个错误代码以前并没有见过，于是上google查了一下资料，据说有几种可能：

1，路由器或防火墙干掉了tcp1723；

2，电脑协议栈问题；

3，拨号连接的认证选项有问题；

    由于服务器一直也没有改动，电脑之前连接都正常，那我猜测应该是被天朝墙掉了。既然如此，找朋友帮忙测试就能真相大白了，于是找了外地的朋友和外国朋友帮忙测试，然而结果却不容乐观：不仅外地的朋友619，外国的朋友竟然也是619，真是意料之外。这样的话，这几项可能都排除掉了，问题只可能出在服务器上，只好登陆服务器来查个究竟。

连上之后首先查看日志：tail /var/log/messages | grep ppp

Jun 21 12:54:40 ip-172-31-45-110 pptpd[4173]: CTRL: Starting call (launching pp                              d, opening GRE)

Jun 21 12:54:40 ip-172-31-45-110 pppd[4174]: Plugin /usr/lib64/pptpd/pptpd-logwt                             mp.so loaded.

Jun 21 12:54:40 ip-172-31-45-110 pppd[4174]: pptpd-logwtmp: $Version$

Jun 21 12:54:40 ip-172-31-45-110 pppd[4174]: The remote system is required to au                             thenticate itself

Jun 21 12:54:40 ip-172-31-45-110 pppd[4174]: but I couldn't find any suitable se                             cret (password) for it to use to do so.

Jun 21 12:54:40 ip-172-31-45-110 pptpd[4173]: GRE: read(fd=6,buffer=611860,len=8                             196) from PTY failed: status = -1 error = Input/output error, usually caused by                              unexpected termination of pppd, check option syntax and pppd logs

    节选报错如上：果然认证失败，说没有合适的认证方式。但是查看配置文件之后发现配置与正常运行的时候并无二致。难道是进程出的问题？遂重启进程，然而并没有什么卵用，依然是619。经过完整的检查后，配置全部一切正常。

    这可真是出了奇了，一怒之下只好重启服务器试试。但是即使整机重启了，再拨号依然是错误619。这下可有点束手无策的感觉了。但是这事不能就这么了了啊，咱的解决这个问题，虽然机器是自己的，但毕竟还有别人在用呢。

    重新整理思路，想到了一点：身份验证的时候是要用到chap-secrets文件来检查用户名密码，而文件里的内容都好好的保存着，日志里却说不能找到任何合适的密码，会不会是文件访问出现了问题？

于是stat /etc/ppp/chap-secrets一看，果然发现了怪异：

[root@ip-172-31-45-110 ppp]# stat chap-secrets

  File: ‘chap-secrets’

  Size: 290             Blocks: 8          IO Block: 4096   regular file

Device: ca02h/51714d    Inode: 17588514    Links: 1

Access: (0600/-rw——-)  Uid: (    0/    root)   Gid: (    0/    root)

Context: unconfined_u:object_r:user_tmp_t:s0

Access: 2016-06-19 13:41:01.975812200 -0400

Modify: 2016-06-19 13:41:01.975812200 -0400

Change: 2016-06-19 13:41:01.977812153 -0400

 Birth: –

    这个文件的访问时间竟然还停留在19号，而今天已经是21号，怪不得pptpd进程一直讲没有合适的密码，这个文件根本就访问不到！但是为什么呢，仔细回忆之前的操作，19号那天我使用vpnuser del命令删除了一个用户名。（在后面的实验中也验证了确实是这条命令导致的）

    故障原因找到了，开始着手处理了，我也不知道应该怎么解除这个不能访问的状态，于是直接删除并重新创建了一个chap-secrets文件在ppp下。重新拨号测试，一切恢复了正常。

    vpnuser应该是一个可执行文件（cat之后显示是乱码），这样的话应该是它占用了chap-secrets导致它不能被pptpd访问，但是为什么重启了也不能解决，难道是文件属性被修改了？于是再次使用vpnuser 测试了一下，发现chap-secrets的文件属性由-rw-r–r–.变成了-rw——-.。这应该是说只有文件的所有者root才可以读取这个文件，群组和其他人都没有权限读取。但是ps -aux查看出pptpd就是由root所运行，这就比较奇怪了。另外vpnuser这个命令为何会修改读取权限，也是一个未解之谜。

    以下是测试，确实权限变了：

[root@ip-172-31-45-110 ppp]# stat chap-secrets

  File: ‘chap-secrets’

  Size: 290             Blocks: 8          IO Block: 4096   regular file

Device: ca02h/51714d    Inode: 8828791     Links: 1

Access: (0644/-rw-r–r–)  Uid: (    0/    root)   Gid: (    0/    root)

Context: unconfined_u:object_r:pppd_etc_t:s0

Access: 2016-06-21 13:37:38.754584806 -0400

Modify: 2016-06-21 13:37:38.754584806 -0400

Change: 2016-06-21 13:37:38.754584806 -0400

 Birth: –

[root@ip-172-31-45-110 ppp]# vpnuser add 1 1

[root@ip-172-31-45-110 ppp]# stat chap-secrets

  File: ‘chap-secrets’

  Size: 298             Blocks: 8          IO Block: 4096   regular file

Device: ca02h/51714d    Inode: 8828791     Links: 1

Access: (0600/-rw——-)  Uid: (    0/    root)   Gid: (    0/    root)

Context: unconfined_u:object_r:pppd_etc_t:s0

Access: 2016-06-21 13:37:38.754584806 -0400

Modify: 2016-06-21 13:39:51.623464409 -0400

Change: 2016-06-21 13:39:51.624464386 -0400

 Birth: –

    运行pptpd的用户也是root：

[root@ip-172-31-45-110 ppp]# ps -aux| grep pptpd

root      4277  0.0  0.0  10672   744 ?        Ss   12:59   0:00 /usr/sbin/pptpd