国内 IPsec VPN のトラブルシューティング方法。 パート1

状況

休みの日。 コーヒーを飲む。 学生は XNUMX 地点間に VPN 接続を設定し、行方不明になりました。 確認すると、本当にトンネルがありますが、トンネル内には交通量がありません。 生徒は電話に出ません。

やかんを付けて、S-Terra ゲートウェイのトラブルシューティングに取り組みます。 私の経験と方法論を共有します。

初期データ

地理的に離れた XNUMX つのサイトは GRE トンネルによって接続されています。 GRE は暗号化する必要があります。

GRE トンネルの機能をチェックしています。 これを行うには、デバイス R1 からデバイス R2 の GRE インターフェイスに対して ping を実行します。 これが暗号化の対象となるトラフィックです。 答えはありません:

root@R1:~# ping 1.1.1.2 -c 4
PING 1.1.1.2 (1.1.1.2) 56(84) bytes of data.

--- 1.1.1.2 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3057ms

Gate1 と Gate2 のログを確認します。 ログには、IPsec トンネルが問題なく正常に起動されたことがうれしく報告されています。

root@Gate1:~# cat /var/log/cspvpngate.log
Aug  5 16:14:23 localhost  vpnsvc: 00100119 <4:1> IPSec connection 5 established, traffic selector 172.17.0.1->172.16.0.1, proto 47, peer 10.10.10.251, id "10.10.10.251", Filter 
IPsec:Protect:CMAP:1:LIST, IPsecAction IPsecAction:CMAP:1, IKERule IKERule:CMAP:1

Gate1 の IPsec トンネルの統計を見ると、実際にはトンネルが存在しますが、Rсvd カウンタがゼロにリセットされています。

root@Gate1:~# sa_mgr show
ISAKMP sessions: 0 initiated, 0 responded

ISAKMP connections:
Num Conn-id (Local Addr,Port)-(Remote Addr,Port) State Sent Rcvd
1 3 (10.10.10.251,500)-(10.10.10.252,500) active 1070 1014

IPsec connections:
Num Conn-id (Local Addr,Port)-(Remote Addr,Port) Protocol Action Type Sent Rcvd
1 3 (172.16.0.1,*)-(172.17.0.1,*) 47 ESP tunn 480 0

S-Terra を次のようにトラブルシューティングします。R1 から R2 へのパス上でターゲットのパケットが失われた場所を探します。 その過程で（ネタバレ）間違いを見つけてしまいます。

トラブルシューティング

ステップ 1. Gate1 が R1 から受け取るもの

私は組み込みのパケット スニファー tcpdump を使用します。 内部インターフェイス (Cisco のような表記では Gi0/1、Debian OS の表記では eth1) でスニッファを起動します。

root@Gate1:~# tcpdump -i eth1

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
14:53:38.879525 IP 172.16.0.1 > 172.17.0.1: GREv0, key=0x1, length 92: IP 1.1.1.1 > 1.1.1.2: ICMP echo request, id 2083, seq 1, length 64
14:53:39.896869 IP 172.16.0.1 > 172.17.0.1: GREv0, key=0x1, length 92: IP 1.1.1.1 > 1.1.1.2: ICMP echo request, id 2083, seq 2, length 64
14:53:40.921121 IP 172.16.0.1 > 172.17.0.1: GREv0, key=0x1, length 92: IP 1.1.1.1 > 1.1.1.2: ICMP echo request, id 2083, seq 3, length 64
14:53:41.944958 IP 172.16.0.1 > 172.17.0.1: GREv0, key=0x1, length 92: IP 1.1.1.1 > 1.1.1.2: ICMP echo request, id 2083, seq 4, length 64

Gate1 が R1 から GRE パケットを受信して​​いることがわかります。 先に進みます。

ステップ 2. Gate1 が GRE パケットを処理すること

klogview ユーティリティを使用すると、S-Terra VPN ドライバー内の GRE パケットで何が起こっているかを確認できます。

root@Gate1:~# klogview -f 0xffffffff

filtration result for out packet 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0: chain 4 "IPsecPolicy:CMAP", filter 8, event id IPsec:Protect:CMAP:1:LIST, status PASS
encapsulating with SA 31: 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0
passed out packet 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: encapsulated

ターゲット GRE トラフィック (proto 47) 172.16.0.1 -> 172.17.0.1 が CMAP 暗号マップの LIST 暗号化ルールの下にあり、カプセル化されていることがわかります。 次に、パケットがルーティング (パスアウト) されました。 klogview 出力には応答トラフィックはありません。

Gate1 デバイスのアクセス リストをチェックしています。 XNUMX つのアクセス リスト LIST が表示されます。これは、暗号化のターゲット トラフィックを定義しています。これは、ファイアウォール ルールが設定されていないことを意味します。

Gate1#show access-lists
Extended IP access list LIST
    10 permit gre host 172.16.0.1 host 172.17.0.1

結論: 問題は Gate1 デバイスにありません。

klogview についてさらに詳しく

VPN ドライバーは、暗号化が必要なトラフィックだけでなく、すべてのネットワーク トラフィックを処理します。 これらは、VPN ドライバーがネットワーク トラフィックを処理し、暗号化せずに送信した場合に klogview に表示されるメッセージです。

root@R1:~# ping 172.17.0.1 -c 4

root@Gate1:~# klogview -f 0xffffffff

filtration result for out packet 172.16.0.1->172.17.0.1, proto 1, len 84, if eth0: chain 4 "IPsecPolicy:CMAP": no match
passed out packet 172.16.0.1->172.17.0.1, proto 1, len 84, if eth0: filtered

ICMP トラフィック (プロト 1) 172.16.0.1->172.17.0.1 が CMAP 暗号化カードの暗号化ルールに含まれていない (一致しない) ことがわかります。 パケットはクリア テキストでルーティング (送信) されました。

ステップ 3. Gate2 が Gate1 から受け取るもの

WAN (eth0) Gate2 インターフェイスでスニファを起動します。

root@Gate2:~# tcpdump -i eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:05:45.104195 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x1), length 140
16:05:46.093918 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x2), length 140
16:05:47.117078 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x3), length 140
16:05:48.141785 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x4), length 140

Gate2 が Gate1 から ESP パケットを受信して​​いることがわかります。

ステップ 4. Gate2 が ESP パッケージで行うこと

Gate2 で klogview ユーティリティを起動します。

root@Gate2:~# klogview -f 0xffffffff
filtration result for in packet 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: chain 17 "FilterChain:L3VPN", filter 21, status DROP
dropped in packet 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: firewall

ESP パケット (proto 50) がファイアウォール ルール (L3VPN) によってドロップ (DROP) されたことがわかります。 Gi0/0 に実際に L3VPN アクセス リストがアタッチされていることを確認します。

Gate2#show ip interface gi0/0
GigabitEthernet0/0 is up, line protocol is up
  Internet address is 10.10.10.252/24
  MTU is 1500 bytes
  Outgoing access list is not set
  Inbound  access list is L3VPN

問題を発見しました。

ステップ 5. アクセス リストの問題点

L3VPN アクセス リストが何であるかを調べます。

Gate2#show access-list L3VPN
Extended IP access list L3VPN
    10 permit udp host 10.10.10.251 any eq isakmp
    20 permit udp host 10.10.10.251 any eq non500-isakmp
    30 permit icmp host 10.10.10.251 any

ISAKMP パケットが許可されているため、IPsec トンネルが確立されていることがわかります。 しかし、ESP を有効にするルールはありません。 どうやら学生はicmpとespを混同したようです。

アクセスリストの編集:

Gate2(config)#
ip access-list extended L3VPN
no 30
30 permit esp host 10.10.10.251 any

ステップ 6. 機能の確認

まず最初に、L3VPN アクセス リストが正しいことを確認します。

Gate2#show access-list L3VPN
Extended IP access list L3VPN
    10 permit udp host 10.10.10.251 any eq isakmp
    20 permit udp host 10.10.10.251 any eq non500-isakmp
    30 permit esp host 10.10.10.251 any

ここで、デバイス R1 からターゲット トラフィックを開始します。

root@R1:~# ping 1.1.1.2 -c 4
PING 1.1.1.2 (1.1.1.2) 56(84) bytes of data.
64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=35.3 ms
64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=3.01 ms
64 bytes from 1.1.1.2: icmp_seq=3 ttl=64 time=2.65 ms
64 bytes from 1.1.1.2: icmp_seq=4 ttl=64 time=2.87 ms

--- 1.1.1.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 2.650/10.970/35.338/14.069 ms

勝利。 GRE トンネルが確立されました。 IPsec 統計の受信トラフィック カウンタがゼロではありません。

root@Gate1:~# sa_mgr show
ISAKMP sessions: 0 initiated, 0 responded

ISAKMP connections:
Num Conn-id (Local Addr,Port)-(Remote Addr,Port) State Sent Rcvd
1 3 (10.10.10.251,500)-(10.10.10.252,500) active 1474 1350

IPsec connections:
Num Conn-id (Local Addr,Port)-(Remote Addr,Port) Protocol Action Type Sent Rcvd
1 4 (172.16.0.1,*)-(172.17.0.1,*) 47 ESP tunn 1920 480

Gate2 ゲートウェイの klogview 出力には、ターゲット トラフィック 172.16.0.1->172.17.0.1 が CMAP 暗号マップの LIST ルールによって正常に復号化 (PASS) されたことを示すメッセージが表示されました。

root@Gate2:~# klogview -f 0xffffffff
filtration result for in packet 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0: chain 18 "IPsecPolicy:CMAP", filter 25, event id IPsec:Protect:CMAP:1:LIST, status PASS
passed in packet 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0: decapsulated

結果

学生が休日を台無しにした。
MEルールには注意してください。

匿名のエンジニア
t.me/anonymous_engineer

出所： habr.com