☰

2つのAWSインスタンス間のStrongswan VPNトンネルが接続されない

tag-icon • tag-icon vpn amazon-web-services ipsec ubuntu-14.04 strongswan
2つのAWSインスタンス間のStrongswan VPNトンネルが接続されない

StrongSwan 5.1.2 を使用して、Ubuntu 14.04.2 LTS を実行している 2 つの Amazon AWS EC2 インスタンス間で VPN トンネルを設定しようとしています。StrongSwan を使用する前は、Amazon RedHat AMI で open(libre)swan を使用していましたが、問題なく動作していました。何らかの理由で、ここでは StrongSwan で IKE を動作させることさえできません。AWS 構成を 3 回確認しましたが、すべて問題がないため、StrongSwan 構成に問題があるに違いありません。

以下に示すように、私が受けたエラーは次のとおりです。「ソケットへの書き込みエラー: 無効な引数」オンラインで調べましたが、この問題の解決策が見つかりません。strongswan の ipsec.conf が正しく構成されていないと確信しています。

私が取り組んでいるのは以下のものです:

Instance #1: N.Virginia - 10.198.0.164 with public EIP 54.X.X.X
Instance #2: Oregon - 10.194.0.176 with public EIP 52.Y.Y.Y

(単純な) トポロジは次のとおりです。

[ Instance #1 within N.Virginia VPC <-> Public internet <-> Instance #2 within Oregon VPC ]

次の AWS 構成が正しいことを確認しました。

Security groups permit all
IP information is correct
Src/Dest disabled on both instances
ACLs permit all
routes are present and correct (route to 10.x will point to that local instance in order to be routed out to the VPN tunnel)

以下はipsec.conf ファイル (これはオレゴン州のものですが、左|右の値が逆になっていることを除いて、N.バージニア州のインスタンスでも同じです):

config setup
        charondebug="dmn 2, mgr 2, ike 2, chd 2, job 2, cfg 2, knl 2, net 2, enc 2, lib 2"
conn aws1oexternal-aws1nvexternal
        left=52.Y.Y.Y (EIP)
        leftsubnet=10.194.0.0/16
        right=54.X.X.X (EIP)
        rightsubnet=10.198.0.0/16
        auto=start
        authby=secret
        type=tunnel
        mobike=no
        dpdaction=restart

以下は /etc/ipsec.secrets です (他のインスタンスの場合は逆になっています)。

54.X.X.X 52.Y.Y.Y : PSK "Key_inserted_here"

以下は /etc/strongswan.conf です:

charon {
        load_modular = yes
        plugins {
                include strongswan.d/charon/*.conf
        }
}

以下は /etc/sysctl.conf です:

net.ipv4.ip_forward=1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0

以下は/var/log/syslogからのデバッグ出力です。ここでの問題は「ソケットへの書き込みエラー: 無効な引数です。すべて試しましたが、同じエラーが引き続き発生します」のようです。:

Jun 17 17:34:48 ip-10-198-0-164 charon: 13[IKE] retransmit 5 of request with message ID 0
Jun 17 17:34:48 ip-10-198-0-164 charon: 13[NET] sending packet: from 54.X.X.X[500] to 52.Y.Y.Y[500] (1212 bytes)
Jun 17 17:34:48 ip-10-198-0-164 charon: 03[JOB] next event in 75s 581ms, waiting]
Jun 17 17:34:48 ip-10-198-0-164 charon: 16[NET] sending packet: from 54.X.X.X[500] to 52.Y.Y.Y[500]
Jun 17 17:34:48 ip-10-198-0-164 charon: 13[MGR] checkin IKE_SA aws1vexternal-aws1oexternal[1]
Jun 17 17:34:48 ip-10-198-0-164 charon: 13[MGR] check-in of IKE_SA successful.
Jun 17 17:34:48 ip-10-198-0-164 charon: 16[NET] error writing to socket: Invalid argument
Jun 17 17:36:04 ip-10-198-0-164 charon: 03[JOB] got event, queuing job for execution
Jun 17 17:36:04 ip-10-198-0-164 charon: 03[JOB] no events, waiting
Jun 17 17:36:04 ip-10-198-0-164 charon: 08[MGR] checkout IKE_SA
Jun 17 17:36:04 ip-10-198-0-164 charon: 08[MGR] IKE_SA aws1vexternal-aws1oexternal[1] successfully checked out
Jun 17 17:36:04 ip-10-198-0-164 charon: 08[IKE] giving up after 5 retransmits
Jun 17 17:36:04 ip-10-198-0-164 charon: 08[IKE] establishing IKE_SA failed, peer not responding
Jun 17 17:36:04 ip-10-198-0-164 charon: 08[MGR] checkin and destroy IKE_SA aws1vexternal-aws1oexternal[1]
Jun 17 17:36:04 ip-10-198-0-164 charon: 08[IKE] IKE_SA aws1vexternal-aws1oexternal[1] state change: CONNECTING => DESTROYING
Jun 17 17:36:04 ip-10-198-0-164 charon: 08[MGR] check-in and destroy of IKE_SA successful

これまでに試したことは以下の通りです。

1) 検証済みレイヤー3

2) 再起動したマシン

3) leftid= を追加してみました

4) ipsec update を実行してから ipsec restart を実行しました

5) confif 設定で nat_traversal=yes を追加してみました (ipsec statusall は IKEv2 を使用して検証されており、ドキュメントによると nat_traversal が自動的に使用されるため、これは問題にならないことに注意してください)

6) virtual_private を省略してみました <-- AWS openswan ドキュメントに従って使用されたため、strongswan 構成に含めました。

7) /etc/sysctl.conf で net.ipv4.conf.all.send_redirects = 0 と net.ipv4.conf.all.accept_redirects = 0 を無効にしてみました

8) EIP の代わりにプライベート IP を使用しようとしました。ソケット エラーは発生しなくなりましたが、明らかに 2 つの IP はピアリングのために相互に通信できません...

9) strongswan.conf に以下を追加してみました: load = aes des sha1 sha2 md5 gmp random nonce hmacstroke kernel-netlink socket-default updown

10) leftfirewall=yes を試したが、機能しなかった

助けてください！ ありがとう！

編集#1:

Michael の回答により、元の問題は解決しましたが、ルーティングに関連する新しい問題が発生しました。両方の VPN インスタンスが相互に ping できません。さらに、いずれかのサブネットのランダムなインスタンスから別のランダムなインスタンスまたは遠端の VPN インスタンスに ping しようとすると、次の ping 応答が返されます。

root@ip-10-194-0-80:~# ping 10.198.0.164
PING 10.198.0.164 (10.198.0.164) 56(84) bytes of data.
From 10.194.0.176: icmp_seq=1 Redirect Host(New nexthop: 10.194.0.176)
From 10.194.0.176: icmp_seq=2 Redirect Host(New nexthop: 10.194.0.176)
From 10.194.0.176: icmp_seq=3 Redirect Host(New nexthop: 10.194.0.176)
From 10.194.0.176: icmp_seq=4 Redirect Host(New nexthop: 10.194.0.176)

明らかに、これは 2 つの VPN インスタンス間のルーティングの問題であるはずです (おそらく strongswan 構成またはインスタンス ルーティング テーブルが原因)。これは、オレゴン サブネットの 10.194.0.80 ホストがオレゴン VPN インスタンスから応答を受信できるためです。インスタンス上のルート テーブル + traceroute:

root@ip-10-194-0-80:~# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.194.0.1      0.0.0.0         UG        0 0          0 eth0
10.194.0.0      0.0.0.0         255.255.255.0   U         0 0          0 eth0

root@ip-10-194-0-80:~# traceroute 10.198.0.164
traceroute to 10.198.0.164 (10.198.0.164), 30 hops max, 60 byte packets
 1  10.194.0.176 (10.194.0.176)  0.441 ms  0.425 ms  0.409 ms^C

openswan を使用していたときは、各インスタンスのルーティング テーブルを手動で変更する必要はありませんでした。

オレゴン VPN インスタンスのルーティング テーブルは次のとおりです。

root@ip-10-194-0-176:~# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.194.0.1      0.0.0.0         UG        0 0          0 eth0
10.194.0.0      0.0.0.0         255.255.255.0   U         0 0          0 eth0

ちょっと困惑しています。

編集#2:

VPNインスタンス間のルーティングは問題ではないようです: /var/log/syslogには、1つのVPNインスタンスのパブリックIPから別のVPNインスタンスに受信されたパケットが表示されます。

Jun 23 19:57:49 ip-10-194-0-176 charon: 10[NET] received packet: from 54.X.X.X[4500] to 10.194.0.176[4500] (76 bytes)

児童安全協会に関連した問題のようです:

aws1oexternal-aws1nvexternal:   child:  10.194.0.0/16 === 10.198.0.0/16 TUNNEL, dpdaction=restart
Security Associations (1 up, 0 **connecting**):

ログファイル:

Jun 23 19:52:19 ip-10-194-0-176 charon: 02[IKE] failed to establish CHILD_SA, keeping IKE_SA
Jun 23 19:52:48 ip-10-194-0-176 charon: 11[IKE] queueing CHILD_CREATE task
Jun 23 19:52:48 ip-10-194-0-176 charon: 11[IKE]   activating CHILD_CREATE task
Jun 23 19:52:48 ip-10-194-0-176 charon: 06[IKE] establishing CHILD_SA aws1oexternal-aws1nvexternal
Jun 23 19:52:48 ip-10-194-0-176 charon: 10[IKE] received FAILED_CP_REQUIRED notify, no CHILD_SA built
Jun 23 19:52:48 ip-10-194-0-176 charon: 10[IKE] failed to establish CHILD_SA, keeping IKE_SA
Jun 23 19:52:49 ip-10-194-0-176 charon: 14[CFG] looking for a child config for 10.194.0.0/16 === 10.198.0.0/16 
Jun 23 19:52:49 ip-10-194-0-176 charon: 14[CFG] found matching child config "aws1oexternal-aws1nvexternal" with prio 10
Jun 23 19:52:49 ip-10-194-0-176 charon: 14[IKE] configuration payload negotiation failed, no CHILD_SA built
Jun 23 19:52:49 ip-10-194-0-176 charon: 14[IKE] failed to establish CHILD_SA, keeping IKE_SA

***編集 #3: 問題は解決しました (えーと、実際には下の編集 #4 を参照してください...)****

問題は修正されました。

1) Michael の設定指示に正しく従っていませんでした。また、rightsourceip と leftsourceip を一緒に設定したため、両方のインスタンスが両方ともイニシエーターであると認識してしまいました。一方がイニシエーターで、もう一方がリクエスターであることを確認しました。これで IKE の問題は解決しました。

2) esp パラメータも明示的に設定する必要があることがわかりました。すでにデフォルト (aes128-sha1,3des-sha1) があるにもかかわらず、インスタンスが esp または ah (両方ではない) を使用することを認識できるように、esp パラメータを設定する必要があります。最終的に、aes128-sha1-modp2048 を使用しました。

この投稿が、次の Linux 初心者がセットアップする際に役立つことを願っています。

乾杯！

編集＃4：問題は（実際には）解決していない

strongswan に関連する別の問題をトラブルシューティングしているときに、「leftfirewall」パラメータを変更してテストしましたが、別の問題は解決しませんでした。その後、以前の元の構成に戻しました (leftfirewall をコメント アウトしました)。すると、トンネル経由で ping できなくなったことに気付きました。何が起こったのかを解明しようと何時間も頭を悩ませた後、esp パラメータをコメント アウトしてどうなるかを確認しました。これで、再びトンネル経由で ping できるようになりました! <- つまり、ipsec ゴーストが動き回って私をだましていて、esp パラメータが TS_UNACCEPTABLE エラーの修正ではない可能性があります (ただし、オンラインの他のリソースでは、esp パラメータが修正であると述べられています...)

編集＃5：問題は完全に解決しました

結局、すべてをテスト環境に移動し、最初からやり直すことにしました。Ubuntu リポジトリにあった古いバージョン (5.1.2) ではなく、最新バージョン (5.3.2) を使用してソースからインストールしました。これにより、上記の問題が解決し、VPN トンネルを介した複数のサブネット間で netcat (素晴らしいツールです!!) を使用してレイヤー 7 の接続を検証しました。

また：それはないVPC の DNS ホスト名を有効にするために必要です (Amazon から誤って信じ込まされたため)。参考までに>

これがすべて役立つことを願っています!!!!!!

追加編集 2017年2月11日:

JustEngland のリクエストに従い、以下の動作構成をコピーします (いかなる形であれ識別されないように特定の詳細は省略しています)。

サイドA:

# ipsec.conf - strongSwan IPsec configuration file

# basic configuration
config setup
# Add connections here.
conn %default
 ikelifetime= You choose; must match other side
 keylife= You choose; must match other side
 rekeymargin= You choose; must match other side
 keyingtries=1
 keyexchange= You choose; must match other side
 authby=secret
 mobike=no

conn side-a
 left=10.198.0.124
 leftsubnet=10.198.0.0/16
 leftid=54.y.y.y
 leftsourceip=10.198.0.124
 right=52.x.x.x
 rightsubnet=10.194.0.0/16
 auto=start
 type=tunnel
# Add connections here.


root@x:~# cat /etc/ipsec.secrets 
A.A.A.A B.B.B.B : PSK "Your Password"

サイドB:

# ipsec.conf - strongSwan IPsec configuration file

# basic configuration
config setup

conn %default
 ikelifetime= You choose; must match other side
 keylife= You choose; must match other side
 rekeymargin= You choose; must match other side
 keyingtries=1
 keyexchange= You choose; must match other side
 authby=secret
 mobike=no

conn side-b
 left=10.194.0.129
 leftsubnet=10.194.0.0/16
 leftid=52.x.x.x
 right=54.y.y.y
 rightsubnet=10.198.0.0/16
 rightsourceip=10.198.0.124
 auto=start
 type=tunnel

root@x:~# cat /etc/ipsec.secrets 
B.B.B.B A.A.A.A : PSK "Your Password"

答え1

VPCでは、インスタンスのパブリックIPアドレスはインスタンスのスタックにバインドされないため、内部プライベートアドレスと外部パブリックアドレスの両方を設定する必要があります。無効な引数これは、インスタンスに認識されていないパブリック IP アドレスから直接トラフィックを送信しようとしたことが原因であると考えられます。

left=10.10.10.10         # instance private IP of local system
leftsourceip=10.10.10.10 # instance private IP of local system
leftid=203.x.x.x         # elastic IP of local system
leftsubnet=10.x.x.x/xx

rightsubnet=10.x.x.x/xx
right=198.x.x.x          # elastic IP of remote system

答え2

問題は修正されました。

1) Michael の設定指示に正しく従っていませんでした。また、rightsourceip と leftsourceip を一緒に設定したため、両方のインスタンスが両方ともイニシエーターであると認識してしまいました。一方がイニシエーターで、もう一方がリクエスターであることを確認しました。これで IKE の問題は解決しました。

2) esp パラメータも明示的に設定する必要があることがわかりました。すでにデフォルト (aes128-sha1,3des-sha1) があるにもかかわらず、インスタンスが esp または ah (両方ではない) を使用することを認識できるように、esp パラメータを設定する必要があります。最終的に、aes128-sha1-modp2048 を使用しました。

関連情報