🥇Cumu risolve i prublemi di VPN IPsec domestica. Parte 1

A situazione

Ghjornu off. Beiu caffè. U studiente hà stallatu una cunnessione VPN trà dui punti è hè sparitu. Cuntrolla: ci hè veramente un tunnel, ma ùn ci hè micca trafficu in u tunnel. U studiente ùn risponde micca à e chjama.

Aghju messu u bollitore è immerse in a risoluzione di prublemi di S-Terra Gateway. Aghju sparte a mo sperienza è metodulugia.

Dati iniziali

I dui siti geograficamente separati sò cunnessi da un tunnel GRE. GRE deve esse criptatu:

Aghju verificatu a funziunalità di u tunnel GRE. Per fà questu, aghju eseguitu ping da u dispusitivu R1 à l'interfaccia GRE di u dispusitivu R2. Questu hè u trafficu di destinazione per a criptografia. Nisuna risposta:

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

Fighjulà i logs nantu à Gate1 è Gate2. U logu informa felicemente chì u tunnel IPsec hè statu lanciatu cù successu, senza prublemi:

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

In e statistiche di u tunnel IPsec in Gate1, vecu chì ci hè veramente un tunnel, ma u contatore Rсvd hè resettatu à 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 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

I prublemi S-Terra cusì: cercu induve i pacchetti di destinazione sò persi nantu à a strada da R1 à R2. In u prucessu (spoiler) truverete un sbagliu.

Risoluzione di prublemi

Passu 1. Chì Gate1 riceve da R1

Aghju utilizatu u sniffer di pacchettu integratu - tcpdump. Lanciau u sniffer nantu à l'interfaccia interna (Gi0/1 in notazione Cisco-like o eth1 in notation Debian OS):

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

Vecu chì Gate1 riceve pacchetti GRE da R1. Aghju avanzatu.

Passu 2. Chì Gate1 faci cù i pacchetti GRE

Utilizendu l'utilità klogview possu vede ciò chì succede cù i pacchetti GRE in u driver VPN S-Terra:

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

Vecu chì u trafficu GRE di destinazione (proto 47) 172.16.0.1 -> 172.17.0.1 hè vinutu sottu a regula di criptografia di LIST in a mappa di criptu CMAP è hè stata incapsulata. In seguitu, u pacchettu hè statu instradatu (passatu). Ùn ci hè micca un trafficu di risposta in l'output di klogview.

Sò cuntrollà i listi d'accessu nantu à u dispusitivu Gate1. Veju una lista d'accessu LIST, chì definisce u trafficu di destinazione per a criptografia, chì significa chì e regule di firewall ùn sò micca cunfigurati:

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

Conclusioni: u prublema ùn hè micca cù u dispusitivu Gate1.

Più nantu à klogview

U cunduttore VPN gestisce tuttu u trafficu di a rete, micca solu u trafficu chì deve esse criptatu. Quessi sò i missaghji visibili in klogview se u driver VPN hà trattatu u trafficu di a rete è l'hà trasmessu senza criptu:

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

Vecu chì u trafficu ICMP (proto 1) 172.16.0.1-> 172.17.0.1 ùn era micca inclusu (senza match) in i reguli di criptografia di a carta di criptu CMAP. U pacchettu hè statu mandatu (passatu) in testu chjaru.

Step 3. Chì Gate2 riceve da Gate1

Lanciau u sniffer nantu à l'interfaccia 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

Vecu chì Gate2 riceve i pacchetti ESP da Gate1.

Step 4. Chì Gate2 faci cù i pacchetti ESP

Lanciau l'utilità klogview in 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

Vecu chì i pacchetti ESP (proto 50) sò stati abbandunati (DROP) da a regula di firewall (L3VPN). Aghju assicuratu chì Gi0/0 hà veramente una lista di accessu L3VPN attaccata à questu:

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

Aghju scupertu u prublema.

Step 5. Cosa hè male cù a lista di accessu

Fighjulu ciò chì hè a lista di accessu 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

Vecu chì i pacchetti ISAKMP sò permessi, cusì un tunnel IPsec hè stabilitu. Ma ùn ci hè micca una regula di attivazione per ESP. Apparentemente, u studiente hà cunfunditu icmp è esp.

Edite a lista di accessu:

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

Step 6. Cuntrollà funziunalità

Prima di tuttu, aghju assicuratu chì a lista di accessu L3VPN hè curretta:

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

Avà lanciau u trafficu di destinazione da u dispusitivu 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

Vittoria. U tunnel GRE hè statu stabilitu. U contatore di trafficu entrante in statistiche IPsec ùn hè micca 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

Nantu à a porta Gate2, in l'output di klogview, i missaghji apparsu chì u trafficu di destinazione 172.16.0.1-> 172.17.0.1 hè statu decriptatu cù successu (PASS) da a regula LIST in a mappa di criptu 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

Risultati

Un studiente hà arruvinatu u so ghjornu.
Attenti à e regule ME.

Ingegnere anonimu
t.me/anonymous_engineer

Source: www.habr.com

Cumu risolve u prublema IPsec VPN domestica. Parte 1

A situazione

Dati iniziali

Risoluzione di prublemi

Add a comment annuler risponde