VPN状态一致性问题

是否可以使用Isakmp 消息猪主动同步vpn状态的问题

比如， VPNa 和 VPNb通讯；两者建立连接后。

VPNa因为设备重启等原因/或者系统异常，导致
VPNa在没有发送出删除载荷时。

VPNb如何主动同步这一状态？

可否使用Isakmp doi里介绍的notification information /或者别的消息来实现？

当然 有别的方法能解决vpn状态一致性问题，也欢迎
介绍。

据我所知FREESWAN是这样做的：
设定4个值：IKE生存期（好象和这里说的没有关系）
           SA生存期 T1
           SA到期前的一定长度的时间 T2
           一个百分数 X%

由于网络上不可能做到完全同步，所以FREESWAN采取了一个比较聪明的办法，SA的删除由本机根据T1自己删除，
为了不使连接断开，在自己的机器检测到SA时间已经到了（T1-T2*X%）了，就会在到达T1时间的这段时间里发起协商新SA。那么原来的SA怎么办呢？不用管它，让它呆在SAD中，等T1到了，再删它。现在使用的是新协商出来的SA！！！

解决问题是最关键的，我想，即使有冗余也可以承受。

RACOON的代码我没有看过，没有调查没有发言权，呵呵

我知道你说的是soft expiry/hard expiry问题。

但是就你说的这种方法也无法保持两个vpn设备的状态一致。

就SA来说存在Soft expiry(软过期问题)和hard expiry(硬过期)问题。在SA到达软过期时，应该重新协商IPSEC session,这时原来的Session只能用在inbound，而不能在outbound使用，这样就可以保证一般情况下的vpn状态同步。

但是在一些特殊情况下，比如，vpn设备的一方出现异常（crash 重启）,假设重启的是vpn_a.那么vpn_b还没有到达软过期。如果vpn_a这时没有outbound数据，vpn_b有outbound数据，因为vpn_b Session是完整的，所以从b发出的数据不会发起IKE协商。

有一个freeswan的patch叫Dead Peer Detection (draft-ietf-ipsec-dpd-02) Support主要用来当对端vpn失效后删除本地sa。

我知道你说的是soft expiry/hard expiry问题。

但是在一些特殊情况下，比如，vpn设备的一方出现异常（crash 重启）,假设重启的是vpn_a.那么vpn_b还没有到达软过期。如果vpn_a这时没有outbound数据，vpn_b有outbound数据，因为vpn_b Session是完整的，所以从b发出的数据不会发起IKE协商。

 

vpn_a重启，那么vpn_a启动完成它会主动发起IKE协商的（不需要A---》B的数据，A的PLUTO会检查，如果这个连接没有建立SA，他会主动发协商数据的），那么在A，B之间通信就使用的是这次协商出的SA，
B的老的SA就等它硬到期吧！

对于出发IKE协商有（前提已经add）三个途径：1。使用up手工发起协商。2。当有外出数据是查找spd发现需用ipsec处理但是又没有相应的SA，这是内核放出消息触发IKE协商相应的SA.3。当软过期后（时间，流量）。

[编辑 -  11/17/03 by  twofish]

vpn_a重启，那么vpn_a启动完成它会主动发起IKE协商的（不需要A---》B的数据，A的PLUTO会检查，如果这个连接没有建立SA，他会主动发协商数据的），那么在A，B之间通信就使用的是这次协商出的SA，
B的老的SA就等它硬到期吧！

这个方法可以避免状态不一致。
但是没有数据流主动发起协商，是否合适？

这样同步也太简单了。
我记得ipsec doi里有维护session的消息。
不知道可否用消息来维护vpn状态一致。

对于出发IKE协商有（前提已经add）三个途径：1。使用up手工发起协商。2。当有外出数据是查找spd发现需用ipsec处理但是又没有相应的SA，这是内核放出消息触发IKE协商相应的SA.3。当软过期后（时间，流量）。

[编辑 -  11/17/03 by  twofish]

你说的不能避免状态不一致。

对，单纯靠这套协议本身不能避免状态不一致。所以才有Dead Peer Detection (draft-ietf-ipsec-dpd-02)这个草案来解决这个问题。

vpn_a重启，那么vpn_a启动完成它会主动发起IKE协商的（不需要A---》B的数据，A的PLUTO会检查，如果这个连接没有建立SA，他会主动发协商数据的），那么在A，B之间通信就使用的是这次协商出的SA，
B的老的SA就等它硬到期吧！

这个方法可以避免状态不一致。
但是没有数据流主动发起协商，是否合适？

这样同步也太简单了。
我记得ipsec doi里有维护session的消息。
不知道可否用消息来维护vpn状态一致。
 

其实我没有说我采用的方案，我说的是现在FREESWAN所采用的做法，早期版本的FREESWAN采用的方法也是当有数据发出去，当还没有SA就发起协商，后来改了。发起协商这些代码，现在的代码里还留着，没有删除呢！函数名是pfkey_acquire，自己看看吧

对，单纯靠这套协议本身不能避免状态不一致。所以才有Dead Peer Detection (draft-ietf-ipsec-dpd-02)这个草案来解决这个问题。
 

谢谢，正在研究这个草案

其实我没有说我采用的方案，我说的是现在FREESWAN所采用的做法，早期版本的FREESWAN采用的方法也是当有数据发出去，当还没有SA就发起协商，后来改了。发起协商这些代码，现在的代码里还留着，没有删除呢！函数名是pfkey_acquire，自己看看吧

可以说说你的方法么

[quote]

其实我没有说我采用的方案，我说的是现在FREESWAN所采用的做法，早期版本的FREESWAN采用的方法也是当有数据发出去，当还没有SA就发起协商，后来改了。发起协商这些代码，现在的代码里还留着，没有删除呢！函数名是pfkey_acquire，自己看看吧

可以说说你的方法么 [/quote]

你在做客户端吗？如果是的话，我也许可以给你参考。说实话，我对LINUX不熟，只是看了这部分代码而已。
另：你在哪里（城市）？

DPD 草案