ProHoster > Օրագիր > Վարչակազմը > Ինչպես լուծել ներքին IPsec VPN-ի անսարքությունները: Մաս 1

Ինչպես լուծել ներքին IPsec VPN-ի անսարքությունները: Մաս 1

Ինչպես լուծել ներքին IPsec VPN-ի անսարքությունները: Մաս 1

Իրավիճակը

Հանգստի օր. սուրճ եմ խմում։ Ուսանողը երկու կետերի միջև VPN կապ է ստեղծել և անհետացել: Ստուգում եմ՝ իսկապես թունել կա, բայց թունելում երթեւեկություն չկա։ Ուսանողը չի պատասխանում զանգերին.

Ես դնում եմ թեյնիկը և սուզվում եմ S-Terra Gateway-ի անսարքությունների վերացման մեջ: Կիսվում եմ իմ փորձով և մեթոդաբանությամբ:

Նախնական տվյալներ

Աշխարհագրորեն բաժանված երկու տեղամասերը միացված են GRE թունելով: GRE-ն պետք է կոդավորված լինի.

Ինչպես լուծել ներքին IPsec VPN-ի անսարքությունները: Մաս 1

Ես ստուգում եմ GRE թունելի ֆունկցիոնալությունը: Դա անելու համար ես կատարում եմ Ping R1 սարքից R2 սարքի GRE ինտերֆեյս: Սա գաղտնագրման թիրախային տրաֆիկն է: Պատասխան չկա:

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

Gate1-ի 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. Ինչ է Gate1-ը ստանում R1-ից

Ես օգտագործում եմ ներկառուցված փաթեթների sniffer - tcpdump: Ես գործարկում եմ sniffer-ը ներքին (Gi0/1 Cisco-ի նման նշումով կամ 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

Ես տեսնում եմ, որ Gate1-ը ստանում է GRE փաթեթներ R1-ից: Ես առաջ եմ գնում:

Քայլ 2. Ինչ է անում Gate1-ը GRE փաթեթների հետ

Օգտագործելով klogview կոմունալ ծրագիրը, ես կարող եմ տեսնել, թե ինչ է կատարվում GRE փաթեթների հետ 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

Ես տեսնում եմ, որ թիրախային GRE տրաֆիկը (պրոտո 47) 172.16.0.1 -> 172.17.0.1 մտել է LIST ծածկագրման կանոնի տակ CMAP կրիպտո քարտեզում և ինկապսուլացված է: Այնուհետև փաթեթը ուղղվեց (անհետացավ): Klogview-ի ելքում պատասխան տրաֆիկ չկա:

Ես ստուգում եմ մուտքի ցուցակները Gate1 սարքի վրա: Ես տեսնում եմ մուտքի մեկ ցուցակ LIST, որը սահմանում է գաղտնագրման թիրախային տրաֆիկը, ինչը նշանակում է, որ firewall-ի կանոնները կազմաձևված չեն.

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-ի դրայվերը կարգավորում է ցանցի ամբողջ տրաֆիկը, ոչ միայն այն երթևեկը, որը պետք է ծածկագրվի: Սրանք այն հաղորդագրություններն են, որոնք տեսանելի են klogview-ում, եթե 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 տրաֆիկը (պրոտո 1) 172.16.0.1->172.17.0.1 ներառված չի եղել (չհամընկնում) CMAP կրիպտո քարտի կոդավորման կանոններում։ Փաթեթը փոխանցվել է (հեռացվել է) հստակ տեքստով:

Քայլ 3. Ինչ է Gate2-ը ստանում Gate1-ից

Ես գործարկում եմ sniffer-ը 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-ը ստանում է ESP փաթեթներ Gate1-ից:

Քայլ 4. Ինչ է անում Gate2-ը ESP փաթեթների հետ

Ես գործարկում եմ klogview կոմունալ ծրագիրը 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

Ես տեսնում եմ, որ ESP փաթեթները (պրոտո 50) հեռացվել են (DROP) firewall կանոնով (L3VPN): Ես համոզված եմ, որ 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-ում, klogview ելքում, հայտնվեցին հաղորդագրություններ, որ թիրախային տրաֆիկը 172.16.0.1->172.17.0.1 հաջողությամբ վերծանվել է (PASS) LIST կանոնով 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

Արդյունքները

Ուսանողը փչացրել է իր հանգստյան օրը.
Զգույշ եղեք ME կանոնների հետ:

Անանուն ինժեներ
t.me/anonymous_engineer

Source: www.habr.com

Добавить комментарий