สถานการณ์
วันหยุด ฉันดื่มกาแฟ. นักเรียนตั้งค่าการเชื่อมต่อ 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 tunnel เปิดตัวสำเร็จแล้ว โดยไม่มีปัญหา:
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 อยู่ระหว่างดำเนินการ(สปอยล์) ผมจะเจอข้อผิดพลาดครับ
การแก้ไขปัญหา
ขั้นตอนที่ 1 สิ่งที่ Gate1 ได้รับจาก R1
ฉันใช้แพ็กเก็ตดมกลิ่นในตัว - tcpdump ฉันเปิดตัวดมกลิ่นบนอินเทอร์เฟซภายใน (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 ฉันเห็นรายการเข้าถึงหนึ่งรายการ ซึ่งกำหนดการรับส่งข้อมูลเป้าหมายสำหรับการเข้ารหัส ซึ่งหมายความว่าไม่ได้กำหนดค่ากฎไฟร์วอลล์:
Gate1#show access-lists
Extended IP access list LIST
10 permit gre host 172.16.0.1 host 172.17.0.1สรุป: ปัญหาไม่ได้อยู่ที่อุปกรณ์ Gate1
ข้อมูลเพิ่มเติมเกี่ยวกับคล็อกวิว
ไดรเวอร์ VPN จัดการการรับส่งข้อมูลเครือข่ายทั้งหมด ไม่ใช่แค่การรับส่งข้อมูลที่ต้องเข้ารหัสเท่านั้น นี่คือข้อความที่มองเห็นได้ใน klogview หากไดรเวอร์ VPN ประมวลผลการรับส่งข้อมูลเครือข่ายและส่งโดยไม่เข้ารหัส:
root@R1:~# ping 172.17.0.1 -c 4root@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
ฉันเปิดตัวดมกลิ่นบนอินเทอร์เฟซ 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) โดยกฎไฟร์วอลล์ (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 ในเอาต์พุต klogview ข้อความปรากฏว่าทราฟฟิกเป้าหมาย 172.16.0.1->172.17.0.1 ได้รับการถอดรหัสสำเร็จ (PASS) โดยกฎ LIST ใน CMAP crypto map:
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
ที่มา: will.com