Tình hình
Ngày nghỉ. Tôi uống cà phê. Học sinh này thiết lập kết nối VPN giữa hai điểm và biến mất. Tôi kiểm tra: thực sự có một đường hầm, nhưng trong đường hầm không có xe cộ qua lại. Học sinh không trả lời cuộc gọi.
Tôi bật ấm lên và đi sâu vào cách khắc phục sự cố của Cổng S-Terra. Tôi chia sẻ kinh nghiệm và phương pháp của tôi.
Dữ liệu thô
Hai địa điểm cách nhau về mặt địa lý được kết nối bằng đường hầm GRE. GRE cần được mã hóa:
Tôi đang kiểm tra chức năng của đường hầm GRE. Để thực hiện việc này, tôi chạy ping từ thiết bị R1 đến giao diện GRE của thiết bị R2. Đây là lưu lượng truy cập mục tiêu để mã hóa. Không có câu trả lời:
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 3057msTôi nhìn vào nhật ký trên Cổng 1 và Cổng 2. Nhật ký vui vẻ báo cáo rằng đường hầm IPsec đã được khởi chạy thành công, không có vấn đề gì:
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:1Trong phần thống kê của đường hầm IPsec trên Gate1 mình thấy thực sự có một đường hầm nhưng bộ đếm Rсvd được reset về XNUMX:
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 0Tôi gặp rắc rối với S-Terra như thế này: Tôi tìm nơi các gói mục tiêu bị mất trên đường dẫn từ R1 đến R2. Trong quá trình thực hiện (spoiler) mình sẽ tìm thấy sai sót.
Xử lý sự cố
Bước 1. Những gì Gate1 nhận được từ R1
Tôi sử dụng trình thám thính gói tích hợp - tcpdump. Tôi khởi chạy trình thám thính trên giao diện nội bộ (Gi0/1 theo ký hiệu giống Cisco hoặc eth1 trong ký hiệu hệ điều hành Debian):
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 64Tôi thấy Gate1 nhận gói GRE từ R1. Tôi đang đi tiếp.
Bước 2. Gate1 làm gì với gói GRE
Sử dụng tiện ích klogview tôi có thể thấy điều gì đang xảy ra với các gói GRE bên trong trình điều khiển 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
Tôi thấy rằng lưu lượng GRE mục tiêu (proto 47) 172.16.0.1 -> 172.17.0.1 tuân theo quy tắc mã hóa LIST trong bản đồ mật mã CMAP và đã được gói gọn. Tiếp theo, gói được định tuyến (được chuyển đi). Không có lưu lượng phản hồi trong đầu ra klogview.
Tôi đang kiểm tra danh sách truy cập trên thiết bị Gate1. Tôi thấy một LIST danh sách truy cập, xác định lưu lượng đích để mã hóa, có nghĩa là các quy tắc tường lửa không được định cấu hình:
Gate1#show access-lists
Extended IP access list LIST
10 permit gre host 172.16.0.1 host 172.17.0.1Kết luận: vấn đề không nằm ở thiết bị Gate1.
Tìm hiểu thêm về klogview
Trình điều khiển VPN xử lý tất cả lưu lượng mạng, không chỉ lưu lượng cần được mã hóa. Đây là những thông báo hiển thị trong klogview nếu trình điều khiển VPN xử lý lưu lượng mạng và truyền nó mà không được mã hóa:
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: filteredTôi thấy rằng lưu lượng ICMP (proto 1) 172.16.0.1->172.17.0.1 không được bao gồm (không khớp) trong quy tắc mã hóa của thẻ mật mã CMAP. Gói đã được định tuyến (chuyển đi) ở dạng văn bản rõ ràng.
Bước 3. Những gì Gate2 nhận được từ Gate1
Tôi khởi chạy trình thám thính trên giao diện 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 140Tôi thấy Gate2 nhận được gói ESP từ Gate1.
Bước 4. Gate2 làm gì với gói ESP
Tôi khởi chạy tiện ích klogview trên 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
Tôi thấy rằng các gói ESP (proto 50) đã bị loại bỏ (DROP) bởi quy tắc tường lửa (L3VPN). Tôi đảm bảo rằng Gi0/0 thực sự có danh sách truy cập L3VPN được đính kèm:
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 L3VPNTôi phát hiện ra vấn đề.
Bước 5. Danh sách truy cập có vấn đề gì
Tôi xem danh sách truy cập L3VPN là gì:
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 anyTôi thấy rằng các gói ISAKMP được cho phép nên đường hầm IPsec được thiết lập. Nhưng không có quy tắc kích hoạt ESP. Có vẻ như sinh viên này đã nhầm lẫn giữa icmp và Esp.
Chỉnh sửa danh sách truy cập:
Gate2(config)#
ip access-list extended L3VPN
no 30
30 permit esp host 10.10.10.251 anyBước 6. Kiểm tra chức năng
Trước hết, tôi đảm bảo rằng danh sách truy cập L3VPN là chính xác:
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 anyBây giờ tôi khởi chạy lưu lượng truy cập mục tiêu từ thiết bị 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 msChiến thắng. Đường hầm GRE đã được thiết lập. Bộ đếm lưu lượng truy cập đến trong thống kê IPsec không bằng XNUMX:
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 480Trên cổng Gate2, trong đầu ra klogview, xuất hiện thông báo cho biết lưu lượng đích 172.16.0.1->172.17.0.1 đã được giải mã thành công (PASS) theo quy tắc LIST trong bản đồ mật mã 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: decapsulatedKết quả
Một sinh viên đã phá hỏng ngày nghỉ của mình.
Hãy cẩn thận với các quy tắc ME.
kỹ sư ẩn danh
t.me/anonymous_engineer
Nguồn: www.habr.com