ProHoster > Blog > Administrimi > Si të zgjidhni problemet me IPsec VPN të brendshëm. Pjesa 1

Si të zgjidhni problemet me IPsec VPN të brendshëm. Pjesa 1

Si të zgjidhni problemet me IPsec VPN të brendshëm. Pjesa 1

Situata

E diela. Po piq kafe. Një student ka vendosur një lidhje VPN mes dy pikave dhe ka zhdukur. Po kontrolloj: tuneli vërtet ekziston, por nuk ka trafik në tunel. Studentit nuk i përgjigjem në telefon.

Po vendos një çajnik dhe po shpërndaj përvojën time në troubleshooting-in e C-Terra Gateway. Po ndaj përvojën dhe metodologjinë time.

Të dhënat fillestare

Dy vende të ndara hapësinorisht janë të lidhura me një tunel GRE. Duhet të enkriptojmë GRE-në:

Si të zgjidhni problemet me IPsec VPN të brendshëm. Pjesa 1

Po kontrolloj funksionimin e tunelit GRE. Për këtë, filloj ping nga pajisja R1 në ndërfaqen GRE të pajisjes R2. Ky është trafiku që do të enkriptohet. Nuk kam përgjigje:

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

Po shikoj log-et në Gate1 dhe Gate2. Log-u me gëzim raporton se tuneli IPsec është ngritur me sukses, nuk ka probleme:

root@Gate1:~# cat /var/log/cspvpngate.log
Aug  5 16:14:23 localhost  vpnsvc: 00100119  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

Në statistikat e tunelit IPsec në Gate1 shoh se tuneli vërtet ekziston, por numri Rcvd është 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

Unë po bëj troubleshooting në C-Terra kështu: po kërkoj ku humbasin paketat e synuara nga R1 në R2. Gjatë procesit (spoiler) do të gjej një gabim.

Troubleshooting

Hapi 1. ÇfarĂ« merr Gate1 nga R1

Po pĂ«rdor sniffer-in e integruar – tcpdump. Filloj sniffer-in nĂ« ndĂ«rfaqen e brendshme (Gi0/1 nĂ« notacion Cisco-like ose eth1 nĂ« notacionin e OS 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

Po shikoj se Gate1 merr paketa GRE nga R1. Po lëviz më tej.

Hapi 2. ÇfarĂ« bĂ«n Gate1 me paketat GRE

Me utilitarin klogview shikoj se çfarë po ndodh me paketat GRE brenda VPN drejtuesit të C-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

Po shikoj se se trafiku GRE të synuar (proto 47) 172.16.0.1 -> 172.17.0.1 i është nënshtruar (PASS) rregullit të enkriptimit LIST në hartën e kriptimit CMAP dhe është enkriptuar (encapsulated). Më tej paketa është rrugëzuar (passed out). Nuk ka trafik përgjigjeje në rezultatin e klogview.

Po kontrolloj listat e qasjes në pajisjen Gate1. Shikoj një listë qasje LIST, e cila përcakton trafikun e synuar për enkriptim, kështu që nuk janë konfiguruar rregulla MEP:

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

Përfundimi: problemi nuk është në pajisjen Gate1.

Më shumë rreth klogview

Drejtuesi VPN përpunon të gjithë trafikun rrjet, jo vetëm atë që duhet të enkriptohet. Ky mesazh duket në klogview, nëse drejtuesi VPN përpunoi trafikun rrjet dhe e dërgoi atë në formë të paenkriptuar:

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

Po shikoj se se trafiku ICMP (proto 1) 172.16.0.1->172.17.0.1 nuk është nënshtruar (no match) rregullave të enkriptimit të hartës së kriptimit CMAP. Paketa është rrugëzuar (passed out) në mënyrë të hapur.

Hapi 3. ÇfarĂ« merr Gate2 nga Gate1

Filloj një sniffer në ndërfaqen WAN (eth0) të 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

Po shikoj se se Gate2 merr paketa ESP nga Gate1.

Hapi 4. ÇfarĂ« bĂ«n Gate2 me paketat ESP

Filloj utilitarin klogview në 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

Po shikoj se paketa ESP (proto 50) janë hequr (DROP) nga rregulli (L3VPN) të firewall-it. Po konfirmoj se lista e qasjes L3VPN është me të vërtetë e lidhur me Gi0/0:

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

Kam identifikuar problemin.

Hapi 5. ÇfarĂ« nuk shkon me listĂ«n e qasjes

Po shikoj se si duket lista e qasjes 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

Shikoj se janë të lejuara paketat ISAKMP, prandaj po krijohet një tunel IPsec. Megjithatë, nuk ka rregull lehtësues për ESP. Duket se studenti ka ngatërruar icmp dhe esp.

Po korrigjoj listën e aksesit:

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

Hapi 6. Po kontrolloj funksionalitetin

Së pari, po sigurohem që lista e aksesit L3VPN është e saktë:

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

Tani nga pajisja R1 po nisin trafikun e synuar:

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

Fitorja. Tuneli GRE është krijuar. Numri i trafikut të hyrshëm në statistikën IPsec nuk është 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

Në portin Gate2 në rezultatin klogview janë shfaqur mesazhe se trafiku synuar 172.16.0.1->172.17.0.1 është dekapsuluar me sukses (PASS) nga rregulli LIST në hartën e enkriptimit 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

PĂ«rfundimet

Studenti ka prish rezultatin.
Kujdes mĂ« me rregullat e MË.

Inxhinier anonim
t.me/anonimous_engineer

Burimi: habr.com

Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster