第一次写博客，明显不知道如何下笔。
昨天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一看，果然发现了怪异：
[[email protected] 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这个命令为何会修改读取权限，也是一个未解之谜。
以下是测试，确实权限变了：
[[email protected] 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: - [[email protected] ppp]# vpnuser add 1 1 [[email protected] 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：
[[email protected] ppp]# ps -aux| grep pptpd root 4277 0.0 0.0 10672 744 ? Ss 12:59 0:00 /usr/sbin/pptpd
如果有大神知道原因，还请不吝赐教！