ProHoster > Blog > yönetim > Yerel IPsec VPN ile ilgili sorunlar nasıl giderilir? Bölüm 1

Yerel IPsec VPN ile ilgili sorunlar nasıl giderilir? Bölüm 1

Yerel IPsec VPN ile ilgili sorunlar nasıl giderilir? Bölüm 1

Durum

İzin günü. Kahve içerim. Öğrenci iki nokta arasında VPN bağlantısı kurarak ortadan kayboldu. Kontrol ediyorum: Gerçekten bir tünel var ama tünelde trafik yok. Öğrenci çağrılara cevap vermiyor.

Su ısıtıcıyı ocağa koydum ve S-Terra Ağ Geçidi sorun giderme işlemine daldım. Deneyimlerimi ve metodolojimi paylaşıyorum.

Ham veriler

Coğrafi olarak ayrılmış iki bölge bir GRE tüneli ile birbirine bağlanıyor. GRE'nin şifrelenmesi gerekiyor:

Yerel IPsec VPN ile ilgili sorunlar nasıl giderilir? Bölüm 1

GRE tünelinin işlevselliğini kontrol ediyorum. Bunu yapmak için R1 cihazından R2 cihazının GRE arayüzüne ping çalıştırıyorum. Bu, şifreleme için hedef trafiktir. Cevapsız:

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

Gate1 ve Gate2'deki kayıtlara bakıyorum. Günlük mutlu bir şekilde IPsec tünelinin başarıyla başlatıldığını, hiçbir sorun olmadığını bildiriyor:

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

Gate1'deki IPsec tünelinin istatistiklerinde gerçekten bir tünel olduğunu görüyorum, ancak Rсvd sayacı sıfıra sıfırlandı:

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

S-Terra'yı şu şekilde rahatsız ediyorum: R1'den R2'ye giden yolda hedef paketlerin nerede kaybolduğunu arıyorum. Bu süreçte (spoiler) bir hata bulacağım.

Sorun giderme

Adım 1. Gate1, R1'den ne alır?

Yerleşik paket dinleyicisini kullanıyorum - tcpdump. Algılayıcıyı dahili (Cisco benzeri gösterimde Gi0/1 veya Debian OS gösteriminde eth1) arayüzde başlatıyorum:

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

Gate1'in R1'den GRE paketleri aldığını görüyorum. Devam ediyorum.

Adım 2. Gate1, GRE paketleriyle ne yapar?

Klogview yardımcı programını kullanarak S-Terra VPN sürücüsünün içindeki GRE paketlerinde neler olduğunu görebiliyorum:

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

Hedef GRE trafiğinin (proto 47) 172.16.0.1 -> 172.17.0.1'in CMAP kripto haritasında LIST şifreleme kuralına girdiğini ve kapsüllendiğini görüyorum. Daha sonra paket yönlendirildi (dağıtıldı). Klogview çıkışında yanıt trafiği yok.

Gate1 cihazındaki erişim listelerini kontrol ediyorum. Şifreleme için hedef trafiği tanımlayan bir erişim listesi LIST görüyorum; bu, güvenlik duvarı kurallarının yapılandırılmadığı anlamına gelir:

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

Sonuç: Sorun Gate1 cihazında değil.

klogview hakkında daha fazla bilgi

VPN sürücüsü yalnızca şifrelenmesi gereken trafiği değil, tüm ağ trafiğini yönetir. VPN sürücüsünün ağ trafiğini işlemesi ve şifrelenmeden iletmesi durumunda klogview'de görünen mesajlar şunlardır:

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

CMAP kripto kartının şifreleme kurallarına ICMP trafiğinin (proto 1) 172.16.0.1->172.17.0.1 dahil edilmediğini (eşleşme yok) görüyorum. Paket açık metin olarak yönlendirildi (dağıtıldı).

Adım 3. Kapı2, Kapı1'den ne alır?

Sniffer'ı WAN (eth0) Gate2 arayüzünde başlatıyorum:

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

Gate2'nin Gate1'den ESP paketleri aldığını görüyorum.

Adım 4. Gate2, ESP paketleriyle ne yapar?

Gate2'de klogview yardımcı programını başlatıyorum:

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

ESP paketlerinin (proto 50) güvenlik duvarı kuralı (L3VPN) tarafından bırakıldığını (DROP) görüyorum. Gi0/0'ın aslında bir L3VPN erişim listesine bağlı olduğundan emin oluyorum:

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

Sorunu keşfettim.

5. Adım. Erişim listesindeki sorun nedir?

L3VPN erişim listesinin ne olduğuna bakıyorum:

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

ISAKMP paketlerine izin verildiğini görüyorum, dolayısıyla bir IPsec tüneli kuruluyor. Ancak ESP için etkinleştirme kuralı yoktur. Görünüşe göre öğrenci icmp ve esp'yi karıştırdı.

Erişim listesini düzenleme:

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

Adım 6. İşlevselliğin kontrol edilmesi

Öncelikle L3VPN erişim listesinin doğru olduğundan emin oluyorum:

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

Şimdi hedef trafiği R1 cihazından başlatıyorum:

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

Zafer. GRE tüneli kuruldu. IPsec istatistiklerindeki gelen trafik sayacı sıfır değil:

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

Gate2 ağ geçidinde, klogview çıktısında, 172.16.0.1->172.17.0.1 hedef trafiğinin şifresinin, CMAP kripto haritasındaki LIST kuralı tarafından başarıyla çözüldüğüne (PASS) ilişkin mesajlar belirdi:

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

sonuçlar

Bir öğrenci izin gününü mahvetti.
ME kurallarına dikkat edin.

anonim mühendis
t.me/anonymous_engineer

Kaynak: habr.com

Yorum ekle