Sytuacja
Zamykam. Piję kawę. Student skonfigurował połączenie VPN między dwoma punktami i zniknął. Sprawdzam: tunel rzeczywiście istnieje, ale w tunelu nie ma ruchu. Na połączenia telefoniczne student nie odpowiada.
Zarządzam czajnikiem i zagłębiam się w troubleshooting z C-Terra Gateway. Dzielę się swoim doświadczeniem i metodologią.
Dane źródłowe
Dwa terytorialnie oddzielone lokalizacje są połączone tunelami GRE. Należy zaszyfrować GRE:
Sprawdzam funkcjonalność tunelu GRE. W tym celu uruchamiam ping z urządzenia R1 do interfejsu GRE urządzenia R2. To jest docelowy ruch do zaszyfrowania. Brak odpowiedzi:
root@R1:~# ping 1.1.1.2 -c 4
PING 1.1.1.2 (1.1.1.2) 56(84) bajtów danych.
--- statystyki ping 1.1.1.2 ---
4 pakiety wysłane, 0 odebranych, 100% utraty pakietów, czas 3057msSprawdzam logi na Gate1 i Gate2. Log z radością informuje, że tunel IPsec został pomyślnie ustanowiony, brak problemów:
root@Gate1:~# cat /var/log/cspvpngate.log
5 sie 16:14:23 localhost vpnsvc: 00100119 Połączenie IPSec 5 nawiązane, selektor ruchu 172.17.0.1->172.16.0.1, proto 47, peer 10.10.10.251, id "10.10.10.251", Przygotowanie IPsec: Protect:CMAP:1:LIST, IPsecAction IPsecAction:CMAP:1, IKERule IKERule:CMAP:1W statystykach tunelu IPsec na Gate1 widzę, że tunel rzeczywiście istnieje, ale licznik Rcvd jest zerowy:
root@Gate1:~# sa_mgr show
Sesje ISAKMP: 0 zainicjowanych, 0 odpowiedzianych
Połączenia ISAKMP:
Num Conn-id (Adres lokalny, Port)-(Adres zdalny, Port) Stan Wysłane Otrzymane
1 3 (10.10.10.251,500)-(10.10.10.252,500) aktywne 1070 1014
Połączenia IPsec:
Num Conn-id (Adres lokalny, Port)-(Adres zdalny, Port) Protokół Typ Akcji Wysłane Otrzymane
1 3 (172.16.0.1,*)-(172.17.0.1,*) 47 ESP tunel 480 0Troubleshootuję C-Terrę w ten sposób: szukam, gdzie giną docelowe pakiety na drodze od R1 do R2. W trakcie (spoiler) znajdę błąd.
Rozwiązywanie problemów
Krok 1. Co otrzymuje Gate1 od R1
Używam wbudowanego sniffera pakietów – tcpdump. Uruchamiam sniffer na interfejsie wewnętrznym (Gi0/1 w notacji Cisco-like lub eth1 w notacji systemu Debian):
root@Gate1:~# tcpdump -i eth1
tcpdump: wyjście szczegółowe jest ukryte, użyj -v lub -vv, aby uzyskać pełny dekodowanie protokołu
nasłuchując na eth1, typ linku EN10MB (Ethernet), rozmiar przechwytywania 262144 bajtów
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 64Widzę, że Gate1 otrzymuje od R1 pakiety GRE. Przechodzę dalej.
Krok 2. Co Gate1 robi z pakietami GRE
Używając narzędzia klogview, sprawdzam, co dzieje się z pakietami GRE wewnątrz VPN sterownika C-Terra:
root@Gate1:~# klogview -f 0xffffffff
wynik filtracji dla pakietu wyjściowego 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0: łańcuch 4 "IPsecPolicy:CMAP", filtr 8, identyfikator zdarzenia IPsec:Protect:CMAP:1:LIST, status PASS
enkapsulacja z SA 31: 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0
przeszedł pakiet wyjściowy 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: enkapsulowany
Widzę, że docelowy ruch GRE (proto 47) 172.16.0.1 -> 172.17.0.1 przeszedł (PASS) przez regułę szyfrowania LIST w mapie kryptograficznej CMAP i został zaszyfrowany (enkapsulowany). Następnie pakiet został przekierowany (passed out). Nie ma ruchu zwrotnego w wyjściu klogview.
Sprawdzam listy dostępu na urządzeniu Gate1. Widzę jedną listę dostępu LIST, która określa docelowy ruch do szyfrowania, więc reguły MЭ nie zostały skonfigurowane:
Gate1#show access-lists
Rozszerzona lista dostępu IP LIST
10 zezwól gre host 172.16.0.1 host 172.17.0.1Wynik: problem nie leży w urządzeniu Gate1.
Dodatkowe informacje o klogview
Sterownik VPN obsługuje cały ruch sieciowy, nie tylko ten, który powinien być szyfrowany. Takie komunikaty są widoczne w klogview, jeśli sterownik VPN obsłużył ruch sieciowy i przekazał go w niezabezpieczonej postaci:
root@R1:~# ping 172.17.0.1 -c 4root@Gate1:~# klogview -f 0xffffffff
wynik filtracji dla pakietu wyjściowego 172.16.0.1->172.17.0.1, proto 1, len 84, if eth0: łańcuch 4 "IPsecPolicy:CMAP": brak dopasowania
przeszedł pakiet wyjściowy 172.16.0.1->172.17.0.1, proto 1, len 84, if eth0: przefiltrowanyWidzę, że ruch ICMP (proto 1) 172.16.0.1->172.17.0.1 nie przeszedł (brak dopasowania) w reguły szyfrowania mapy kryptograficznej CMAP. Pakiet został przekierowany (przeszedł na zewnątrz) w otwartej postaci.
Krok 3. Co Gate2 otrzymuje od Gate1
Uruchamiam sniffer na interfejsie WAN (eth0) Gate2:
root@Gate2:~# tcpdump -i eth0
tcpdump: wyjście szczegółowe stłumione, użyj -v lub -vv dla pełnego dekodowania protokołu
nasłuchiwanie na eth0, typ połączenia EN10MB (Ethernet), rozmiar zapisu 262144 bajtów
16:05:45.104195 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x1), długość 140
16:05:46.093918 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x2), długość 140
16:05:47.117078 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x3), długość 140
16:05:48.141785 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x4), długość 140Widzę, że Gate2 otrzymuje pakiety ESP od Gate1.
Krok 4. Co Gate2 robi z pakietami ESP
Uruchamiam narzędzie klogview na Gate2:
root@Gate2:~# klogview -f 0xffffffff
wynik filtracji dla pakietu przychodzącego 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: łańcuch 17 "FilterChain:L3VPN", filtr 21, status DROP
dropping pakiet przychodzący 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: firewall
Widzę, że pakiety ESP (proto 50) zostały odrzucone (DROP) przez regułę (L3VPN) zapory sieciowej (firewall). Upewniam się, że lista dostępu L3VPN jest rzeczywiście przypisana do Gi0/0:
Gate2#show ip interface gi0/0
GigabitEthernet0/0 działa, protokół linii działa
Adres internetowy to 10.10.10.252/24
MTU to 1500 bajtów
Lista dostępu wychodzącego nie jest ustawiona
Lista dostępu przychodzącego to L3VPNProblem zidentyfikowany.
Krok 5. Co jest nie tak z listą dostępu
Patrzę, jak wygląda lista dostępu 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 anyWidzę, że pakiety ISAKMP są dozwolone, więc ustalany jest tunel IPsec. Jednak brak reguły zezwalającej dla ESP. Wygląda na to, że student pomylił icmp i esp.
Poprawiam listę dostępu:
Gate2(config)#
ip access-list extended L3VPN
no 30
30 permit esp host 10.10.10.251 anyKrok 6. Sprawdzam działanie
Na początku upewniam się, że lista dostępu L3VPN jest poprawna:
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 anyTeraz z urządzenia R1 uruchamiam docelowy ruch:
root@R1:~# ping 1.1.1.2 -c 4
PING 1.1.1.2 (1.1.1.2) 56(84) bajtów danych.
64 bajty z 1.1.1.2: icmp_seq=1 ttl=64 czas=35.3 ms
64 bajty z 1.1.1.2: icmp_seq=2 ttl=64 czas=3.01 ms
64 bajty z 1.1.1.2: icmp_seq=3 ttl=64 czas=2.65 ms
64 bajty z 1.1.1.2: icmp_seq=4 ttl=64 czas=2.87 ms
--- statystyki ping 1.1.1.2 ---
4 pakiety wysłane, 4 odebrane, 0% utraty pakietów, czas 3006ms
rtt min/avg/max/mdev = 2.650/10.970/35.338/14.069 msZwycięstwo. Tunel GRE został ustanowiony. Licznik ruchu przychodzącego w statystyce IPsec jest niezerowy:
root@Gate1:~# sa_mgr show
Sesje ISAKMP: 0 inicjowanych, 0 odpowiedzianych
Połączenia ISAKMP:
Num Conn-id (Adres lokalny, Port)-(Adres zdalny, Port) Stan Wysłane Odebrane
1 3 (10.10.10.251,500)-(10.10.10.252,500) aktywne 1474 1350
Połączenia IPsec:
Num Conn-id (Adres lokalny, Port)-(Adres zdalny, Port) Protokół Akcja Typ Wysłane Odebrane
1 4 (172.16.0.1,*)-(172.17.0.1,*) 47 ESP tunn 1920 480Na bramie Gate2 w wyjściu klogview pojawiły się komunikaty, że ruch docelowy 172.16.0.1->172.17.0.1 został pomyślnie (PASS) odszyfrowany (decapsulated) przez regułę LIST w mapie kryptograficznej CMAP:
root@Gate2:~# klogview -f 0xffffffff
wynik filtracji dla pakietu przychodzącego 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0: łańcuch 18 "IPsecPolicy:CMAP", filtr 25, id zdarzenia IPsec:Protect:CMAP:1:LIST, status PASS
przeszło w pakiecie 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0: odszyfrowanePodsumowanie
Student zepsuł wynik.
Uważaj na reguły MЭ.
Anonimowy inżynier
t.me/anonimous_engineer
Źródło: habr.com
