第一次寫博客，明顯不知道如何下筆。
昨天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
原創文章，作者：lichenhan，如若轉載，請注明出處：http://www.www58058.com/19290
