Clever Geek Handbook

如何对家用IPsec VPN进行故障排除。第1部分





情况



输出。我喝咖啡。学生在两点之间建立了VPN连接，然后消失了。我检查：隧道确实存在，但是隧道中没有流量。学生不接听电话。



我打开水壶，跳入C-Terra网关故障排除程序。我分享我的经验和方法。



初始数据



这两个地理位置不同的站点通过GRE隧道连接。GRE需要加密：







检查GRE隧道是否正常工作。为此，我从R1设备ping通到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隧道的统计信息中，我看到该隧道确实存在，但是Rcvd计数器为零： 



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


我像这样对C-Terra进行故障排除：我正在寻找从R1到R2的途中目标数据包丢失的位置。在过程中（破坏者），我会发现一个错误。



故障排除



步骤1. Gate1从R1得到什么我



使用内置的数据包嗅探器-tcpdump。我在内部（类似于Cisco的表示法中的Gi0 / 1或Debian OS表示法中的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实用程序，我可以看到C-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加密规则下下降了（PASS），并且被加密（封装）了。然后将数据包路由（通过）。klogview输出中没有响应流量。



检查Gate1设备上的访问列表。我看到一个访问列表LIST，它确定了加密的目标流量，这意味着未配置ME规则： 



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接收什么在Gate2



的WAN（eth0）接口上启动嗅探器： 



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数据包（协议50）被防火墙的规则（L3VPN）丢弃（DROP）。我确保L3VPN访问列表确实附加到Gi0 / 0： 



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规则成功（通过）解密（解封装）： 



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/anonimous_engineer


More articles:


All Articles