De situatie
Vrije dag. Ik drink koffie. De student zette een VPN-verbinding op tussen twee punten en verdween. Ik controleer: er is echt een tunnel, maar er is geen verkeer in de tunnel. De leerling beantwoordt geen oproepen.
Ik zet de ketel op en duik in de probleemoplossing van de S-Terra Gateway. Ik deel mijn ervaring en methodiek.
Initiële gegevens
De twee geografisch gescheiden locaties zijn verbonden door een GRE-tunnel. GRE moet worden gecodeerd:
Ik controleer de functionaliteit van de GRE-tunnel. Om dit te doen, voer ik ping uit van apparaat R1 naar de GRE-interface van apparaat R2. Dit is het doelverkeer voor versleuteling. Geen antwoord:
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 3057msIk kijk naar de logboeken op Gate1 en Gate2. Het log meldt vrolijk dat de IPsec-tunnel met succes is gelanceerd, zonder problemen:
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:1In de statistieken van de IPsec-tunnel op Gate1 zie ik dat er echt een tunnel is, maar de Rсvd-teller wordt op nul gezet:
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 0Ik maak S-Terra op de volgende manier lastig: ik zoek waar de doelpakketten verloren gaan op het pad van R1 naar R2. In het proces (spoiler) zal ik een fout ontdekken.
Probleemoplossen
Stap 1. Wat Gate1 ontvangt van R1
Ik gebruik de ingebouwde pakketsniffer - tcpdump. Ik start de sniffer op de interne (Gi0/1 in Cisco-achtige notatie of eth1 in Debian OS-notatie) interface:
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 64Ik zie dat Gate1 GRE-pakketten ontvangt van R1. Ik ga verder.
Stap 2. Wat Gate1 doet met GRE-pakketten
Met behulp van het klogview-hulpprogramma kan ik zien wat er gebeurt met GRE-pakketten in het S-Terra VPN-stuurprogramma:
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
Ik zie dat het doel-GRE-verkeer (proto 47) 172.16.0.1 -> 172.17.0.1 onder de LIST-coderingsregel in de CMAP-cryptokaart viel en ingekapseld was. Vervolgens werd het pakket gerouteerd (uitgegeven). Er is geen antwoordverkeer in de klogview-uitvoer.
Ik controleer de toegangslijsten op het Gate1-apparaat. Ik zie één toegangslijst LIST, die het doelverkeer voor codering definieert, wat betekent dat de firewallregels niet zijn geconfigureerd:
Gate1#show access-lists
Extended IP access list LIST
10 permit gre host 172.16.0.1 host 172.17.0.1Conclusie: het probleem ligt niet bij het Gate1-apparaat.
Meer over klogview
Het VPN-stuurprogramma verwerkt al het netwerkverkeer, niet alleen het verkeer dat gecodeerd moet worden. Dit zijn de berichten die zichtbaar zijn in klogview als het VPN-stuurprogramma het netwerkverkeer verwerkt en onversleuteld verzendt:
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: filteredIk zie dat ICMP-verkeer (proto 1) 172.16.0.1->172.17.0.1 niet was opgenomen (geen match) in de encryptieregels van de CMAP-cryptokaart. Het pakket werd in duidelijke tekst doorgestuurd (uitgedeeld).
Stap 3. Wat Gate2 ontvangt van Gate1
Ik start de sniffer op de WAN (eth0) Gate2-interface:
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 140Ik zie dat Gate2 ESP-pakketten ontvangt van Gate1.
Stap 4. Wat Gate2 doet met ESP-pakketten
Ik start het klogview-hulpprogramma op 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
Ik zie dat ESP-pakketten (proto 50) zijn verwijderd (DROP) door de firewallregel (L3VPN). Ik zorg ervoor dat aan Gi0/0 daadwerkelijk een L3VPN-toegangslijst is gekoppeld:
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 L3VPNIk heb het probleem ontdekt.
Stap 5. Wat is er mis met de toegangslijst
Ik kijk naar wat de L3VPN-toegangslijst is:
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 anyIk zie dat ISAKMP-pakketten zijn toegestaan, dus er is een IPsec-tunnel tot stand gebracht. Maar er is geen machtigingsregel voor ESP. Blijkbaar verwarde de student icmp en esp.
De toegangslijst bewerken:
Gate2(config)#
ip access-list extended L3VPN
no 30
30 permit esp host 10.10.10.251 anyStap 6. Functionaliteit controleren
Allereerst zorg ik ervoor dat de L3VPN-toegangslijst correct is:
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 start ik doelverkeer vanaf apparaat 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 msZege. De GRE-tunnel is aangelegd. De teller voor inkomend verkeer in IPsec-statistieken is niet nul:
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 480Op de Gate2-gateway verschenen in de klogview-uitvoer berichten dat het doelverkeer 172.16.0.1->172.17.0.1 met succes was gedecodeerd (PASS) door de LIST-regel in de CMAP-cryptokaart:
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: decapsulatedResultaten van
Een student verpestte zijn vrije dag.
Wees voorzichtig met de ME-regels.
Anonieme ingenieur
t.me/anonieme_ingenieur
Bron: www.habr.com