د کورني IPsec VPN ستونزې حل کولو څرنګوالی. برخه 1

د کورني IPsec VPN ستونزې حل کولو څرنګوالی. برخه 1

وضعیت

ورځ رخصت. زه قهوه څښم. زده کونکي د دوه ټکو ترمینځ VPN اړیکه جوړه کړه او ورک شو. زه ګورم: واقعیا یو تونل دی، مګر په تونل کې هیڅ ترافیک نشته. زده کوونکی زنګونو ته ځواب نه ورکوي.

ما کیتلی واچاوه او د S-Terra Gateway ستونزې حل کولو کې ډوب شوم. زه خپله تجربه او میتودولوژي شریکوم.

د سرچینې ډاټا

دوه جغرافیه جلا شوي سایټونه د GRE تونل لخوا وصل شوي. GRE باید کوډ شي:

د کورني IPsec VPN ستونزې حل کولو څرنګوالی. برخه 1

زه د GRE تونل فعالیت ګورم. د دې کولو لپاره ، زه د وسیلې R1 څخه د وسیلې R2 GRE انٹرفیس ته ping چلوم. دا د کوډ کولو لپاره هدف ترافیک دی. ځواب نشته:

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 او Gate2 کې لاګونه ګورم. لاګ په خوښۍ سره راپور ورکوي چې د IPsec تونل په بریالیتوب سره پیل شوی، کومه ستونزه نشته:

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

په ګیټ 1 کې د IPsec تونل په احصایو کې زه ګورم چې واقعیا یو تونل شتون لري ، مګر د Rсvd کاونټر صفر ته بیا تنظیم شوی:

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 په څیر ستونزه لرم: زه د R1 څخه تر R2 پورې لاره کې د هدف کڅوړې چیرته ورک شوي دي. په پروسه کې (سپیلر) زه به یوه غلطي ومومم.

د ستونزو حل کول

مرحله 1. کوم ګیټ 1 د R1 څخه ترلاسه کوي

زه د جوړ شوي پیکټ سنیفیر کاروم - tcpdump. زه په داخلي کې سنیففر پیلوم (Gi0/1 د سیسکو په څیر نوټیشن کې یا eth1 په 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

زه ګورم چې ګیټ 1 د R1 څخه د GRE پاکټونه ترلاسه کوي. زه روان یم

2 ګام. ګیټ 1 د GRE پاکټونو سره څه کوي

د کلوګ ویو افادیت په کارولو سره زه کولی شم وګورم چې د S-Terra VPN ډرایور دننه د GRE پاکټونو سره څه پیښیږي:

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

زه ګورم چې د هدف GRE ترافیک (پروټو 47) 172.16.0.1 -> 172.17.0.1 د CMAP کریپټو نقشه کې د لیست کوډ کولو قاعدې لاندې راغلی او پوښل شوی. بیا، پاکټ راوتلی (پاس شوی). د کلوګ ویو محصول کې هیڅ غبرګون ترافیک شتون نلري.

زه د ګیټ 1 وسیله کې د لاسرسي لیستونه ګورم. زه یو د لاسرسي لیست لیست ګورم، کوم چې د کوډ کولو لپاره د هدف ټرافیک تعریفوي، پدې معنی چې د فایر وال قواعد ترتیب شوي ندي:

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

پایله: ستونزه د Gate1 وسیلې سره نه ده.

د klogview په اړه نور

د VPN ډرایور ټول د شبکې ترافیک اداره کوي ، نه یوازې هغه ترافیک چې کوډ کولو ته اړتیا لري. دا هغه پیغامونه دي چې په کلوګ ویو کې لیدل کیږي که چیرې د VPN ډرایور د شبکې ترافیک پروسس کړي او غیر کوډ شوي لیږد کړي:

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

زه ګورم چې د ICMP ترافیک (proto 1) 172.16.0.1->172.17.0.1 د CMAP کریپټو کارت د کوډ کولو قواعدو کې شامل نه و (هیڅ لوبه نه وه). پاکټ په روښانه متن کې راوتلی (پاس شوی).

مرحله 3. هغه څه چې ګیټ 2 د ګیټ 1 څخه ترلاسه کوي

زه په 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

زه ګورم چې Gate2 د Gate1 څخه د ESP پاکټونه ترلاسه کوي.

4 ګام. Gate2 د ESP کڅوړو سره څه کوي

زه په ګیټ 2 کې د کلوګ ویو افادیت پیلوم:

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 پاکټونه (پروټو 50) د فائر وال قاعدې (L3VPN) لخوا غورځول شوي (DROP). زه ډاډه یم چې Gi0/0 په حقیقت کې د 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

ما ستونزه وموندله.

مرحله 5. د لاسرسي لیست سره څه غلط دي

زه ګورم چې د 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

زه ګورم چې د ISAKMP پاکټونو ته اجازه ورکړل شوې، نو د IPsec تونل تاسیس شوی. مګر د ESP لپاره هیڅ وړ قواعد شتون نلري. په ښکاره ډول، زده کوونکی د icmp او esp ګډوډ کړی.

د لاسرسي لیست ترمیم کول:

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

6 ګام. د فعالیت چک کول

له هرڅه دمخه ، زه ډاډه یم چې د 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 esp host 10.10.10.251 any

اوس زه د 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

بریا. د GRE تونل تاسیس شوی. په IPsec احصایو کې د راتلونکي ترافیک کاونټر صفر ندی:

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 gateway کې، د کلوګ ویو په محصول کې، پیغامونه ښکاره شول چې د هدف ټرافيک 172.16.0.1->172.17.0.1 په بریالیتوب سره د CMAP کریپټو نقشه کې د لیست قاعدې لخوا (PASS) ډیکریټ شوی:

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

پایلې

یوه محصل خپله ورځ خرابه کړه.
د ME قواعدو سره محتاط اوسئ.

نامعلوم انجینر
t.me/anonymous_engineer


سرچینه: www.habr.com

Add a comment