Situation
Ledig dag. Jag dricker kaffe. Eleven satte upp en VPN-anslutning mellan två punkter och försvann. Jag kollar: det finns verkligen en tunnel, men det är ingen trafik i tunneln. Eleven svarar inte på samtal.
Jag sätter på vattenkokaren och dyker in i felsökningen av S-Terra Gateway. Jag delar med mig av mina erfarenheter och metoder.
Rå data
De två geografiskt åtskilda platserna är förbundna med en GRE-tunnel. GRE måste krypteras:
Jag kollar funktionen hos GRE-tunneln. För att göra detta kör jag ping från enhet R1 till GRE-gränssnittet på enhet R2. Detta är måltrafiken för kryptering. Inget svar:
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 3057msJag tittar på loggarna på Gate1 och Gate2. Loggen rapporterar glatt att IPsec-tunneln har lanserats framgångsrikt, inga problem:
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:1I statistiken för IPsec-tunneln på Gate1 ser jag att det verkligen finns en tunnel, men Rсvd-räknaren återställs till noll:
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 0Jag besvärar S-Terra så här: Jag letar efter var målpaketen går förlorade på vägen från R1 till R2. I processen (spoiler) kommer jag att hitta ett misstag.
Felsökning
Steg 1. Vad Gate1 tar emot från R1
Jag använder den inbyggda paketsniffer - tcpdump. Jag startar sniffern på det interna gränssnittet (Gi0/1 i Cisco-liknande notation eller eth1 i Debian OS-notation):
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 64Jag ser att Gate1 tar emot GRE-paket från R1. Jag går vidare.
Steg 2. Vad Gate1 gör med GRE-paket
Med hjälp av klogview-verktyget kan jag se vad som händer med GRE-paket inuti S-Terra VPN-drivrutinen:
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
Jag ser att mål-GRE-trafiken (proto 47) 172.16.0.1 -> 172.17.0.1 kom under LIST-krypteringsregeln i CMAP-krypteringskartan och var inkapslad. Därefter dirigerades paketet (passades ut). Det finns ingen svarstrafik i klogview-utgången.
Jag kollar åtkomstlistorna på Gate1-enheten. Jag ser en åtkomstlista LIST, som definierar måltrafiken för kryptering, vilket betyder att brandväggsreglerna inte är konfigurerade:
Gate1#show access-lists
Extended IP access list LIST
10 permit gre host 172.16.0.1 host 172.17.0.1Slutsats: problemet är inte med Gate1-enheten.
Mer om klogview
VPN-drivrutinen hanterar all nätverkstrafik, inte bara den trafik som behöver krypteras. Dessa är meddelandena som är synliga i klogview om VPN-drivrutinen bearbetade nätverkstrafiken och överförde den okrypterad:
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: filteredJag ser att ICMP-trafik (proto 1) 172.16.0.1->172.17.0.1 inte ingick (ingen matchning) i krypteringsreglerna för CMAP-krypteringskortet. Paketet dirigerades (passades ut) i klartext.
Steg 3. Vad Gate2 tar emot från Gate1
Jag startar sniffern på WAN (eth0) Gate2-gränssnittet:
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 140Jag ser att Gate2 tar emot ESP-paket från Gate1.
Steg 4. Vad Gate2 gör med ESP-paket
Jag startar klogview-verktyget på 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
Jag ser att ESP-paket (proto 50) släpptes (DROP) av brandväggsregeln (L3VPN). Jag ser till att Gi0/0 faktiskt har en L3VPN-åtkomstlista kopplad till den:
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 L3VPNJag upptäckte problemet.
Steg 5. Vad är fel med åtkomstlistan
Jag tittar på vad L3VPN-åtkomstlistan är:
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 anyJag ser att ISAKMP-paket är tillåtna, så en IPsec-tunnel upprättas. Men det finns ingen aktiveringsregel för ESP. Uppenbarligen förväxlade studenten icmp och esp.
Redigera åtkomstlistan:
Gate2(config)#
ip access-list extended L3VPN
no 30
30 permit esp host 10.10.10.251 anySteg 6. Kontrollera funktionalitet
Först och främst ser jag till att L3VPN-åtkomstlistan är korrekt:
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 anyNu startar jag måltrafik från enhet 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 msSeger. GRE-tunneln har upprättats. Räknaren för inkommande trafik i IPsec-statistiken är inte noll:
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 480På Gate2-gatewayen, i klogview-utgången, dök meddelanden upp om att måltrafiken 172.16.0.1->172.17.0.1 framgångsrikt dekrypterades (PASS) av LIST-regeln i CMAP-krypteringskartan:
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: decapsulatedResultat av
En student förstörde hans lediga dag.
Var försiktig med ME-reglerna.
Anonym ingenjör
t.me/anonym_ingenjör
Källa: will.com