4

ipsec 接続を作成しようとしているときに、奇妙な動作が見られました。cisco asa と Linux ボックスの間で ipsec を設定したところ、期待どおりに動作しました。しかし、Linux ボックスでネットワーク サービスを再起動するか、cisco 側でポートを再起動すると、トンネルは機能しなくなりますが、トンネル ステータスはアップになります。

/etc/init.d/ipsec status
/usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled
IPsec running  - pluto pid: 2684
pluto pid 2684
1 tunnels up
some eroutes exist

反対側 (telnet、ping、ssh) に接続しようとすると、接続が機能しません。

/etc/ipsec.conf は次のようになります。

# /etc/ipsec.conf - Openswan IPsec configuration file
#
# Manual:     ipsec.conf.5
#
# Please place your own config files in /etc/ipsec.d/ ending in .conf

version 2.0     # conforms to second version of ipsec.conf specification

# basic configuration
config setup
        # Debug-logging controls:  "none" for (almost) none, "all" for lots.
        # klipsdebug=none
        # plutodebug="control parsing"
        # For Red Hat Enterprise Linux and Fedora, leave protostack=netkey
        protostack=netkey
        nat_traversal=yes
        virtual_private=
        oe=off
        # Enable this if you see "failed to find any available worker"
        nhelpers=0

#You may put your configuration (.conf) file in the "/etc/ipsec.d/" and uncomment this.
include /etc/ipsec.d/*.conf

そして私の /etc/ipsec.d/myvpn.conf は次のようになります:

conn myvpn
        authby=secret                # Key exchange method
        left=server-ip                     # Public Internet IP address of the
                                     # LEFT VPN device
        leftsubnet=server-ip/32            # Subnet protected by the LEFT VPN device
        leftnexthop=%defaultroute    # correct in many situations
        right=asa-ip                 # Public Internet IP address of
                                     # the RIGHT VPN device
        rightsubnet=network/16       # Subnet protected by the RIGHT VPN device
        rightnexthop=asa-ip          # correct in many situations
        auto=start                   # authorizes and starts this connection
                                     # on booting
        auth=esp
        esp=aes-sha1
        compress=no

openswan サービスを再起動すると、すべてが機能し始めますが、これを自動的に行うロジックが必要だと思います。誰かが私が欠けているものを知っていますか?

4

5 に答える 5

5

両側で使用できる場合は、デッド ピア検出を有効にすることをお勧めします。デッド ピア検出は、トンネルが実際に機能しなくなったことを通知し、切断またはリセットします。

利用できない場合は、セッションの再ネゴシエーション時間を非常に短く変更することもできます。トンネルは新しいキーを頻繁に作成し、新しいトンネルを設定して古いものを定期的に置き換え、セッションがダウンしたタイムアウト後にトンネルを効果的に再作成します。

Linux での PPP セッションについては、PPP デバイスがオンラインに戻るたびにすべてのトンネルを再起動するために、/etc/ppp/ip-up.local に "service ipsec restart" を設定するだけです。

YMMV。

于 2012-05-30T14:32:10.390 に答える
3

DPD を試すだけですが、うまくいきません。

だから私はマイクバブコックから学びました。

/etc/ppp/ip-down に次の行を追加します

service ipsec restart

この回避策により、L2TP/IPSec が魅力的に機能するようになりました。

于 2013-01-10T03:35:48.810 に答える
1


これは、iptables ルールが原因で発生する可能性があります。
リモート パブリック IP アドレスに対して udp ポート 500 と esp プロトコルが有効になっていることを確認してください。

例：

    iptables -A OUTPUT -p udp -d 1.2.3.4 --dport 500 -j ACCEPT
    iptables -A OUTPUT -p esp -d 1.2.3.4 -j ACCEPT

さよなら

于 2016-05-26T09:52:20.837 に答える
1

接続が失われるたびに ipsec を再起動するという考えは好きではありません。実際/usr/libexec/ipsec/_updownには、ipsec のさまざまなアクションで実行されます。leftupdown/rightupdown で同じスクリプトを実行できます。しかし問題は、リモート クライアントがホストに接続し直すときに実際のコマンドを実行しないことです。この問題を修正するには、/usr/libexec/ipsec/_updown.netkey のdoroute replace後up-client)に追加する必要があります (もちろん Netkey を使用する場合):

# ...skipped...
#
up-client)
# connection to my client subnet coming up
# If you are doing a custom version, firewall commands go here.
    doroute replace
#
# ...skipped...

ただし、パッケージを更新すると、このファイルは上書きされることに注意してください。別の場所に置き、次のコマンドを接続構成に追加します。

rightupdown="/usr/local/libexec/ipsec/_updown"
leftupdown="/usr/local/libexec/ipsec/_updown"

これで、リモートがサーバーに接続し直すとすぐにルートが復元されます。

于 2014-01-05T03:54:15.347 に答える