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


        昨天6月21日，突然发现往日运行一切正常的pptp***服务器怎么也连不上了，错误代码是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号那天我使用***user del命令删除了一个用户名。（在后面的实验中也验证了确实是这条命令导致的）


        故障原因找到了，开始着手处理了，用chmod修改一下权限，添加所有用户的读取权限。重新拨号测试，一切恢复了正常。


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


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

[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]# ***user 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

   如果有大神知道原因，还请不吝赐教！