當我通過客戶端連接到 VPN 伺服器時Cisco AnyConnect，我的 virtualbox 路由資訊消失了。

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         *               0.0.0.0         U     0      0        0 cscotun0
default         172.21.157.1    0.0.0.0         UG    256    0        0 eth0
172.23.36.90    172.21.157.1    255.255.255.255 UGH   0      0        0 eth0
172.23.236.0    *               255.255.254.0   U     0      0        0 cscotun0

然後我嘗試通過以下方式恢復它：

# ip route add 192.168.56.0/24 via 192.168.56.1 src 192.168.56.1

該命令成功且沒有錯誤，但從route命令它不會添加任何內容

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         *               0.0.0.0         U     0      0        0 cscotun0
default         172.21.157.1    0.0.0.0         UG    256    0        0 eth0
172.23.36.90    172.21.157.1    255.255.255.255 UGH   0      0        0 eth0
172.23.236.0    *               255.255.254.0   U     0      0        0 cscotun0

有任何想法嗎？我已將 apparmor 配置為阻止 vpnagentd 執行 iptables 或 modprobe 命令（如果相關）。

原來是 Cisco AnyConnect 客戶端正在監控路由表。

C++ 函式CHostConfigMgr::StartInterfaceAndRouteMonitoring()正在完成這項工作。您可以修改函式以使其立即返回（並修復 vpnagentd 中的校驗和驗證）或使用新函式名稱嘗試此解決方案_ZN14CHostConfigMgr32StartInterfaceAndRouteMonitoringEv

介紹和其他選項

已經有 5.5 年了，所以我主要把這個答案留給人們，試圖用現代 Cisco Anyconnect 4.x 解決同樣的問題。在我的例子中，Anyconnect 將流量包裝到由 Minikube 在 macOS 上啟動的本地 Kubernetes 集群。

類似_ZN27CInterfaceRouteMonitorLinux20routeCallbackHandlerEv或__ZN25CInterfaceRouteMonitorMac20routeCallbackHandlerEv描述的方法：

• https://superuser.com/a/1174704/465915
• https://superuser.com/a/870752/465915

似乎不再起作用了。此外，許多指南都與修復以前版本中的 OS X 防火牆有關，如此處的實用ipfw程序，因此它們無關緊要。

修補 vpnagentd

在 2019 年，我們仍在與公司避免拆分路由和提出不合理的防火牆規則這兩個問題作鬥爭。這是修復。

您需要 CHostConfigMgr::StartInterfaceAndRouteMonitoring()在vpnagentd二進制中修補方法的呼叫，在我的版本中位於0x09cbf6. 這是一個簡單的jmp qword命令，永遠不會返回到這個地方，所以一個人nop就足夠了。但是，用 6nop秒完全擦除命令可能是值得的。

這裡的 Python 腳本可以為您自動執行此過程，但是任何反彙編實用程序都可以幫助您。在我最初的研究和破解中，我使用radare2了這對於不每天執行此類操作的人來說非常方便：

#!/usr/bin/python3

MAGIC_OFFSET = "0x09cbf6"
MAGIC_BYTE = 144

def eff_anyconnect(file):

   print("Opening {} to patch it".format(file))
   with open(file, "rb+") as f:
       print("Going to {}".format(MAGIC_OFFSET))

       print("Current command to call method for watching our routing table")
       f.seek(int(MAGIC_OFFSET, 16))
       print(hex(int.from_bytes(f.read(6), "big")))

       f.seek(int(MAGIC_OFFSET, 16))
       f.write(bytes([MAGIC_BYTE]))

       print("NOP any longer:")
       f.seek(int(MAGIC_OFFSET, 16))
       print(hex(int.from_bytes(f.read(6), "big")))

eff_anyconnect("/your/path/to/cisco/bin/vpnagentd")

下一步，在您修補二進製文件後，您應該終止目前vpnagent程序並重新連接到您的 VPN。您可能會發現所需的路由仍然受到影響，但上面的 hack 將解鎖路由表，因此您可以覆蓋路由。

路線

我建議添加-static一個，那些根本不受 AnyConnect 干擾，而非靜態仍然被隧道複製。我在這裡沒有好的解決方案，對於我來說，單個靜態路由就足夠了：

sudo route -n delete $(minikube ip) 
sudo route -n add $(minikube ip) -interface bridge100 -static

防火牆

最後，防火牆步驟。這非常簡單，您需要檢查哪些規則拒絕或僅允許帶有 AnyConnect 標記的規則。就我而言，未標記的所有內容都被阻止，因此我創建了一個包含以下條目的文件：

nat on utun1 proto {tcp, udp, icmp} from 192.168.64.0/24 to any -> utun1 
pass in log on bridge0 inet all flags S/SA keep state tag cisco_anyconnect_vpn_pass
pass in log on bridge100 inet all flags S/SA keep state tag cisco_anyconnect_vpn_pass

請注意以下幾點：

• utun1是您的 AnyConnect 介面
• bridge0並且bridge100是您的 Minikube/Docker 橋樑。出於某種原因，AnyConnect 重命名了網橋。
• 192.168.64.0/24是您的 Minikube 子網。

然後執行：

sudo pfctl -e enable packet-filtering
sudo pfctl -f <your_file_with_rules> -v

從現在開始，直到下一次重新連接，您應該在路由和防火牆方面做得很好。

引用自：https://unix.stackexchange.com/questions/106304