Сітуацыя
Выходны. П'ю каву. Студэнт наладзіў VPN злучэнне паміж двума кропкамі і знік. Правяраю: тунэль сапраўды ёсць, але трафіку ў тунэлі няма. На званкі студэнт не адказвае.
Стаўлю імбрычак і апускаюся ў траблшутинг С-Тэра Шлюз. Дзялюся сваім досведам і метадалогіяй.
Зыходныя дадзеныя
Дзве тэрытарыяльна падзеленыя пляцоўкі звязаны GRE тунэлем. GRE трэба зашыфраваць:
Правяраю працаздольнасць GRE тунэля. Для гэтага запускаю ping з прылады R1 да GRE інтэрфейсу прылады R2. Гэта мэтавы трафік для шыфравання. Адказу няма:
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У статыстыцы IPsec тунэля на Gate1 бачу, што тунэль сапраўды ёсць, але лічыльнік 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Я траблшучу З-Тэрру так: шукаю, дзе губляюцца мэтавыя пакеты на шляхі ад R1 да R2. У працэсе (спойлер) знайду памылку.
Траблшутынг
Крок 1. Што атрымлівае Gate1 ад R1
Выкарыстоўваю ўбудаваны пакетны сниффер - tcpdump. Запускаю сниффер на ўнутраным (Gi0/1 у натацыі Cisco-like або eth1 у натацыі АС Debian) інтэрфейсе:
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 гляджу, што адбываецца з GRE пакетамі ўсярэдзіне VPN драйвера З-Тэра:
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 патрапіў (PASS) пад правіла шыфравання LIST у крыптакарце CMAP і зашыфраваўся (encapsulated). Далей пакет змаршрутызаваўся (passed out). Трафік у адказ у выснове klogview няма.
Правяраю спісы доступу на прыладзе Gate1. Бачу адзін спіс доступу 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 драйвер апрацоўвае ўвесь сеткавы трафік, не толькі той, які павінен шыфравацца. Вось такія паведамленні бачныя ў klogview, калі VPN драйвер апрацаваў сеткавы трафік і перадаў яго ў незашыфраваным выглядзе:
root@R1:~# ping 172.17.0.1 -c 4root@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 трафік (proto 1) 172.16.0.1->172.17.0.1 не патрапіў (no match) у правілы шыфравання криптокарты CMAP. Пакет змаршрутызаваўся (passed out) у адкрытым выглядзе.
Крок 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 атрымлівае ESP пакеты ад Gate1.
Крок 4. Што Gate2 робіць з ESP пакетамі
Запускаю ўтыліту klogview на Gate2:
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) былі драпнуты (DROP), правілам (L3VPN) міжсеткавага экрана (firewall). Пераканаюся, што да 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 паспяхова (PASS) расшыфраваны (decapsulated) правілам LIST у крыптакарце CMAP:
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Вынікі
Студэнт прыпсаваў выходны.
Акуратней з правіламі МЭ.
Ананімны інжынер
t.me/anonimous_engineer
Крыніца: habr.com