使用ipsec和xl2tpd搭建好vpn后，使用ipsec密鑰方式不能連接，顯示 “連接的時候被遠程服務器中止”
使用xl2tpd -D查看連接情況，嘗試連接了許多次，錯誤如下：
開始不確定問題所在，查看ppp連接日志:
/etc/ppp/option.xl2tpd中增加一行：
logfile /var/log/xl2tpd.log
重新在win10上面連接vpn，發現日志出現許多如下字符：
auth chap ms-v2
后來發現可能是協議的問題
在/etc/ppp/options.l2tpd增加+mschap-v2即可，增加后，重啟ipsec，即可連接成功。
以下為轉載資料：http://www.gpxz.com/diannao/hulianwang/432244.html
15 PPP認證、壓縮和加密
IPsec被用來開L2TP隧道，L2TP在運行時開PPP隧道。PPP有幾種認證法子。最常用的是PAP（不加密口令）和CHAP（基於認證的挑戰/回應）。你可以自由地選擇兩者，最好是CHAP。如果你用PAP，Windows客戶會提示口令沒有加密。這有點離題，IPsec已經加密了。 PAP和CHAP都是IETE標准，但微軟收購並增強了CHAP，推出一一個新的MS-CHAP（最近斷定為MS-CHAPv2）。
默認情況下，Windows客戶會使用MS-CHAP進行PPP認證。問題是大多數發行版包含的PPP服務不支持MS-CHAP，比如 Red Hat Linux 9或更早的版。一個解決法子是配置每個Windows客戶使用CHAP。另一個解決法子是更新pppd到包含MS-CHAP (v2)的2.4.2或更高版本。如果你連接一個不支持MS-CHAP的服務器，客戶端配置為使用MS-CHAP，pppd將會提示 “auth chap 81”和“peer will not authorize”。一但你安裝一個支持MS-CHAP的pppd，你需要在 /etc/ppp/options.l2tpd增一行（根據你的pppd版本，參照man pppd）：
+mschap-v2
或者
require-chapms-v2
使用PAP或(MS-)CHAP最容易的法子是一個口令文件（secrets）。口令文件指定為/etc/ppp/chap-secrets或者 /etc/ppp/pap-secrets（分別對應於PAP還是CHAP/MS-CHAP）。當用戶數量較多而更為繁雜的情況下，你也許會尋找更為靈活的東西。這是來自文檔（畢竟它是PPP出版）的一小部分，但是這有多種可能的解決方案：
在l2tpd.conf中使用“unix authentication”關鍵字。賬戶名和口令將依靠Linux用戶數據庫（/etc/passwd）來檢查。為PPP選項增加“login”關鍵字后會它會做什么。記住，你最好使用PAP，因為(MS-)CHAP不能使用保存在/etc/pssswd文件中的預加密用戶口令。賬戶名仍由/etc/ppp/pap-secrets指定，但是在這個文件中口令為空字符串（“”）時，pppd使用Unix口令。參見：man pppd。
pppd2.4.2以上版本包含了RADIUS插件（radius.so，radattr.so），允許你依靠RADIUS服務對用戶進行認證。在有利用RADIUS和MySQL的安裝示范。他們使用pppd，同樣也適用於L2TP。
pppd2.4.3及以上版本包含了一個由Samba小組的Andrew Bartlet供給的winbind插件(winbind.so)，它供給依靠Samba或Windows域控制器使用MS-CHAP或MS-CHAPv2對用戶認證的能力。Andrew發布了安裝文檔：http: //hawkerc.net/staff/abartlet/comp3700/final-report.pdf。
多數ppp守護進程目前編譯時都有PAM支持。這意味着你可以使用所有的認證機制來認證。例如：插入上面提到的winbind插件，你可以用像 pam smb（包含pam_smb_auth）、pam_winbind或pam_ntdom（已經停止）的模塊依靠Samba或Windows服務器認證。還有，你可以用pam_ldap來依靠LDAP服務認證。
在/etc/ppp/options.l2tpd中指定noauth，你就可以完全忘記PPP認證。它可以在任何版本的pppd上工作，因為它不再要求客戶進行PPP認證（當然客戶仍然有IPsec認證）。但是，這還算是一個比較猛烈的解決辦法。你不應該簡單地省去PPP認證，盡管它不會對整個安全增強多少。
微軟也開發了MPPE，一種PPP加密協議。它基於RSA安全體系RC4加密算法，並且被用到了PPTP中。通常，你不要想使用MPPE與 L2TP/IPsec結合使用，因為它意味着IPsec和MPPE雙重加密。有時Windows客戶想強制使用MPPE。如果那樣的話，在那些 Windows客戶上禁用加密。這可能把用戶搞混。他禁用MPPE加密，認為根本沒有任何加密，IPsec已經供給了加密，但是用戶大概不會知道這些。一些Windows客戶也支持壓縮。你注意，這是PPP壓縮，不是IPsec壓縮（IPCOMP）。微軟使用的壓縮協議(MPPC)是有專利限制的。如果你仍想使用MPPC，參考配置一個LINUX PPP服務器()。
16.1 安裝和配置PPP（LINUX）
一旦L2TP連接啟用，它將控制權移交給PPP守護進程。明顯地，你需要一個PPP服務。幾乎每個發行版都有一個pppd。安裝一個最新的版本，比如2.4.1或更高。另外，相同的PPP軟件也可以用來做點別的事情（比如：用於撥號連接的模擬調制解調器）。幸運的是，你可以在l2tpd.conf 文件中用pppoptfile參數來為L2TP守護進程指定一個單獨的PPP選項文件。
注意：PPP守護進程的口令共享給所有PPP進程，不僅僅是l2tpd啟動的那個。可是，你可以限制用戶名/口令的有效性到某些IP地址，就像這個chap-secrets示例文件那樣。
# Secrets for authentication using CHAP
# client server secret IP addresses
jacco * "mysecret" 192.168.1.128/25
* jacco "mysecret" 192.168.1.128/25
sam * "rumpelstiltskin" 192.168.1.5
* sam "rumpelstiltskin" 192.168.1.5
每個用戶都有兩個入口，兩端的認證。在這種情況下，用戶jacco將從像/etc/l2tpd/l2tpd.conf文件中指定的l2tpd的 IP地址池（在示范配置文件中是192.168.1.128——192.168.1.254符合192.168.1.128/25） 獲得一個地址。用戶 sam總是從PPP服務獲得192.168.1.5。這是一種給用戶在你的內部局域網上的固定虛擬地址的法子（它看起來能工作，但是不能100%確認在任何情況下都能工作）。如果你不想在IP地址作任何限制，你可以使用通配符“*”來代替IP地址（不推薦這樣，因為它會允許用戶自己斷定自己的地址，有一定的風險）。
微軟客戶端有一個選項“登錄到Windows”如果啟用它，客戶端嘗試用“DOMAINNAMEusername”驗證。另外，你還可以在chap-secrets或者pap-secrets文件中指定這個用戶名款式。
關於解決如何配置PPP服務器這個主題的資料很多，如PPP Howto（）。
簡單點，我們假設你的Linux服務器外網接口是eth0，並且內網接口是eth1。PPP服務允許遠程用戶用一個內網的IP地址，一旦用戶連接上，ppp0介面將會自動啟動。l2tpd.conf中有一行“local ip”，用這個參數指定內網的一個固定IP地址供L2TP守護進程使用。
你看到的PPP選項文件示范那樣（/etc/ppp/options.l2tpd），你也可以指定DNS和WINS服務器，當連接成功后，遠程客戶將會自動獲得這些參數。一般情況下，你應該為遠程客戶指定的DNS/WINS就像直接連接的內網客戶一樣。可是，Windows 2000/XP自己的L2TP/IPsec客戶端好象只支持獲這些DNS/WINS服務器（當它的Internet連接配置為動態IP地址時）。
注：options.l2tpd包含proxyarp參數。這個參數將在內網接口（示例中的eth1）為遠程用戶打開一個代理ARP入口。如果這個關鍵字沒有指定，Windows客戶端發出的數據包將到達內網服務器，但這些服務器不知道向哪兒發出回應，因為沒有人回答它的ARP請求。用 proxyarp參數，內網機器被到遠程Windows客戶到網關發送進來的數據包欺騙。網關讓IP繼續向前，因此它知道如何發送數據到Windows客戶端。
16.2 MTU問題
你的VPN連接有斷斷續續的問題，它可能是一個MTU問題。你大概會看這樣的問題：你可以ping內網的機器，並且你可以復制非常小的文件，但是你不能復制大文件，因為連接中斷。試着在/etc/ppp/options.l2tp文件中增加以下幾行減少MTU到1410（或許更低）。
mtu 1400
mru 1400
當你的連接通過VPN到用broken Path MTU Discovery站點時，這個問題可能特別明顯。大概用PPTP或PPPoE的 ADSL連接同樣有這樣的問題。如果認證成功前連接失敗，減少PPP數據包的大小是沒有用的。試着使用更小的證書或不使用被NAT的連接。
FreeS/WAN的郵件列表中有一些討論，FreeS/WAN小組寫到：“可以在ipsec.conf的配置安裝用一節用 overridemtu=參數改變MTU。”一般情況下，這個參數僅支持KLIPS，不支持26sec。其它的提有，減少你的證書大小（短姓名，更少的 X.509v3選項等），或用IPCOMP壓縮。你也可以試着強制你的以太網接口使用一個更小的MTU：ifconfig ethx mtu 1400。
Cisco也有關於這一問題的一些文檔。微軟知識庫中的Q314053解釋了如何為一個指定的適配器設置MTU。
17 再次開始L2TP/IPsec連接
到這里，你已經配置好了IPsec、L2TP、PPP，在Windows或Mac客戶端再次開始VPN連接，這個過程和上邊的一樣，但這一次 L2TP連接應該正常啟動，如果成功了，祝賀你，你獲得了一個成功的L2TP/IPsec配置。如果它不成功，檢查你的設置，也可以看下面的“檢查並修理故障”。
有兩種比較好的檢查辦法：
1、在客戶端和服務器之間放一台計算機，你可以用這台計算機靠tcpdump或Ethereal這樣的網絡監視程序來sniff客戶端和服務器之間的通信。數據包必須被加密，如果你看到未被加密的數據包（舉例來說，出現文本“L2TP”），說明你的設置有問題。
2、在客戶端使用nmap或其它更好的端口掃描工具來掃描服務器上開放的端口（用法：nmap –sU 123.123.123.123），你不應該能看到L2TP守護進程（UDP 1701），打開的端口應該只有IKE（UDP 500）和隨意的UDP端口，比如4500（NAT-T）。
18 對L2TP/IPsec的一些評論
在第一次測試期間，我忘了在Windows工作站的TCP/IP配置里輸入默認網關和主機名，對於Linux服務器在本地網絡來說真的不是一個問題，可是當我從Windows客戶端向Linux服務器發起一個連接時，l2tpd在/var/log/message里提示一個有點模糊的錯誤信息 “Specify you hostname”，最初我想大概是l2tpd不能探測到正在運行的Linux服務器的主機名，我在Windows工作站里輸入主機名后這個問題解決了，我只是簡單地認為l2tpd不需要它。
19 NAT-Traversal
19.1 緒論
在客戶端和IPsec服務器之間有時需要網絡地址轉換（NAT：Network Address Translation）。比如：當用戶把他所有的計算機聯網並通過一個NAT路由器共享上互聯網。還有一種情況是VPN服務器自己位於NAT設備（UDP 500、4500傳送到VPN服務器）之后。甚至在有些情況下客戶端和服務器都位於NAT之后。有些ISP也使用在他們的路由器上使用NAT，我們看到許多GPRS服務商使用NAT，比如，他們給GPRS電話分配10.x.x.x或192.168.x.x地址。
NAT將在數據包穿過時改變它。問題是VPN會設法防止數據包改變。一些NAT設備支持“IPsec passthrough”，允許一次一個用戶的IPsec通過，相同的NAT設備后的不允許多個連接的用戶。
如果同L2TP/IPsec一起使用NAT-T，考慮到是實驗性的並且不安全。Linux kernel 2.6包含的一個不同的IPsec執行者（“26sec”）也支持NAT-T。顯然它也有與Openswan等的NAT-T補丁相同的安全問題。26sec執行者支持KAME用戶態程序（多數發行版的ipsec-tools）也支持Openswan/Strongswan/FreeS/WAN 2.x。切換到ipsec-tools並不能改變安全問題。
19.2 局限性和需求
NAT-T支持26sec（推薦kernel 2.6.6及以上），最新的發行版如Fedora Core2+、 Debian unstable、Mandrake 10.0+、SuSE 9.1+使用了帶26sec的內核，支持NAT-T。如果你在內核中使用 KLIPS代替26sec，你需要Mathieu Lafon的NAT-Traversal補丁（ source.arkoon.net/）。注：根據Mathieu，NAT-T在傳輸模式（Transport Mode）可能不安全。微軟、SSH、 SafeNet不支持NAT-T，但他大概會對非安全工作區拿出一個方案。老版的Red HAT、Mandrake、SuSE內核沒有包含KLIPS的 NAT-T補丁，對於這些版，你將需要重新編譯內核，因為NAT-T補丁涉及到了內核的TCP/IP部分。如果你用的是FreeS/WAN用戶態工具，你還要打這個補丁。Openswan和Strongswan已經包含了這個補丁。打過補丁后的FreeS/WAN在Makefile明確啟用了傳送模式下 NAT-T。Openswan和Strongswan已經支持傳送模式下NA-T。
Openswan的NAT-T支持對26sec和KLIPS都有效，在配置文件ipsec.conf中添加“nat_traversal=yes”即可，客戶端不在NAT后面不受影響，客戶端的任何程序都仍將正常工作。
KLIPS的NAT-T補丁目前不支持使用“預共享密鑰”認證的連接。如果你在KILPS和NAT-T使用了“預共享密鑰”，Openswan將不允許連接，因為發送者的端口不是500，並且NAT-T補丁不能支持它，這應該引起程序員的注意。“預共享密鑰”有一些缺點，因此你應該使用證書。 26sec執行者支持“預共享密鑰”，但你將不得不使用right=%any、leftid=和rightid=。如果你用right=a.b.c.d指定了一個IP地址，但沒有left=和right=，Openswan會提示“no connection authorized”。
如果你在同一NAT設備后面有多個客戶端，只有第一個客戶端可以連接，這大概是Linux內核的一個限制。另一個限制大概是客戶端不能共享相同的NAT-ed（internal）地址。當然這十分難以消除，尤其是遠程客戶端之間的一個小的團隊。另一個限制是如果客戶端和服務器都位於NAT后，我沒有親自測試過，但是我收到這方面的一份報告，它不能工作，不過我不能斷定到底是雙重NAT引起的還是其它原因。
幾乎所有L2TP/IPsec客戶端都支持NAT-T。Windows Server 2003也支持NAT-T。像承諾的那樣，微軟為 Windows XP和Windows 2000 Professional發布了一個IPsec升級包（MS KB Q818043）。這個升級包同樣也包含在Windows XP Service Pack 2，可是它制造出來的NAT-T升級包有導致第三方應用程序出現一大堆錯誤印刷的問題，因此微軟要召回它的升級包，2003年8月他們重新發布了一個補丁，這個補丁可能通過Windows Update安裝，如果你使用的是 Windows 2000 Professional，你需要先安裝Service Pack 3或更高版本，另外，IPsec升級包不會在 Windows Update顯示，對於Windows XP，你需要Service Pack 1或更高版本。如果升級包仍沒有在 Windows Update中顯示，轉到Windows Update Catalog並且使用“高檔搜索選項”搜索“818043”，如果你想下載 NAT-T升級程序到硬盤並發給更多的客戶端，你可以使用Windows Update的Download Basket（見：http: //support.microsoft.com/default.aspx?scid=kb;ZH-CN;323166）或 Software Update Services（見：http: //www.microsoft.com/windowsserversystem/sus/default.mspx）。
依據微軟員工的信件，也將可以對Windows 2000 Server和ISA Server更新，不過微軟寧願你升級到 Windows 2003。引用微軟的話（KB Q818043）：“在 Windows 2000 路由和遠程訪問中不會增加 NAT-T 服務器端支持。”如果你的服務器運行的Linux，微軟的這個決定不會影響到你。
除SSH Sentinel之外所有的客戶端都會自動檢測NAT-T是否啟用。SSH Sentinel需要手動在VPN連接的“屬性”窗口的“高檔”選項中啟用“NAT-Traversal”。
19.3 L2TP/IPsec客戶端支持NAT-T的情況
成功測試的（也就是看起來能工作，但是仍認為是試驗性的並且不安全的）。
• Windows XP Home/Professional（帶有IPsec update Q818043或 Service Pack2）。支持Windows需要最新的高於0.6c的NAT-T補丁（檢查/var/log/messages里的 Openswan的啟動信息來查看你服務器上的NAT-T版本）。這個補丁已經包含在Openswan2.x和Strongswan中，如果你的服務器沒有這個補丁，你將在LOG文件中看到“unsupported ID type ID FQDN”錯誤信息。如果沒有http: //www.advancevpn.com/public/super-freeswan-818043NATv3.patch補丁（Openswan 2.x和Strongswan 2.0.2+包含有這個補丁），你將得到“no connection is know”的錯誤信息（LOG中顯示的IP地址和端口號被一個大數代替）。如果你用的是帶SP2的Windows XP並且你的Openswan服務器位於NAT后面，你可能需要修改系統注冊表。
• Windows 2000 Professional（帶IPsec update Q818043，這個更新不包含在任何服務包中），參考上邊提到的Windows XP。
• Windows 2000 Server（當客戶端使用）：據一黑客報道，它可以工作，這個版本的Windows在 Windows Update中不會顯示IPsec update Q818043，但如果下載Windows 2000 Professional的 IPsec update Q818043補丁並安裝。微軟大概不支持這樣，也就是說它可能會破壞你的“支持合同”。在Widnows Update，到 Windows Update Catalogue並選擇“Windows 2000 Professional SP3和你的語言版本，在“高檔搜索” 中選擇“包含這些字符：818043”，把這個更新加入到“Download Basket”，下載並安裝。
• Windows Server 2003（當客戶端使用）：內建了NAT-T支持，也使用ID_FQDN法子（參考上邊提到的Windows XP）。
• MSL2TP客戶端連接到一個基於Linux的KLIPS服務器。
• SafeNet SoftRemote V7.0.5和9.2.1（可能僅用於KLIPS）。
• SSH Sentinel V1.4.1 build 98連接到基於KLIPS的服務器。可是有一個斷開連接的問題， Sentinel看起來不會發送“Delete SA”數據包，Openswan仍認為這是一個IPsec連接，因此客戶端在IPsec連接超時前不能訪問Linux機器的在外部接口。
• Pocket PC 2003（“Windows Mobile 2003 for Pocket PC”）用證書連接。可以工作，但只有證書比較尺寸比較小時可以。
• Pocket PC 2003用“預共享密鑰”連接到基於26sec的服務器。
不能工作的：
• MSL2TP客戶端連接到基於26sec的服務器。
• SSH Sentinel V1.41 build 98連接到基於26sec的服務器。
• SSH Sentinel V1.4 build 177。
• SSH Sentinel V1.3或更低。
• Pocket PC 2003用“預共享密鑰”連接到基於KLIPS的服務器。
至今不能工作的：
• Mac OS 10.3 Panther。
19.4 准備NAT-T
啟用NAT-T的過程：開始取決於你的發行版的內核是否包含26sec或KLIPS，如果你的內核支持26sec那么內核已經支持NAT-T。如果你的發行版的內核既沒有包含26sec也沒有包含KLIPS，那么很明顯沒有為IPsec供給NAT-T支持。即使你的內核支持KLIPS，大概仍不支持NAT-T。發行版根本不帶任何IPsec支持或帶一個基於內核沒有NAT-T補丁的KLIPS大概需要安裝一個新的內核。如果你需要安裝並且重新啟用一個新內核RPM，確認獲得了對內核RPM的一般警惕，，也就是不要更新內核，要重新安裝新內核來代替當前內核，並且在lilo.conf中為新內核增加一個入口，然后重新運行一下lilo（也可能使用GRUB）。
19.4.1 基於內核的26sec使用NAT-T
不像KLIPS的NAT-T補丁，26sec執行者支持“預共享密鑰”認證的NAT-T。可是你不能用right=a.b.c.d參數指定一個固定IP地址，將將只好指定right=%any並且使用leftid=/rightid=，這意味着“預共享密鑰”被所有Road Warriors共享。你也只好在ipsec.secrets中使用%any：
123.123.123.123 %any : PSK “thisismytopsecretkey”
不能使用l2tpd的listen-addr參數，因為26sec沒有使用ipsec0樣式的接口。
19.4.2 基於內核的KLIPS使用NAT-T
KLIPS的NAT-T補丁不支持“預共享密鑰”。
19.5 關於NAT-T的發行版細節信息
略
19.6 啟用NAT-T的過程
當你有一個支持NAT-T的內核和用戶態工具，你可以依照下面的過程為L2TP/IPsec客戶端啟用NAT-T。
• 確認L2TP/IPsec客戶端支持NAT-T，這常意味着你需要獲得最新版或安裝更新。
• 如果你的NAT設備支持IPsec passthrough，修改它的配置來禁用IPsec passthrough。
• 如果你的Openswan服務位於一個NAT設備后面並且你使用的客戶端運行的是帶SP2的Windows XP，你可能需要修改客戶端的注冊表。
• 在Openswan的配置文件ipsec.conf里添加一行nat_traversal=yes。
• 如果用戶的工作站位於NAT設備后面，IP地址是私網地址，Openswan在它可以商談一個連接前需要知道關於這個地址的一點情況，用戶NAT設備的公網IP用right=參數指定，有三種法子指定位於NAT設備后面的用戶工作站的私網地址：
法子1：rightsubnet=192.168.111.40/32
法子2：rightsubnetwithin=192.168.111.0/24
法子3：rightsubnet=vhost:%no,%priv （推薦）
第一種法子Openswan、Strongswan和所有的FreeS/WAN都支持，但明顯它不是特別靈活，你的每個 Road Warriors可能使用單獨的/32，這種法子不方便。第二種法子是X.509補丁的一個特點，這意味着只有Openswan和 Strongswan支持，FreeS/WAN打過X.509補丁后才能支持。可以接受你指定的一個子網並且客戶端使用的私有的地址（/32）位於這個子網。注，這和簡單的配置rightsubnetwinthin=0.0.0.0/0相比不是一個好的主意。第三種法子是NAT-T補丁的一個特性。這意味着Openswan和Strong在KLIPS和26sec上都支持，FreeS/WAN需要打過補丁后才支持。首先你在ipsec.conf文件中用 virtual_private=192.168.101.0/24參數指定子網。一些人更願意使用這個參數來列舉所有的RFC1918子網，除這些之外都用在你的Linux服務器上。參考NAT-T文檔的示例，客戶端的私有地址（/32）在任何這些子網都可以接受。另外，%no允許相同的配置文件用到沒有位於NAT設備后面的客戶。
20 Windows網絡（WINS等）
在許多方案中，VPN是用來開NetBIOS/SMB/CIFS網絡傳輸（Windows網絡）隧道的，不幸的是Windows網絡是一個很糟的協議（可以咨詢Samba的開發人員）並且它經常導致各種問題，這不是一篇Windows網絡指南，因此我不能在那方面幫助你，但是我可以供給一些提示：
如果你想通過子網（包含WAN和VPN）瀏覽“網上鄰居”，非常推薦有一台WINS服務器，如果你沒有一台可用的 Windows NT/2000/2003或你不想購買它，你可以下載Samba（網址：）並且將它配置成 WINS服務器。記住這個重要的部分：所有計算機必須配置成使用WINS服務，否則一些計算機看其它計算機可能有點麻煩。
我也注意到，最好的結果是所有的客戶端應該配置成使用相同的工作組名或域名，也就是辦公網絡。許多客戶端都有一個默認的工作組名或域名（比如 WORKGROUP或MSHOME），與實際辦公網絡的工作組名域名不同，最好將這些改成相同的名字。在ISA Server.org網站（http: //www.tacteam.net/isaserverorg/vpnkitbeta2/vpnclientbrowsing.htm）可以找到類似的技術。
微軟的客戶端有一個“登錄到網絡”的選項，如果你想登錄到域控制器就啟用它。
Windows XP Home不能加入一個域，可是你應該可以訪問域中的資源。
自從微軟認可L2TP/IPsec協議以來，我還沒有真正試過讓登錄腳本（批處理文件）工作，理論上它應該可以工作。在連接向導的最后一步，計算機詢問你這個連接是供“我自己”還是“使用這台計算機的所有人”使用，應該選擇“所有人”。你也許喜歡不輸入口令，在你下一次登錄時點擊“選項”按鈕，你可以看到出現一個復選框“通過撥號網絡登錄”，選中這個復選框，用你的Windows用戶名和口令登錄，你可以看到一個窗口讓你選擇的連接，其中有你剛才創建的VPN連接，選擇它你就可以通過VPN連接登錄，並且登錄腳本就會啟動。