WINCE+聯(lián)通3G撥號+vpn+撥號經常ping不通內網IP問題

WINCE+聯(lián)通3G撥號+vpn+撥號常常ping不通內網IP問題

備注：這里的VPN網關，也就是vpn服務器，是個硬件專用vpn裝備，是網御星云裝備Power V6000，下文個別IP擔心涉密，去除掉其中1部份

在此之前還遇到WINCE連接不上vpn裝備問題，見《WINCE6.0基于PPTP的VPN連接網御星云裝備Power V6000問題》

1. 問題

WINCE手持機聯(lián)通版本采取的模塊是SIM5360，WINCE和vpn服務器都是基于PPTP協(xié)議，先是WINCE手持機這邊3G撥號成功后，WINCE的vpn客戶端連接到VPN網關(也就是VPN服務器)，然后ping客戶內網的Web網絡服務器，下面是網絡拓撲圖

圖1

VPN網關前有個路由(VPN網關有專門的業(yè)務封裝，路由只是轉發(fā)尋址),這里VPN網關有兩個網卡，1個對內網(有個內部IP，這里是10.XXX.XXX.114)，1個對外網(有個外部IP，這里是60.XX.XX.XXX)

我們聯(lián)通3G版Ping不通客戶的web服務器，同臺機器用WIFI就能夠，但用同1張聯(lián)通3G卡在anroid手機或是我們C4050上是正常連接和ping通的，另外我們WINCE電信版本(模塊是SIM6320C)好很多，雖然也有ping丟包的，但不會出現(xiàn)大部份時間ping不通的情況。

還有個差異，還是WINCE聯(lián)通3G版本連接其他vpn服務器，ping對應的內網IP，雖然偶爾也存在ping丟包情況，但不會出現(xiàn)常常ping不通的情況。

綜合這些現(xiàn)象，問題還是WINCE聯(lián)通3G版本和客戶的vpn服務器兼容性不太好。

2. 問題的排查進程

2.1 vpn服務器的排查

ping包的流程:

(1) 手持機封GRE包--->VPN網關

(2) VPN網關解封裝，還原ping包

(3) VPN網關把ping包轉發(fā)給目的地址

VPN服務器抓取數(shù)據(jù)包，還原的正常的ping包是這樣：

10.X.X.114--->10.X.X.102

10.X.X.102--->10.X.X.114

Ping不通時的ping包是這樣：

192.X.X.10(手持機IP)--->192.X.X.1

192.X.X.10--->192.X.X.1

再后來測試有時候都抓不到這個數(shù)據(jù)包。我們ping的IP是10.X.X.102，但ping不通情況顯示是192.X.X.1，被變址了。抓取到這個變地址的包也有多是其他人在用，畢竟環(huán)境上不是我們1臺機器，收不到正常的ping包這個是肯定的

也就是說還原后的ping包目的地址是毛病的，從而判斷是手持機發(fā)出的目的地址是錯的。但為何是錯的呢？緣由不清楚，vpn裝備廠家建議我們聯(lián)系3G模塊廠家，看是否是3G模塊這邊發(fā)出去的數(shù)據(jù)包本身就有問題。

根據(jù)我們自己的討論，基于“手持機-- 3G撥號上網  ---  代理VPN   ---  內蒙路政VPN ，最好這個代理VPN是聯(lián)通的”這樣的思路驗證下，可用狂風VPN代理服務器，新注冊用戶能提供1個小時的VPN測試地址和賬戶，但是用手持機沒法連接VPN，但android可以。

2.2 3G模塊廠家的分析

我們的3G聯(lián)通模塊是SIM5360，在WINCE裝備用DiagGrabPro工具抓3G模塊發(fā)出去的數(shù)據(jù)包，這個數(shù)據(jù)包需要廠家解包采取wireshark分析數(shù)據(jù)包

圖2

上圖抓到3G模塊發(fā)出去的ping包進程，這是ping通情況的，ping 10.X.X.102都被壓在vpn包里，只能看到裝備ip和vpn網關60.X.X.X交互。

根據(jù)王工抓3G模塊發(fā)出去的包分析，認為發(fā)出去的時候ping目的地址也是錯了，斟酌到3G模塊只是作為鏈路層不會對協(xié)議進行處理，所以建議我們查WINCE送到3G驅動之前的數(shù)據(jù)包是否是就有問題了。

SIMCOM研發(fā)王工用SIM5360和4G模塊開發(fā)測試結果

4G模塊+電信卡（找到電信4G LTE網絡）+客戶的VPN賬號 ----vpn可以登錄成功
4G模塊+電信卡（找到電信3G EVDO網絡）+客戶的VPN賬號 ----vpn可以登錄成功
4G模塊+聯(lián)通卡（找到聯(lián)通 LTE網絡）+客戶的VPN賬號 ----vpn可以登錄成功
4G模塊+聯(lián)通卡（強迫設成3G模式，找到聯(lián)通 3G WCDMA網絡）+客戶的VPN賬號 ----vpn登錄失敗
3G模塊+聯(lián)通卡（找到聯(lián)通 3G WCDMA網絡）----vpn登錄失敗

2.3 WINCE裝備真?zhèn)€分析

在抓WINCE網絡logo之前，我們先來看ping包是否是沒有到達目的節(jié)點(基于IT部門的建議)，在ping通情況下，WINCE端通過命令行tracert 10.X.X.102來確認從手持機到目的地經過的路由信息就兩個節(jié)點

ppp_peer10.X.X.114

10.X.X.102

Ping不通情況下：

圖3

也就是路由不到，再次tracert，路由到下面信息：

圖4

路由到的是192.168.255.74(本地局域網)和61.50.245.5(北京市通州區(qū) 聯(lián)通)，我們客戶是在內蒙古調試，為何回路由到北京聯(lián)通呢，由于采取的是北京本地卡。但沒有到內蒙古的VPN網關。

下面對Ping不通的情況，進行詳細測試：

(1) Ping不通的情況下，tarcert 10.X.X.102看路由表

ping 102不通的時候，第2次tracert 114 現(xiàn)象還是以下：
1  *      *       *   Request time out 
2                       192.168.255.170
3                       61.50.250.217
4 *   　*    ＊　　Request time out 
５ *   　*    ＊　　Request time out 
６ *   　*    ＊　　Request time out 
．
．
30 *   *   *　　Request time out　

61.50.250.217是北京聯(lián)通IP 

(2) Ping不通的情況下，tarcert 10.X.X.114看路由表

tracert 114 現(xiàn)象還是和之前1樣，以下：
1  *      *       *   Request time out 
2                       192.168.255.170
3                       61.50.250.217
4 *   　*    ＊　　Request time out 
５ *   　*    ＊　　Request time out 
６ *   　*    ＊　　Request time out 
．
．
30 *   *   *　　Request time out　

(3) Ping不通的情況下，tarcert 60.X.X.94看路由表

圖5

在102ping不通的情況下，60.X.X.94是可ping通的

根據(jù)上面tarcert的分析，ping包到到不了VPN網關內網卡IP地址10.X.X.114(見圖1)。是甚么緣由呢？還是不清楚，看來只能分析WINCE送到3G驅動之前的數(shù)據(jù)包了。

WINCE實現(xiàn)抓包，必須添加對應的組件NDIS Packet Capturing DLL，以下；

圖6

抓包步驟以下：

(1) wince cmd命令下面運行 netlogctl start

(2) ping ip地址，然后查看“我的裝備”根木下面會多1個文件netlog0.cap，這個就是數(shù)據(jù)包log.

(3) ping完成以后要運行netlogctl stop命令停止抓包

(4) 在電腦上用ms network monitor 解析.cap文件就行。

根據(jù)抓包，我們發(fā)現(xiàn)3G撥號連接成功后，如果3G撥號成功分配的IP(通過ipconfig可查看)只要是172開頭的就能夠ping，但如果是10開頭的絕大部份是沒法ping通，就算可以ping通也非常不穩(wěn)定，為何呢(注意了，我們要ping的目的地也是10開頭)？而電信3G連接成功后分配的都是1開頭。難道10開頭的就有問題嗎？我們用windows+SIM5360開發(fā)板驗證，10開頭也能夠。那為何下WINCE下就大部份不行呢？

我自己料想，是否是聯(lián)通給手持機分配的地址是１０的時候，ｗｉｎＣＥ會誤以為和10.X.X.102是同1個內網地址，就不按VPN走了，所以致使出錯

根據(jù)測試和WINCE端抓包分析以下：

(1) 3G獲得聯(lián)通ip為172段的，vpn連接成功，ping10.X.X.102比較正常

(2) 3G獲得聯(lián)通ip為10段的，vpn連接成功，ping10.X.X.102 這邊測試沒見過Ping通的，抓包分析，此時使用3G的ip給10.X.X.102發(fā)包，感覺是繞過了vpn連接直接發(fā)包。

這類情況有兩種可能：1種是vpn連接已斷(但并沒有提示端)，另外一種多是wince發(fā)現(xiàn)目標地址是10開頭，本地3G連接也是10，認為是局域網，繞過vpn直接發(fā)。這也解釋了上面用的北京的卡，先找到的聯(lián)通網關的現(xiàn)象。

那為何windows和android可以，WINCE不行呢？很有多是WINCE的bug，而windows規(guī)避了這個問題，看相干描寫：

圖7

3. 目前問題的解決

主要方向明確了，怎樣解決呢？我們找到1篇博文《在Window Embedded CE(Wince)下使用OpenNETCF進行路由表的開發(fā) 》，給我們很大提示，根據(jù)里面提供的思路

http://www.cnblogs.com/procoder/archive/2009/12/23/Windows-Embedded-CE-Routing-Table.html

根據(jù)里面提供的思路

圖8

開發(fā)了1個程序，原理是：找到0.0.0.0的默許路由，且interface是192開頭，把前面兩列替換成10.0.0.0 和255.0.0.0，同時把開消置成1，保證比默許的小，然后增加到路由表中。把10.0.0.0的路由指定有vpn的連接走，開消設置成1，比他下面那1條10.0.0.0的小，要ping的地址10開頭，其實就10.0.0.0的那條起作用

同時根據(jù)1位朋友的反饋“看來3G撥號跟PPPOE撥號1樣的BUG啊。PPPoE也要自己家路由表”

windows本地連接的DNS和VPN連接DNS的優(yōu)先級

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈