Vyatta VPN IPsec隧道随机丢失

我不断收到我的VPN隧道的随机丢失，如果我做一个“服务IPSec重启”，它只会发生很less（〜一周两次），然后立即再次开始工作。真的很烦人，因为我试图复制一个大的虚拟机到我们的灾难恢复站点，每次隧道下降，我必须重新开始！

configuration如下。任何想法家伙？

esp-group DR { compression disable lifetime 3600 mode tunnel pfs enable proposal 1 { encryption aes128 hash sha1 } } ike-group DR { dead-peer-detection { action restart interval 15 timeout 30 } lifetime 28800 proposal 1 { dh-group 2 encryption aes128 hash sha1 } } peer *.*.*.* { authentication { mode pre-shared-secret pre-shared-secret *** } connection-type initiate description "DR Site" ike-group DR local-address *.*.*.* tunnel 2 { allow-nat-networks disable allow-public-networks disable esp-group DR local { prefix 192.168.*.0/24 } remote { prefix 10.*.0.0/24 } } }

在检查日志之后，他们似乎充满了这个消息：

 Apr 3 13:23:37 *.*.*.* pluto[20789]: packet from *.*.*.*:500: received Vendor ID payload [Dead Peer Detection] Apr 3 13:23:37 *.*.*.* pluto[20789]: packet from *.*.*.*:500: ignoring Vendor ID payload [RFC 3947] Apr 3 13:23:37 *.*.*.* pluto[20789]: packet from *.*.*.*:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] Apr 3 13:23:37 *.*.*.* pluto[20789]: packet from *.*.*.*:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] Apr 3 13:23:37 *.*.*.* pluto[20789]: packet from *.*.*.*:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] Apr 3 13:23:37 *.*.*.* pluto[20789]: packet from *.*.*.*:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00] Apr 3 13:23:37 *.*.*.* pluto[20789]: packet from *.*.*.*:500: initial Main Mode message received on *.*.*.*:500 but no connection has been authorized with policy=PSK Apr 3 13:23:39 *.*.*.* heartbeat: [3397]: ERROR: process_status_message: bad node [****] in message Apr 3 13:23:39 *.*.*.* heartbeat: [3397]: ERROR: MSG: Dumping message with 12 fields Apr 3 13:23:39 *.*.*.* heartbeat: [3397]: ERROR: MSG[0] : [t=status] Apr 3 13:23:39 *.*.*.* heartbeat: [3397]: ERROR: MSG[1] : [st=active] Apr 3 13:23:39 *.*.*.* heartbeat: [3397]: ERROR: MSG[2] : [dt=2710] Apr 3 13:23:39 *.*.*.* heartbeat: [3397]: ERROR: MSG[3] : [protocol=1] Apr 3 13:23:39 *.*.*.* heartbeat: [3397]: ERROR: MSG[4] : [src=****] Apr 3 13:23:39 *.*.*.* heartbeat: [3397]: ERROR: MSG[5] : [(1)srcuuid=0x201c570(36 27)] Apr 3 13:23:39 *.*.*.* heartbeat: [3397]: ERROR: MSG[6] : [seq=28077b] Apr 3 13:23:39 *.*.*.* heartbeat: [3397]: ERROR: MSG[7] : [hg=50b63627] Apr 3 13:23:39 *.*.*.* heartbeat: [3397]: ERROR: MSG[8] : [ts=533d60db] Apr 3 13:23:39 *.*.*.* heartbeat: [3397]: ERROR: MSG[9] : [ld=0.00 0.01 0.05 1/87 31182] Apr 3 13:23:39 *.*.*.* heartbeat: [3397]: ERROR: MSG[10] : [ttl=3] Apr 3 13:23:39 *.*.*.* heartbeat: [3397]: ERROR: MSG[11] : [auth=1 96fa591a077c1bd3941d450c9c8973d8f0a9440f]

我find的帮助隧道稳定了很多的设置是

set vpn ipsec auto-update '60'

我的死对等检测间隔和超时时间比你的更长（分别为30和120秒），我使用VTI，但是你的configuration与我的几乎完全相同。通过VyOS虚拟机内部的隧道，我能够维持400 Mbps的速度。

对不起，不能评论，不是一个真正的答案：

你是否尝试增加ike-group DR dead-peer-detetion timeout值？
是否有可能比每周两次随机地有一个networking使用高峰，使所有可用带宽饱和？