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


10

Ubuntu 14.04.2 LTSを実行している2つのAmazon AWS EC2インスタンス間にStrongSwan 5.1.2を使用して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)

以下は/etc/ipsec.confです (これはオレゴンからのものですが、N | Virginiaインスタンスでも同じですが、左|右の値が逆になっています)

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 hmac stroke kernel-netlink socket-default updown

10)leftfirewall = yesを使用してみましたが、機能しませんでした

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

編集#1:

マイケルの応答は元の問題をクリアしましたが、ルーティングに関連する新しい問題があります。両方の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)

Oregonサブネット内の10.194.0.80ホストはOregon VPNインスタンスから応答を受信できるため、これは2つのVPNインスタンス間のルーティングの問題である可能性があります(おそらくstrongswan構成またはインスタンスルーティングテーブルが原因です)。ルートテーブル+インスタンスの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を使用していたとき、各インスタンスのルーティングテーブルを手動で変更する必要はありませんでした。

Oregon 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**):

/ var / log / syslog:

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を一緒に構成したので、両方のインスタンスに、両方がイニシエーターであると信じ込ませました。1つは開始者、もう1つは要求者であることを確認しました。これにより、IKEの問題が修正されました。

2)espパラメータも明示的に設定する必要があることがわかりました。デフォルト(aes128-sha1,3des-sha1)がすでに存在する場合でも、インスタンスがesp OR 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"

作業構成を投稿していただけませんか。
JustEngland 2017

確かに、私の元の質問の投稿に編集として構成を追加します。セットアップにアクセスできなくなったため、構成が正しいかどうかを100%確認することはできません。しかし、彼らは:)でなければなりません
LOBI

回答:


7

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

こんにちはマイケル、元の問題を修正しましたが、strongswanの構成が原因でルーティングの問題が発生しているようです。1つのVPNインスタンスから別のVPNインスタンス(タイムアウト)にpingを実行できず、サブネット内から別のインスタンスからpingを実行しようとすると、次のメッセージが表示されます。10.194.0.176から:icmp_seq = 4 Redirect Host(Newネクストホップ:10.194.0.176)
ロビ2015年

オリジナルの投稿を編集しました
lobi

理解した。Michaelsの設定を正しく実装しませんでした(rightsourceipも含めたため、どちらがイニシエーターで、どちらがリクエスターであるかがわかりません)。また、espパラメータを明示的に設定する必要もありました。
lobi 2015年

1

問題が修正されました。

1)Michaelの設定の指示に正しく従っていない。また、rightsourceipとleftsourceipを一緒に構成したので、両方のインスタンスに、両方がイニシエーターであると信じ込ませました。1つは開始者、もう1つは要求者であることを確認しました。これにより、IKEの問題が修正されました。

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


これが100%修正されているかどうかはわかりません。元の投稿の編集4をご覧ください。
lobi 2015
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.