ProHoster > Blog > administracja > Jak rozwiązywać problemy z krajowymi VPN IPsec. Część 1

Jak rozwiązywać problemy z krajowymi VPN IPsec. Część 1

Jak rozwiązywać problemy z krajowymi VPN IPsec. Część 1

Sytuacja

Dzień wolny. Piję kawę. Student skonfigurował połączenie VPN pomiędzy dwoma punktami i zniknął. Sprawdzam: rzeczywiście jest tunel, ale w tunelu nie ma ruchu. Student nie odbiera telefonów.

Włączam czajnik i zagłębiam się w rozwiązywanie problemów z bramką S-Terra Gateway. Dzielę się swoim doświadczeniem i metodologią.

Surowe dane

Obydwa geograficznie od siebie oddalone miejsca są połączone tunelem GRE. GRE wymaga szyfrowania:

Jak rozwiązywać problemy z krajowymi VPN IPsec. Część 1

Sprawdzam funkcjonalność tunelu GRE. W tym celu uruchamiam polecenie ping z urządzenia R1 do interfejsu GRE urządzenia R2. Jest to ruch docelowy dla szyfrowania. Brak odpowiedzi:

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

Patrzę na logi Gate1 i Gate2. Dziennik szczęśliwie informuje, że tunel IPsec został pomyślnie uruchomiony, bez problemów:

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

W statystykach tunelu IPsec na Gate1 widzę, że rzeczywiście tunel jest, ale licznik Rсvd jest wyzerowany:

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

Mam taki problem z S-Terra: szukam miejsca, w którym pakiety docelowe zostały utracone na ścieżce od R1 do R2. W trakcie (spoiler) znajdę błąd.

Rozwiązywanie problemów

Krok 1. Co Gate1 otrzymuje od R1

Używam wbudowanego sniffera pakietów - tcpdump. Uruchamiam sniffer na wewnętrznym interfejsie (Gi0/1 w notacji podobnej do Cisco lub eth1 w notacji systemu operacyjnego 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

Widzę, że Brama 1 odbiera pakiety GRE od R1. Ruszam do przodu.

Krok 2. Co Gate1 robi z pakietami GRE

Korzystając z narzędzia klogview, mogę zobaczyć, co dzieje się z pakietami GRE w sterowniku S-Terra 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

Widzę, że docelowy ruch GRE (proto 47) 172.16.0.1 -> 172.17.0.1 podlegał regule szyfrowania LIST na mapie kryptograficznej CMAP i został hermetyzowany. Następnie pakiet został trasowany (przepuszczony). W wynikach klogview nie ma ruchu odpowiedzi.

Sprawdzam listy dostępu na urządzeniu Gate1. Widzę jedną listę dostępu LIST, która definiuje ruch docelowy dla szyfrowania, co oznacza, że ​​reguły zapory sieciowej nie są skonfigurowane:

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

Wniosek: problem nie dotyczy urządzenia Gate1.

Więcej o klogview

Sterownik VPN obsługuje cały ruch sieciowy, a nie tylko ten, który wymaga szyfrowania. Oto komunikaty widoczne w klogview jeśli sterownik VPN przetworzył ruch sieciowy i przekazał go w postaci niezaszyfrowanej:

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

Widzę, że ruch ICMP (proto 1) 172.16.0.1->172.17.0.1 nie został uwzględniony (brak dopasowania) w regułach szyfrowania karty kryptograficznej CMAP. Pakiet został przesłany (rozesłany) w postaci zwykłego tekstu.

Krok 3. Co Gate2 otrzymuje od Gate1

Uruchamiam sniffer na interfejsie 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

Widzę, że Brama2 odbiera pakiety ESP z Bramy1.

Krok 4. Co Gate2 robi z pakietami ESP

Uruchamiam narzędzie klogview na 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

Widzę, że pakiety ESP (proto 50) zostały odrzucone (DROP) przez regułę zapory sieciowej (L3VPN). Upewniam się, że Gi0/0 rzeczywiście ma dołączoną listę dostępu 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

Odkryłem problem.

Krok 5. Co jest nie tak z listą dostępu

Patrzę, jaka jest 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 any

Widzę, że pakiety ISAKMP są dozwolone, więc ustanawiany jest tunel IPsec. Nie ma jednak reguły włączającej ESP. Najwyraźniej uczeń pomylił icmp i esp.

Edycja listy dostępu:

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

Krok 6. Sprawdzenie funkcjonalności

Przede wszystkim upewniam się, że lista dostępowa 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 any

Teraz uruchamiam ruch docelowy z urządzenia 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

Zwycięstwo. Tunel GRE został zbudowany. Licznik ruchu przychodzącego w statystykach IPsec nie wynosi zero:

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

Na bramce Gate2 w wyjściu klogview pojawiły się komunikaty, że ruch docelowy 172.16.0.1->172.17.0.1 został pomyślnie odszyfrowany (PASS) za pomocą reguły LIST na mapie kryptograficznej 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

Wyniki

Student zrujnował mu dzień wolny.
Uważaj na zasady ME.

Anonimowy inżynier
t.me/anonymous_inżynier

Źródło: www.habr.com

Dodaj komentarz