Windows7からAmazonEC2へのOpenSwan / xl2tpdを使用したIPSec / L2tpへの接続
自宅のWindows7からAmazonのUbuntuEC2インスタンスのOpenSwan/xl2tpdセットアップに接続しようとしています。
これは、クライアント側とサーバー側の両方からNATされている接続です。
この接続を実現する方法について、いくつかのスレッドからのヒントに従っていましたが、すべてで失敗しました
私が最も困惑しているのは、ログの次の行です。
7月13日11：04：21ip-10-117-59-224 pluto [8782]： "connRW48" [2] 85.178.143.82＃1：IPsec SAリクエストに応答できません23.21.84.48/32 == = 10.117.59.224 [23.21.84.48、+ S = C]：17/1701 ... 85.178.143.82 [192.168.2.103、+ S = C]：17 /の接続が不明なため1701 === 192.168.2.103/32
この接続は、leftidとして識別される外部IPで明らかに存在します（ipsec auto --statusについては以下を参照）。なぜ見つからないのですか？または私は他に何が間違っていますか？
助けていただければ幸いです。
私の構成：
私が使用しているIP：
- EC2インスタンスの内部IP：10.117.59.224
- インスタンスに関連付けられたエラスティックIP：23.21.84.48
- 自宅のルーターに関連付けられているISPのIP：85.178.143.82
- 私の家NAT IP：192.168.2.103
現在、/ var/log /auth.logに次のエラーメッセージが表示されています。
7月13日11：03：55ip-10-117-59-224 pluto [8782]：ディレクトリ '/etc/ipsec.d/ocspcerts'
7月13日11:03へのパスを変更しました：55 ip-10-117-59-224 pluto [8782]：ディレクトリ '/etc/ipsec.d/crls'
7月13日11：03：55ip-10-117-59-224に変更pluto [8782]：警告：空のディレクトリ
7月13日11：03：55ip-10-117-59-224 pluto [8782]：IKEメッセージをリッスンしています
7月13日11:03： 55 ip-10-117-59-224 pluto [8782]：インターフェースeth0/eth0 10.117.59.224：500
7月 13日11：03：55ip-10-117-59-224 pluto [8782]を追加：インターフェイスlo/lo 127.0.0.1：500
7月 13日11：03：55ip-10-117-59-224 pluto [8782]：インターフェイスlo/lo :: 1：500 [.____を追加。] 7月13日11：03：55ip-10-117-59-224 pluto [8782]：「/ etc/ipsec.secrets」からシークレットを読み込んでいます
7月13日11：03：55ip-10- 117-59-224 pluto [8782]：keyidの秘密鍵をロードしました：PPK_RSA：AQOnFE96U
7月13日11：03：57ip-10-117-59-224 pluto [8782]：接続の説明「connRW48 "
7月13日11：04：20ip-10-117-59-224 pluto [8782]：85.178.143.82からのパケット： 500：ベンダーIDペイロードを無視します[MS NT5 ISAKMPOAKLEY 00000008]
7月13日11：04：20ip-10-117-59-224 pluto [8782]：85.178.143.82：500からのパケット：受信したベンダーIDペイロード[RFC 3947] meth = 109、ただしポートフローティングがオフ
7月13日11：04：20ip-10-117-59-224 pluto [8782]：85.178.143.82：500からのパケット：受信したベンダーIDペイロード[draft-ietf-ipsec-nat-t-ike-02_n] meth = 106、ただしポートフローティングはオフです
7月13日11：04：20ip-10-117-59-224 pluto [8782] ：85.178.143.82：500からのパケット：ベンダーIDペイロードを無視[断片化]
7月13日11：04：20ip-10-117-59-224 pluto [8782]：85.178.143.82：500からのパケット：ベンダーIDペイロードを無視する[MS-NegotiationDiscovery Capable]
7月13日11：04：20ip-10-117-59-224 pluto [8782]：85.178.143.82：500からのパケット：ベンダーIDペイロードを無視する[ Vid-Initial-Contact]
7月13日11：04：20ip-10-117-59-224 pluto [8782]：85.178.143.82：500からのパケット：ベンダーIDペイロードを無視[IKECGAバージョン1]
7月13日11：04：20ip-10-117-59-224 pluto [8782]： "connRW48" [1] 85.178.143.82＃1：不明なピアからのメインモードへの応答85.178.143.82
7月13日11：04：20ip-10-117-59-224 pluto [8782]： "connRW48" [1 ] 85.178.143.82＃1：OAKLEY_GROUP20はサポートされていません。属性OAKLEY_GROUP_DESCRIPTION
7月13日11：04：20ip-10-117-59-224 pluto [8782]： "connRW48" [1] 85.178.143.82＃1：OAKLEY_GROUP19はサポートされていません。属性OAKLEY_GROUP_DESCRIPTION
7月13日11：04：20ip-10-117-59-224 pluto [8782]： "connRW48" [1] 85.178.143.82＃1：状態STATE_MAIN_R0から状態STATE_MAIN_R1 [.____への移行。] 7月13日11：04：20ip-10-117-59-224 pluto [8782]： "connRW48" [1] 85.178.143.82＃1：STATE_MAIN_R1：MR1を送信、MI2を期待
7月13日11 ：04：20 ip-10-117-59-224 pluto [8782]： "connRW48" [1] 85.178.143.82＃1：状態STATE_MAIN_R1から状態STATE_MAIN_R2への移行
7月13日11：04：20ip -10-117-59-224 pluto [8782]： "connRW48" [1] 85.178.143.82＃1：STATE_MAIN_R2：MR2を送信し、MI3を期待しています
7月13日11：04：21ip-10-117- 59-224 pluto [8782]： "connRW48" [1] 85.178.143.82＃1：メインモードのピアIDはID_IPV4_ADDR： '192.168.2.103'
7月13日11：04：21ip-10-117- 59-224 pluto [8782]： "connRW48" [1] 85.178.143.82＃1： "connRW48"から "connRW48"に切り替え
7月13日11：04：21ip-10-117-59-224 pluto [8782]： "connRW48" [2] 85.178.143.82＃1：ピア85.178.143.82との接続 "connRW48"インスタンスを削除します{isakmp =＃0/ipsec =＃0}
7月13日11：04：21ip-10-117-59-224 pluto [8782]： "connRW48" [2] 85.178.143.82＃1：状態STATE_MAIN_R2から状態STATE_MAIN_R3
への移行7月13日11：04：21ip-10-117-59-224 pluto [8782]： "connRW48" [2] 85.178.143.82＃1：STATE_MAIN_R3：送信MR3、ISAKMP SA確立{auth = OAKLEY_PRESHARED_KEY cipher = aes_256 prf = oakley_sha group = modp2048}
7月13日11：04：21ip-10-117-59-224 pluto [8782]： "connRW48" [2] 85.178.143.82＃1：ピア提案：23.21.84.48/32：17/1701->192.168.2.103/32:17/0
7月13日11：04：21ip-10-117-59-224 pluto [8782]： " connRW48 "[2] 85.178.143.82＃1：23.21.84.48/32 == = 10.117.59.224 [23.21.84.48、+ S = C]の接続が不明なため、IPsec SA要求に応答できません。 ：17/1701 ... 85.178.143.82 [192.168.2.103、+ S = C]：17/1701 === 192.168.2.103/32
7月13日11：04：21ip-10-117- 59-224 pluto [8782]： "connRW48" [2] 85.178.143.82＃1：暗号化された通知INVALID_ID_INFORMATIONを85.178.143.82:500
7月13日11：04：22ip-10-117-59-に送信224 pluto [8782] ： "connRW48" [2] 85.178.143.82＃1：提案されたピア：23.21.84.48/32：17/1701->192.168.2.103/32:17/0
7月13日11：04：22ip -10-117-59-224 pluto [8782]： "connRW48" [2] 85.178.143.82＃1：23.21.84.48/32 ==の接続が不明なため、IPsec SA要求に応答できません= 10.117.59.224 [23.21.84.48、+ S = C]：17/1701 ... 85.178.143.82 [192.168.2.103、+ S = C]：17/1701 === 192.168.2.103/32
私のセキュリティグループは、UDPポート500および4500などの着信通信を許可しています
私のiptablesは、とりわけ1701も許可します
私の/etc/ipsec.conf：
バージョン2.0 config setup protostack = netkey interfaces =％defaultroute nat_traversal = yes virtual_private =％v4：10.0 .0.0/8、％v4：172.16.0.0/12 oe = no nhelpers = 0 disable_port_floating = yes include /etc/ipsec.d/ * .conf
私の/etc/ipsec.d/connRW48.conf
conn connRW48 rightsubnet = vhost：％no、％priv type = transport authby = secret pfs = no rekey = no ikelifetime = 8h keylife = 1h leftprotoport = 17/1701 left = 10.117.59.224 ＃leftid = @ ip- 10-117-59-224.ec2.internal leftid = 23.21.84.48 rightprotoport = 17/0 right =％any auto = ignore
私の（検閲された）/etc/ipsec.secrets：
：RSA {
＃RSA2048ビットip-10-117-59-224Tue Jul 10 14:01:50 2012
＃署名のみ、UNSAFE FOR ENCRYPTION
＃pubkey = XXXXXXX
モジュラス：XXX
PublicExponent：0x03
＃このポイント以降はすべて秘密です
PrivateExponent：XXX
Prime1： XXX
Prime2：XXX
Exponent1：XXX
Exponent2：XXX
係数：XXX
}
＃インデントを変更しないその "}"
@ ip-10-117-59-224.ec2.internal％any：PSK "XXX"
23.21.84.48％any：PSK "XXX"
'ipsec verify'の実行からの出力：
IPsecがインストールされ、正しく開始されたかどうかを確認するためのシステムのチェック： バージョンチェックとipsecオンパス[OK] LinuxOpenswan U2.6.37/K3.2.0-25- virtual（netkey） カーネルでのIPsecサポートの確認[OK] SArefカーネルサポート[N/A] NETKEY：XFRM関連のproc値のテスト[OK] [OK] [OK] plutoが実行されていることを確認する[OK] udp500でIKEをリッスンするPluto [OK] NATをリッスンするPluto- T on udp 4500 [FAILED] 「ip」コマンドの確認[OK] /bin/shの確認は/ bin/dashではありません[警告] 「iptables」の確認コマンド[OK] Opportunistic Encryption Support [無効]
'ipsec auto --status'を実行するための出力：
000カーネルインターフェイスを使用：netkey
000インターフェイスlo/lo :: 1
000インターフェイスlo/lo 127.0.0.1
000インターフェイスeth0/eth0 10.117.59.224
000％myid =（none）
000 debug none
000
000 virtual_private（％priv）：
000-2つのサブネットを許可：10.0 .0.0/8、172.16.0.0/12
000-許可されていない0サブネット：
000警告：virtual_private =の許可されていないサブネットは空です。内部で使用している
000のプライベートアドレススペースがある場合は、除外する必要があります！
000
000アルゴリズムESP暗号化：id = 2、name = ESP_DES 、ivlen = 8、keysizemin = 64、keysizemax = 64
...
...
000アルゴリズムIKEdh group：id = 24、name = OAKLEY_GROUP_DH24、bits = 2048
000
000 stats db_ops：{curr_cnt、total_cnt、maxsz}：context = {0,0,0} trans = {0,0,0} attrs = {0,0,0}
000
000 "connRW48"：10.117.59.224 [23.21.84.48、+ S = C]：17/1701 ...％virtual [+ S = C]：17/0 == =？;ルーティングされていない; erouteの所有者：＃0
000 "connRW48"：myip = unset; hisip = unset;
000 "connRW48"：ike_life：28800s; ipsec_life：3600s; rekey_margin：540秒; rekey_fuzz：100％; keyingtries：0
000 "connRW48"：ポリシー：PSK + ENCRYPT + DONTREKEY + IKEv2ALLOW + SAREFTRACK + lKOD + rKOD;プリオ：32,32;インターフェイス：eth0;
000 "connRW48"：最新のISAKMP SA：＃0;最新のIPsecSA：＃0;
000
前もって感謝します
この問題は、WindowsクライアントからL2TPサーバーへのNATT接続を許可するためのWindowsレジストリパッチに関連しているようです。
Regパッチは次のとおりです。
Windowsレジストリエディタバージョン5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\PolicyAgent] "AssumeUDPEncapsulationContextOnSendRule" = dword：00000002
同様の設定でEC2でopenswanを実行していますが、Windowsクライアントは問題なく接続できます。問題が正確に何であるかはわかりませんが、ここに私の設定とあなたの設定の違いのいくつかがあります：
openswan 2.6.38
番号 version 2.0パラメータ。 setup構成の残りの部分はほぼ同じです。
（構成に合わせて調整された）自分とは異なる次のパラメーターを用意します。
leftsubnet=10.117.59.224/32
leftnexthop=%defaultroute # this might be redundant with netkey stack.
rightprotoport=17/%any
rightid=%any
forceencaps=yes
auth=esp
ike=3des-sha1
phase2alg=3des-sha1
ikelifetimeまたはkeylifeを指定していません。
ipsec.secretsはパブリックIPのみを参照し、@ internalエントリは参照しません。
この修正がWin7に適用されるかどうかはわかりませんが、XP/Vistaクライアントの場合、 http://support.Microsoft.com/kb）に従ってレジストリを編集する必要がありました。/926179
私のセキュリティポリシー（AWS SG/iptables/etc）は、着信UDP 1701,500,4500、プロトコル50、プロトコル51（ESP＆AH）を許可しています。