ວິທີການແກ້ໄຂບັນຫາ IPsec VPN ພາຍໃນປະເທດ. ພາກທີ 1

ສະຖານະການ

ມື້​ພັກ. ຂ້ອຍດື່ມກາເຟ. ນັກຮຽນໄດ້ຕັ້ງການເຊື່ອມຕໍ່ VPN ລະຫວ່າງສອງຈຸດແລະຫາຍໄປ. ຂ້ອຍກວດເບິ່ງ: ມີອຸໂມງແທ້ໆ, ແຕ່ບໍ່ມີການຈະລາຈອນໃນອຸໂມງ. ນັກຮຽນບໍ່ຮັບສາຍ.

ຂ້າ​ພະ​ເຈົ້າ​ເອົາ​ກະ​ຕຸກ​ໃສ່​ແລະ​ເຊົາ​ເຂົ້າ​ໄປ​ໃນ​ການ​ແກ້​ໄຂ​ບັນ​ຫາ S-Terra Gateway​. ຂ້ອຍແບ່ງປັນປະສົບການແລະວິທີການຂອງຂ້ອຍ.

ຂໍ້ມູນເບື້ອງຕົ້ນ

ສອງສະຖານທີ່ທີ່ແຍກກັນທາງພູມສາດແມ່ນເຊື່ອມຕໍ່ກັນໂດຍອຸໂມງ GRE. GRE ຕ້ອງໄດ້ຮັບການເຂົ້າລະຫັດ:

ຂ້ອຍກໍາລັງກວດສອບການເຮັດວຽກຂອງອຸໂມງ GRE. ເພື່ອເຮັດສິ່ງນີ້, ຂ້າພະເຈົ້າດໍາເນີນການ ping ຈາກອຸປະກອນ R1 ກັບການໂຕ້ຕອບ GRE ຂອງອຸປະກອນ R2. ນີ້ແມ່ນການຈະລາຈອນເປົ້າຫມາຍສໍາລັບການເຂົ້າລະຫັດ. ບໍ່​ມີ​ຄໍາ​ຕອບ:

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

ໃນສະຖິຕິຂອງອຸໂມງ IPsec ໃນ Gate1 ຂ້ອຍເຫັນວ່າມີອຸໂມງຢ່າງແທ້ຈິງ, ແຕ່ຕົວນັບ 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. ໃນຂະບວນການ (spoiler) ຂ້າພະເຈົ້າຈະຊອກຫາຄວາມຜິດພາດ.

ການແກ້ໄຂບັນຫາ

ຂັ້ນຕອນທີ 1. ສິ່ງທີ່ Gate1 ໄດ້ຮັບຈາກ R1

ຂ້ອຍໃຊ້ packet sniffer ທີ່ມີໃນຕົວ - tcpdump . ຂ້ອຍເປີດຕົວ sniffer ຢູ່ໃນພາຍໃນ (Gi0/1 in Cisco-like notation or eth1 in Debian OS notation) interface:

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 ເປົ້າຫມາຍ (proto 47) 172.16.0.1 -> 172.17.0.1 ມາພາຍໃຕ້ກົດລະບຽບການເຂົ້າລະຫັດ LIST ໃນແຜນທີ່ crypto CMAP ແລະຖືກຫຸ້ມຫໍ່. ຕໍ່ໄປ, ຊຸດໄດ້ຖືກສົ່ງຜ່ານ (ຜ່ານອອກ). ບໍ່ມີການຈະລາຈອນຕອບສະຫນອງໃນຜົນຜະລິດ klogview.

ຂ້ອຍກໍາລັງກວດເບິ່ງລາຍການການເຂົ້າເຖິງຢູ່ໃນອຸປະກອນ Gate1. ຂ້ອຍເຫັນບັນຊີລາຍຊື່ການເຂົ້າເຖິງຫນຶ່ງ, ເຊິ່ງກໍານົດການເຂົ້າຊົມເປົ້າຫມາຍສໍາລັບການເຂົ້າລະຫັດ, ຊຶ່ງຫມາຍຄວາມວ່າກົດລະບຽບຂອງ 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 (proto 1) 172.16.0.1->172.17.0.1 ບໍ່ໄດ້ຖືກລວມເຂົ້າ (ບໍ່ກົງກັນ) ໃນກົດລະບຽບການເຂົ້າລະຫັດຂອງບັດ crypto 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 utility ໃນ 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 (proto 50) ຖືກຫຼຸດລົງ (DROP) ໂດຍກົດລະບຽບໄຟວໍ (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 ໃນແຜນທີ່ crypto 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

ແຫຼ່ງຂໍ້ມູນ: www.habr.com