為了連接到我客戶的公司網絡,我一直在使用 Cisco AnyConnect 安全地移動客戶端,這工作正常,但似乎不允許我使用分割隧道(儘管根據應用程式的統計選項卡,VPN 本身,有隧道模式(IPv4 ):拆分包含,據我理解,這應該意味著我可以)。 (是的,我理解為什麼分割隧道可能很危險,但 VPN 的鎖定乾擾了我的工作,而且我客戶的 IT 部門對為承包商破例不感興趣——正如我所說,配置好像允許它。
為了找到一種讓分割隧道發揮作用的方法,我安裝了 OpenConnect,並且連接得很好 — 它接受我的憑證,我在日誌中看到該公司的「橫幅」訊息,它可以工作。但我只能透過 VPN 存取的目的地都不起作用。
我懷疑問題出在路線上。 AnyConnect 和 OpenConnect 都新增了許多到特定網路目標(相同)的路由,但網關和介面的值不同。舉個例子,
AnyConnect
===========================================================================
Interface List
14...00 05 9a 3c 7a 00 ......Cisco AnyConnect Secure Mobility Client Virtual Miniport Adapter for Windows x64
[...]
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.151 35
[...]
a.b.c.x 255.255.255.255 On-link a.b.c.d 2
a.b.c.y 255.255.255.255 On-link a.b.c.d 2
a.b.c.z 255.255.255.255 On-link a.b.c.d 2
[...]
192.168.1.1 255.255.255.255 On-link 192.168.1.151 36
[...]
224.0.0.0 240.0.0.0 On-link a.b.c.d 10000
[...]
255.255.255.255 255.255.255.255 On-link a.b.c.d 10000
開放連接
Interface List
[...]
63...00 ff 8d 2a 8a 57 ......TAP-Windows Adapter V9
[...]
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.151 36
[...]
a.b.c.x 255.255.255.255 a.b.c.(d+1) 192.168.1.151 36
a.b.c.y 255.255.255.255 a.b.c.(d+1) 192.168.1.151 36
a.b.c.z 255.255.255.255 a.b.c.(d+1) 192.168.1.151 36
[...]
224.0.0.0 240.0.0.0 On-link a.b.c.d 291
[...]
255.255.255.255 255.255.255.255 On-link a.b.c.d 291
除了0.0.0.0
路由之外,所有這些路由都是透過連接到 VPN 新增的。對於0.0.0.0
,OpenConnect 將路由的度量更改0.0.0.0
為 36(AnyConnect 表中顯示的值也與我完全斷開連接時的值相同)。 (根據記錄,AnyConnect 也刪除了幾條 IPv6 路由,而 OpenConnect 則不理會這些路由 — 我認為這並不重要?)
為了明確比較新增內容,AnyConnect 對網關使用“On-link”,而 OpenConnect 使用的 IP 位址幾乎與 AnyConnect 用於介面的 IP 位址相同。對於接口,OpenConnect 使用私有 IP 位址。用於 AnyConnect 介面和 OpenConnect 閘道的 IP 位址位於用戶端擁有的範圍內。
指標也不同 — AnyConnect 使用 2,其優先權高於我的0.0.0.0
路由(透過 AnyConnect 斷線或連線時設定為 35),而 OpenConnect 使用 36 — 並且也將我的0.0.0.0
路由改為使用36,因此優先權是相同的 (我係統上的所有其他路由都使用高於 36 的度量,以供記錄)。
192.168.1.1
AnyConnect 也新增了、 到的路由192.168.1.151
,這是 OpenConnect 用於介面的路由。這是唯一一條只有一個途徑有而另一個途徑卻沒有的途徑。
兩者都還添加了224.0.0.0
和的路由255.255.255.255
,但AnyConnect 使用的度量為10000(高於任何其他路由),而OpenConnect 使用291(高於任何其他添加,但低於我在連接之前擁有的其他一些現有路由)。有趣的是,OpenConnect 對這兩條路由使用與 AnyConnect 相同的網關和接口,儘管對所有其他路由使用不同的值。
這是在 Windows 10 Pro x64 電腦上。 Cisco AnyConnect 版本為 4.5.03040; OpenConnect GUI 是「版本1.5.3(32 位元)[...] 基於 OpenConnect v7.08。
我對路由或 VPN 不太了解;即使獲得這麼多信息,也需要進行大量搜索和閱讀。在開始之前我什至不知道“分割隧道”這個術語。許多資訊也已經過時 - Windows 10 不提供「在遠端網路上使用預設網關」選項來取消選中,因為這裡和其他地方的許多其他答案都建議在 AnyConnect 下使用分割隧道。我不知道是否可以提供其他相關細節,但如果需要其他任何信息,我當然很樂意提供。顯然,我一直在嘗試封鎖我客戶的IP位址,但我認為具體位址在這裡並不重要(我也不知道有什麼理由封鎖它們,但這不是我要分享的訊息,所以我不是)。
答案1
根據 KRyan 的回答,我修改了我的 openconnect 腳本(openconnect gui 資料夾中的 vpnc-script.js!),如下所示,它在類似的情況下幫助了我:
for (var i = 0 ; i < parseInt(env("CISCO_SPLIT_INC")); i++) {
var network = env("CISCO_SPLIT_INC_" + i + "_ADDR");
var netmask = env("CISCO_SPLIT_INC_" + i + "_MASK");
var netmasklen = env("CISCO_SPLIT_INC_" + i + "_MASKLEN");
exec("route add " + network + " mask " + netmask);
}
=>
for (var i = 0 ; i < parseInt(env("CISCO_SPLIT_INC")); i++) {
var network = env("CISCO_SPLIT_INC_" + i + "_ADDR");
var netmask = env("CISCO_SPLIT_INC_" + i + "_MASK");
var netmasklen = env("CISCO_SPLIT_INC_" + i + "_MASKLEN");
exec("route add " + network + " mask " + netmask + " " + internal_gw+" metric 2 if "+env("TUNIDX"));
}
(第 175 行)
我認為的錯誤在這裡:
// Calculate the first usable address in subnet
var internal_gw_array = new Array(
address_array[0] & netmask_array[0],
address_array[1] & netmask_array[1],
address_array[2] & netmask_array[2],
(address_array[3] & netmask_array[3]) + 1
);
var internal_gw = internal_gw_array.join(".");
對於由 傳入的內部 IP 的網路遮罩 255.255.255.255 var netmask_array = env("INTERNAL_IP4_NETMASK").split(".");
,此網關技巧(最終路由到達接口,網關 ip 在這裡毫無意義)似乎失敗
答案2
我是對的,路線才是問題所在。經過大量的試驗和錯誤才得到正確的結果,但最終在連接成功後手動更新路線。
奇怪的是,route CHANGE
沒有用;我必須使用route ADD
,儘管據我所知這些路線在我連接後已經存在。我使用相同的目標、遮罩和網關,然後METRIC 2 IF 17
(因為「TAP-Windows 適配器V9」介面使用17,我懷疑它會隨著每次重新啟動而改變?斷開連接和重新連接目前似乎始終使用17,但如您所見)可以在問題中看到它當時使用的是 63)。執行此操作後,該目的地列出了兩個條目route PRINT
(OpenConnect 添加的一個和我添加的一個),它允許我進行連接。
不過,我認為絕對奇怪的是,我新添加的路線的度量為 37,而不是我在命令中輸入的 2 route ADD
,並且大於現有條目的度量 36。但無論如何,它有效。
幸運的是,我們的專案維護了一個hosts
文件(供開發人員在開始處理該文件時複製到自己的hosts
文件中,並且我們的建置工具會進行檢查),因此我能夠編寫批次腳本來調整路由。為了其他想要這樣做的人,我的批次腳本如下所示
FOR /F "tokens=1" %%i IN (\path\to\our\development\hosts) DO (
route ADD %%i MASK 255.255.255.255 a.b.c.d METRIC 2 IF 17
)
文件hosts
格式與系統文件相同:a.b.c.d URL
.該腳本不支援註釋(儘管我想它route ADD
會失敗)並且我不知道空行是否會成為問題(但同樣,可能只是失敗route ADD
)。
我可能需要針對 17 進行調整,因為我懷疑這不會是恆定的;當出現這種情況時,我將研究如何確定它是什麼並使用變數代替。 (我也會更新這個答案。)
答案3
並不是說您還沒有找到可行的方法,而是您似乎誤解瞭如何使用路由指標。它們實際上只是在特定情況下的決定性因素。引用連結的答案:
Windows 上的路由選擇,涉及:
- 尋找到達目的地的最具體路線
- 選擇具有最低度量的最具體的路由。
如果你想讓你的腳本不那麼脆弱,你可以以程式方式確定介面編號。