Closed userofjack closed 4 months ago
@userofjack 你好!感谢你提供解决方案。另外你也可以尝试增加 retransmit timeout 的值,请参见另外这个 Issue。在默认情况下,Libreswan 会通过 dead peer detection (reference) 功能向客户端自动发送类似的 ping,但在超出 retransmit timeout 之后(比如因为网络不稳定导致)则会在服务器端断开该 VPN 连接,从而出现你所说的情况。
@userofjack 你好!感谢你提供解决方案。另外你也可以尝试增加 retransmit timeout 的值,请参见另外这个 Issue。在默认情况下,Libreswan 会通过 dead peer detection (reference) 功能向客户端自动发送类似的 ping,但在超出 retransmit timeout 之后(比如因为网络不稳定导致)则会在服务器端断开该 VPN 连接,从而出现你所说的情况。
经过实验,这个方法最多能够延缓到到1小时左右出现连接丢失。 我试过dpd和nat-keepalive的各种设置组合,retransmit timeout已经设置为86400s,问题依旧。 应该不是nat的原因,毕竟假死后如果重启ipsec服务,客户端会立马提示断开连接。 实在搞不懂了。。。
现象是Windows客户端的连接状态显示“已连接”,但ipsec trafficstatus显示的连接为空,此时ping客户端虚拟内网ip不通。
原因不明,但可以肯定的是“连接丢失”是假象,因为此时Windows客户端的连接状态显示“已连接”,如果此时重启ipsec服务,Windows客户端会立马显示断开连接。因此也能排除由于nat超时的可能性。
解决方案: 在服务器用脚本定时(每隔4分钟左右)ping一下需要保活的客户端虚拟内网ip。