web-dev-qa-db-ja.com

Openswanトンネルは上向きですが、一方向にしか機能しません

IPsec接続を正常に確立しましたが、部分的にしか機能しません。一方はトンネルを介してパケットを送信しません。ネットワークトポロジがこちら側にはっきりしないようです。

どんな助けでも大歓迎です！ありがとう!!

これはネットワークスキームです。

"office"(192.168.73.0/24) == "vpn"(192.168.73.1) == "router"(6.6.6.6) <====> "server"(7.7.7.7) == "VM_LAN"(192.168.133.0/24)

6.6.6.6と7.7.7.7はシンボリックパブリックIPです。つまり、「ルーター」と「サーバー」はどちらもインターネットに直接接続されています。

"vpn"と "server"はどちらもCentOS 6を実行します。 "router"はケーブルモデムであり、NATおよびポート転送を行います。

接続が確立されました。

「vpn」で「サーバー」の内部IPにpingを実行できます。

[root@vpn]# ping 192.168.133.1
PING 192.168.133.1 (192.168.133.1) 56(84) bytes of data.
64 bytes from 192.168.133.1: icmp_seq=1 ttl=64 time=74.8 ms

「サーバー」では「vpn」にpingできません。送信されたパケットすらありません。

以下は、上記のpingパケットの受信を示す「server」からのダンプです。「server」からpingを実行するときに、同じコマンドを使用して、「server」から「vpn」にパケットが送信されるかどうかをテストしましたが、パケットが表示されません。

[root@server]# tcpdump port 500 or port 4500
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
14:40:21.793577 IP 6.6.6.6.ipsec-nat-t > 7.7.7.7.ipsec-nat-t: UDP-encap: ESP(spi=0x712a1d37,seq=0x2), length 132
14:40:21.793650 IP 7.7.7.7.ipsec-nat-t > 6.6.6.6.ipsec-nat-t: UDP-encap: ESP(spi=0x840e6b76,seq=0x2), length 132

ipsec verifyは問題ないようです：

[root@server]# ipsec verify
Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path                                 [OK]
Linux Openswan U2.6.32/K2.6.32-358.2.1.el6.x86_64 (netkey)
Checking for IPsec support in kernel                            [OK]
 SAref kernel support                                           [N/A]
 NETKEY:  Testing for disabled ICMP send_redirects              [OK]
NETKEY detected, testing for disabled ICMP accept_redirects     [OK]
Checking that pluto is running                                  [OK]
 Pluto listening for IKE on udp 500                             [OK]
 Pluto listening for NAT-T on udp 4500                          [OK]
Checking for 'ip' command                                       [OK]
Checking /bin/sh is not /bin/dash                               [OK]
Checking for 'iptables' command                                 [OK]
Opportunistic Encryption Support                                [DISABLED]

iptablesが無効になっています：

[root@server]# iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination


[root@server]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
7.7.7.7         0.0.0.0         255.255.255.255 UH    0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 eth0
0.0.0.0         7.7.7.1         0.0.0.0         UG    0      0        0 eth0

私のipsec.conf：

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

conn aaa-office
    authby=secret
    left=7.7.7.7
    leftsubnet=192.168.133.0/24
    right=6.6.6.6
    rightsubnet=192.168.73.0/24
    rightid=192.168.73.8
    auto=add
linuxipsecopenswan
4
grasbueschel

私は自分自身に回答し、この情報が同じ問題を持つ他のユーザーに役立つことを願っています。

根本的な原因は、「サーバー」からのパケットがトンネルを介してルーティングされなかったことです。 ip xfrm policyを使用すると、トンネルを経由するルーティングのポリシーは、パケットが192.168.133.0/24から発信される必要があることであることがわかりました。

ただし、「サーバー」から「vpn」へのpingの結果、次のパケットが発生しました。

17:29:16.549349 IP 7.7.7.7 > 192.168.73.8: ICMP echo request, id 43864, seq 1, length 64

したがって、pingを実行するときに、自然に使用されるソースIPはサーバーのパブリックIPでした。 「vpn」マシンはすでにサブネット内にあったため、これは「vpn」マシンには当てはまりませんでした。 「サーバー」の構成ファイルに次のステートメントを追加すると、問題は解決しました。

leftsourceip=192.168.133.1

これで問題なく動作し、「サーバー」から「vpn」の背後にあるサブネットに到達できます。

8
grasbueschel

Openswanはわかりませんが、VPNトンネルで、ルートベースのVPNまたはポリシーベースのいずれかを使用していることを確認してください。すなわち。ルートに基づいている場合は、「このトンネルインターフェイスを使用して192.168.73.1のネットワークに到達する」というルートが必要です。ポリシーベースの場合、「xから宛先yに送信されたソーストラフィック= VPNトンネルを通過するトンネル」というポリシーが存在するはずです。

すみません...たくさん削除しました...読解力が不十分...サーバーのLANインターフェイス/ IPに情報が表示され、192.168.133.1のソースIPからpingを実行しようとしていることがわかりました。

Openswanのポリシーまたはルートが192.168.73.0/24宛ての192.168.133.0/24トラフィックソースのサーバー側に設定されていることを確認し、トンネルを使用していることを確認します。そのトラフィックはトンネルを使用していないようですが、代わりに次のようなことをしています：

192.168.133.1--192.168.73.1へのpingの試行（失敗）

1
TheCleaner