IPSecトンネルが確立されましたが、トラフィックまたはpingができません

Question

私はこのサイトや他の多くのサイトですでに何時間も検索しており、同様の問題が発生していても、問題を解決できるサイトは見つかりませんでした。

Strongswan（swanctl.confによる）を使用して、自分のコンピューターからサーバー上の仮想マシンへのIPsecトンネルを構成しようとしています。以前にIPsec接続を行いましたが、別のデバイスから行いました。私は同じ構成（swanctl.conf）を使用していますが、何か他のものが適合していないようです。私のマシン（10.3.72.29）は仮想IP（172.13.14.2）を取得し、独自の仮想IP（192.168.122.2）でサーバーのデバイス（10.3.218.62）への接続を確立します。

私の現在の構成：

私のPC（イニシエーター）swanctl.conf：

connections { ch_vti0 { send_cert = always encap = yes vips = 0.0.0.0 remote_addrs = 10.3.218.62 local { round = 1 id = 10.3.72.29 auth = psk certs = } remote { auth = psk id = 10.3.218.62 certs = } children { ch_vti0 { mark_in = 42 mark_out = 42 remote_ts = 192.168.122.2/24 local_ts = dynamic inactivity = 300s mode = tunnel esp_proposals = 3des-sha1-modp2048 updown = /usr/local/etc/swanctl/updown.sh 0 } } version = 1 proposals = des-md5-modp768, des-md5-modp1024, des-md5-modp1536 } } secrets { eap-xauth { eap_id = test1 id = test1 secret = password } xauth-local { id = test1 secret = password } ike-sec { id = %any secret = test } ike-local { id = 10.3.72.29 secret = test } }

サーバーの仮想マシンswanctl.conf：

connections { ch_vti0 { send_cert = always encap = yes pools = pools_users #aggressive = yes local { round = 1 id = 10.3.218.62 auth = psk certs = } remote { auth = psk id = %any certs = } children { ch_vti0 { local_ts = 192.168.122.2/24 inactivity = 120s mode = tunnel esp_proposals = 3des-sha1-modp2048 updown = /usr/local/libexec/ipsec/_updown iptables } } version = 0 proposals = des-md5-modp768, des-md5-modp1024, des-md5-modp1536 } } pools { pools_users { addrs = 172.13.14.2/24 } } secrets { eap-xauth { eap_id = test1 id = test1 secret = password } xauth-local { id = test1 secret = password } ike-sec { id = %any secret = test } ike-local { id = 10.3.218.62 secret = test } }

誰かがupdown.shスクリプトがvti0インターフェイスとルートを作成するのではないかと思っている場合

私のPCのipsec statusallの結果：

Listening IP addresses: 10.3.72.29 fdc8:c2cb:4586:cc11::8f00:5a9 172.13.14.2 Connections: ch_vti0: %any...10.3.218.62 IKEv1 ch_vti0: local: [10.3.72.29] uses pre-shared key authentication ch_vti0: remote: [10.3.218.62] uses pre-shared key authentication ch_vti0: child: dynamic === 192.168.122.0/24 TUNNEL Security Associations (1 up, 0 connecting): ch_vti0[1]: ESTABLISHED 13 minutes ago, 10.3.72.29[10.3.72.29]...10.3.218.62[10.3.218.62] ch_vti0[1]: IKEv1 SPIs: 7fa996a60f87e923_i* 4faa8dbdd74a5927_r, rekeying in 3 hours ch_vti0[1]: IKE proposal: DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_768 ch_vti0{1}: INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c393a4bb_i c392a387_o ch_vti0{1}: 3DES_CBC/HMAC_SHA1_96/MODP_2048, 65772 bytes_i (783 pkts, 0s ago), 0 bytes_o, rekeying in 42 minutes ch_vti0{1}: 172.13.14.2/32 === 192.168.122.0/24

サーバーのデバイス：

Listening IP addresses: 192.168.122.2 10.3.218.62 fdc8:c2cb:4586:cc12::e49c:faf8 Connections: ch_vti0: %any...%any IKEv1/2 ch_vti0: local: [10.3.218.62] uses pre-shared key authentication ch_vti0: remote: [%any] uses pre-shared key authentication ch_vti0: child: 192.168.122.0/24 === dynamic TUNNEL Security Associations (1 up, 0 connecting): ch_vti0[1]: ESTABLISHED 14 minutes ago, 10.3.218.62[10.3.218.62]...10.3.72.29[10.3.72.29] ch_vti0[1]: IKEv1 SPIs: 7fa996a60f87e923_i 4faa8dbdd74a5927_r*, rekeying in 3 hours ch_vti0[1]: IKE proposal: DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_768 ch_vti0{1}: INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c392a387_i c393a4bb_o ch_vti0{1}: 3DES_CBC/HMAC_SHA1_96/MODP_2048, 0 bytes_i, 68880 bytes_o (820 pkts, 0s ago), rekeying in 44 minutes ch_vti0{1}: 192.168.122.0/24 === 172.13.14.2/32

私のPC上のルート：

root@malz:/usr/local/etc/swanctl# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 10.3.127.1 0.0.0.0 UG 100 0 0 enp2s0 10.3.0.0 0.0.0.0 255.255.0.0 U 100 0 0 enp2s0 192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 vti0

サーバーのデバイス上のルート：

root@server-automation-2:/etc/swanctl# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 10.3.127.1 0.0.0.0 UG 0 0 0 ens4 10.3.0.0 0.0.0.0 255.255.0.0 U 0 0 0 ens4 192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 ens3

IPsecが使用するポート（500、4500、4500/udp、500/udp）を許可し、両方のファイアウォールを無効にして、iptablesをクリアしてすべてを許可しました。

iptables -F iptables -I INPUT -j ACCEPT iptables -P INPUT ACCEPT iptables -P OUTPUT ACCEPT iptables -P FORWARD ACCEPT

パケットをドロップするためのsysctlパラメータもチェックしました（特にicmpリクエストに関するもの）

Tcpdumpを使用してパケットをキャッチしようとすると、サーバーのデバイスからパケットを受信していることがわかります（ping icmpパケット）が、PCが応答しません

パケットを送信しようとすると、サーバーのデバイスでパケットがキャッチされず、PCのIPsecインターフェイスのTXエラーパケットが増加します。 ifconfigから：

vti0: flags=209<UP,POINTOPOINT,RUNNING,NOARP> mtu 1480 inet 172.13.14.2 netmask 255.255.255.255 destination 172.13.14.2 inet6 fe80::5efe:a03:481d prefixlen 64 scopeid 0x20<link> tunnel txqueuelen 1000 (IPIP Tunnel) RX packets 1063 bytes 89292 (89.2 KB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 57 dropped 0 overruns 0 carrier 57 collisions 0

結論として、2台のマシン間にipsec接続を設定しましたが、そのうちの1台がパッケージを送信できず、他のpingに応答しない理由を理解できません。私はこれがすべて以前にテスト済みであり、まったく同じconfファイル（ipsの変更を除く）で動作することを既に述べたので、これすべての原因がipsec構成ではないことにかなり確信しています。

誰かが私にヒントさえ与えることができれば、私はそれを本当に感謝します。

Anton Danilov · Accepted Answer

トラブルシューティングの手順（下から上）：

Tcpdumpを実行します。クリアで暗号化されたパケット（ESP）が表示されます。
Ipsecトンネルの両端間のIP接続を確認します。
ルーティングを確認してください。 strongswanはデフォルトで追加のルートを別のルーティングテーブルにインストールします。 ip -4 r ls table 220を実行します。出力を調査します。実際のルートを確認するには、ip route get <dst>コマンドを使用します。 route -nコマンドは使用しないでください。未完了のビューが返されます。
ip -s -s xfrm state listおよびip -s -s -d xfrm policy listの出力を確認してください。システムSADB（セキュリティアソシエーションデータベース）とポリシーDBが表示されます。 vtiインターフェイスにいくつかのキャリアエラーがあります。 vtiインターフェイスのキャリアエラーは、次のことを意味します。
- 適切なipsecポリシーが見つかりません。 ip x p get ...コマンドを確認してください。
- 適切なルートが見つかりませんでした。 ip route get ...コマンドを確認してください。
- 適切なSAが見つかりません。ip x s lsコマンドを確認してください。
ファイアウォールを確認してください。 iptablesコマンドはデフォルトでfilterテーブルで機能しますが、他のテーブル（raw、nat、mangle）があります。 iptables-save -cコマンドを使用して、完全なルールセットを一覧表示することをお勧めします。 natルールの変更後、conntrack -Fコマンドを使用してconntrackテーブルをクリアします。 ipsecトラフィックはファイアウォールチェーンを2回通過します。1つは暗号化されたパス、もう1つはクリアされたパスです。ルールを調べてください。また、NFLOGターゲットルールを挿入して、tcpdump -ni nflog...コマンドでトラフィックをキャプチャすることもできます。