什麼可能會阻止 IKE 握手成功建構 IPSEC 隧道？
我們使用 EZVPN 方法將 Cisco ASA 用於我們的 IPSEC VPN。我們有時會遇到 ISP 對其網路進行更改並且我們的 VPN 停止工作的問題。十有八九的 ISP 否認他們的改變可能會阻止這項工作——我懷疑是因為他們不明白究竟是什麼導致了問題。我想嘗試將他們指向一個可能獲得更快解決方案的方向，而不是僅僅與他們打頭陣。
在我目前的事件中，我可以通過 ssh 連接到 ASA 的外部介面並進行一些探索：
sh crypto isakmp sa Active SA: 1 Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey) Total IKE SA: 1 1 IKE Peer: {Public IP address of London ASA} Type : user Role : initiator Rekey : no State : AM_TM_INIT_XAUTH_V6C在連結的另一端，我看到以下內容：
Active SA: 26 <snip> 25 IKE Peer: {public IP address of Port-Au-Prince-ASA} Type : user Role : responder Rekey : no State : AM_TM_INIT_MODECFG_V6H我找不到關於 what
AM_TM_INIT_XAUTH_V6C或的任何文件AM_TM_INIT_MODECFG_V6H，但我很確定這意味著 IKE 握手由於某種原因失敗了。任何人都可以提出任何可能阻止 IKE 成功的事情，或者俱體的細節是什麼
AM_TM_INIT_XAUTH_V6C意思？更新：我們在另一個 ISP 的客戶的站點上連接了 ASA。VPN連接立即出現。這確認問題與配置無關。ISP現在正在承擔責任並進一步調查。
更新：上周連接突然恢復線上。我已通知 ISP 以查看他們是否更改了任何內容，但尚未收到回复。令人沮喪的是，我現在在另一個網站上看到了類似的問題。我找到了關於分段對 VPN 的影響的 Cisco 文件。我開始認為這可能是我所看到的問題的原因。
在思科的幫助下，我對正在發生的事情進行了更深入的分析，並找出了我需要檢查的事情。思科告訴我的有用的東西：
debug crypto isakmp 5提供足夠的詳細資訊以查看 ISAKMP 流量是否出現問題clear crypto isakmp sa清除任何陳舊的安全關聯。clear crypto isakmp {client_ip_address}可以在 HQ 上用於清除特定的安全關聯（如果只有一個設備出現問題，您不一定要清除所有安全關聯！- 兩端的數據包擷取對於弄清楚發生了什麼非常有用
稍微閱讀一下 IPSEC 套件，ISAKMP 更具體地表明，需要允許以下內容通過路徑中的任何防火牆：
- UDP 埠 500 上的 ISAKMP 流量
- UDP 埠 4500 上的 ISAKMP（用於 NAT 隧道）流量
- ESP 流量（IP 協議 50）
- AH 流量（IP 協議 51）
似乎很多人沒有意識到 IP 協議和 TCP/UDP 埠之間的重要區別。
以下數據包擷取側重於上述類型的流量。這些是在遠端 ASA 和 HQ ASA 上設置的：
object service isakmp-nat-t service udp destination eq 4500 description 4500 object-group service ISAKMP-Services description Traffic required for ISAKMP service-object esp service-object ah service-object object isakmp-nat-t service-object udp destination eq isakmp access-list ISAKMP extended permit object-group ISAKMP-Services host {hq_ip_address} host {remote_ip_address} access-list ISAKMP extended permit object-group ISAKMP-Services host {remote_ip_address} host {hq_ip_address} capture ISAKMP access-list ISAKMP interface outside然後，您可以從每個設備下載擷取
https://{device_ip_address}/capture/ISAKMP/pcap並在Wireshark中進行分析。我的數據包擷取顯示上面概述的 ISAKMP 流量正在變得碎片化——因為這些數據包是加密的，一旦它們被碎片化，就很難將它們重新組合在一起並且事情會中斷。
將此資訊提供給 ISP 意味著他們可以進行自己的集中檢查，並導致他們對防火牆進行一些更改。結果發現 ISP 阻止了其邊緣路由器上的所有ICMP 流量，這意味著路徑 MTU 發現被破壞，導致 ISAKMP 數據包碎片化。一旦他們停止全面封鎖 ICMP，VPN 就會出現（我希望他們所有的客戶都開始獲得更好的服務）。