情况
休假。 我喝咖啡。 该学生在两点之间建立了 VPN 连接,然后就消失了。 我查了一下:确实有隧道,但是隧道里没有车辆。 该学生不接听电话。
我打开水壶,开始研究 S-Terra 网关的故障排除。 我分享我的经验和方法。
初始数据
两个地理上分离的站点通过 GRE 隧道连接。 GRE需要加密:
我正在检查 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
在 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 接收到的内容
我使用内置的数据包嗅探器 - tcpdump。 我在内部接口(类似于 Cisco 的表示法中的 Gi0/1 或 Debian 操作系统表示法中的 eth1)接口上启动嗅探器:
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 收到来自 R1 的 GRE 数据包。 我正在赶来。
步骤 2. Gate1 对 GRE 数据包执行的操作
使用 klogview 实用程序,我可以看到 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 流量 (proto 47) 172.16.0.1 -> 172.17.0.1 位于 CMAP 加密映射中的 LIST 加密规则下并被封装。 接下来,数据包被路由(传递)。 klogview 输出中没有响应流量。
我正在检查 Gate1 设备上的访问列表。 我看到一个访问列表LIST,它定义了加密的目标流量,这意味着未配置防火墙规则:
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 驱动程序处理网络流量并以未加密的方式传输,则这些是 klogview 中可见的消息:
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 接收到什么
我在 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 包做什么
我在 Gate2 上启动 klogview 实用程序:
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)被防火墙规则(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 网关上,在 klogview 输出中,出现消息表明目标流量 172.16.0.1->172.17.0.1 已被 CMAP 加密映射中的 LIST 规则成功解密 (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
来源: habr.com