web-dev-qa-db-ja.com

openswan複数サブネットのルーティングの問題

CentOS 6.5（最終）にOpenSwan（2.6.32）をセットアップして、AmazonクラウドのリモートVPCゲートウェイに接続しようとしています。トンネルを登った。ただし、ルーティングされるのは、leftsubnetsで定義された最後のIP範囲との間のトラフィックのみです。最初のものは少しの間（おそらく2番目のトンネルがアップする前に）機能し、その後はルーティングを行いません。以下は私の設定です。

conn aws-vpc
    leftsubnets={10.43.4.0/24 10.43.6.0/24}
    rightsubnet=10.43.7.0/24
    auto=start
    left=206.191.2.xxx
    right=72.21.209.xxx
    rightid=72.21.209.xxx
    leftid=206.191.2.xxx
    leftsourceip=10.43.6.128
    authby=secret
    ike=aes128-sha1;modp1024
    phase2=esp
    phase2alg=aes128-sha1;modp1024
    aggrmode=no
    ikelifetime=8h
    salifetime=1h
    dpddelay=10
    dpdtimeout=40
    dpdaction=restart
    type=tunnel
    forceencaps=yes

IPsecサービスの開始後：

# service ipsec status
IPsec running  - pluto pid: 8601
pluto pid 8601
2 tunnels up
some eroutes exist

# ip xfrm policy
src 10.43.6.0/24 dst 10.43.7.0/24 
dir out priority 2344 ptype main 
tmpl src 206.191.2.xxx dst 72.21.209.xxx
    proto esp reqid 16389 mode tunnel
src 10.43.7.0/24 dst 10.43.6.0/24 
dir fwd priority 2344 ptype main 
tmpl src 72.21.209.xxx dst 206.191.2.xxx
    proto esp reqid 16389 mode tunnel
src 10.43.7.0/24 dst 10.43.6.0/24 
dir in priority 2344 ptype main 
tmpl src 72.21.209.xxx dst 206.191.2.xxx
    proto esp reqid 16389 mode tunnel
src 10.43.4.0/24 dst 10.43.7.0/24 
dir out priority 2344 ptype main 
tmpl src 206.191.2.xxx dst 72.21.209.xxx
    proto esp reqid 16385 mode tunnel
src 10.43.7.0/24 dst 10.43.4.0/24 
dir fwd priority 2344 ptype main 
tmpl src 72.21.209.xxx dst 206.191.2.xxx
    proto esp reqid 16385 mode tunnel
src 10.43.7.0/24 dst 10.43.4.0/24 
dir in priority 2344 ptype main 
tmpl src 72.21.209.xxx dst 206.191.2.xxx
    proto esp reqid 16385 mode tunnel

接続をテストするためだけに完全にオフにしたので、ファイアウォールはここでは何の役割も果たしていないと思います。ルートも期待どおりに機能しています。左側の単一のネットワークを個別のテスト接続で個別に定義すると、どちらのサブネットにも到達できます。 leftsubet sを定義した場合にのみ、最後に到達した範囲が最後にルーティングされます。どちらが先でも、ルーティングが停止する前に少しの間動作します。

私はインターネット上の誰も同じような問題を見つけることができませんでした...誰かが私を啓発してくれませんか？

乾杯、

ボー

centosopenswan
3
user2413287

leftsubnetsを使用する場合、rightsubnetsではなくrightsubnetを使用する必要があります。 http://linux.die.net/man/5/ipsec.conf で述べたように：

両方の場合、leftsubnets=およびrightsubnets=が定義されている場合、サブネットトンネルのすべての組み合わせがインスタンス化されます。

5
andyb

これは、AWSのIPSecの実装がSPI（セキュリティパラメータインデックス）を処理する方法に障害があるためです。詳細は libreswanのWebサイト で読むことができますが、要は、2つのトンネルを確立することでlibreswanが2つの範囲を処理することです（あなたの場合、aws-vpc/1x1とaws-vpc/1x2）。 OpenSWANとStrongSWANも同様です。

これらのトンネルにはそれぞれ独自のSA（セキュリティアソシエーション）があり、それぞれが送信するトラフィック（SPI）とAmazonが送信するトラフィック（SPI）のSPIペアで識別されます。アマゾン、いずれかのトンネルが最初に起動したときにSPI＃1を確立しているにもかかわらず、replacesSPI＃2で2番目のトンネルが起動します（トンネル1にSPI＃1を保持し、必要に応じてトンネル2だけにSPI＃2を使用するのではなく）。トラフィックはSPI＃1を使用してAWSダウントンネル1に送信されますが、AmazonはSPI＃2を使用して応答を暗号化します。これにより、トラフィックは当然、エンドでの復号化に失敗します。

そのため、最初のトンネルは、トンネル2がアップするまでの非常に短い期間のみ機能します。しばらくして、最後にトンネル1のSPIの再生成を強制すると、それは機能し始めますが、Amazonの新しいSPI＃1は、トンネル2の古いSPIを置き換えます、トンネル2は、トンネル1がサービスを再開するのと同じように動作を停止します。

私はこれを数年離れた2つの別々の機会に遭遇しましたが、最近では昨日なので、AWSがこれを修正する可能性は低いと思います。商用のIPSec実装には影響しないようです（またはAWSで修正されているはずです）。guessingです。トンネルの概念が実際にはないからです。サブネット間ですが、すべてが同じSPIを共有するホストホストトンネルの束を集約するだけです。ただし、これは推測にすぎません。

編集：奇妙なことに、適切なAWSサポート契約を結んでいるクライアントのためにこれまでの1週間を費やしたおかげで、libreswanが最新について何を言わなければならなかったかを確認しましたSPI以前に確立されたものを誤って置き換えます。 Amazonはまた、彼らがこれを行っていること、および1つのvpn-エンティティは、彼らの考えでは、1組のSPIしかサポートできないことも確認しました。彼らのアドバイスは、トンネルが1つだけ作成されるようにS/WANを構成し、それを介してトラフィックを特定の宛先にルーティングすることです。

さいわい、最近のLinuxカーネルが適度であれば、libreswanはバージョン3.18以降でこれをサポートします。 CentOS 7が両方の点で満足していることを確認できます。

その詳細な記述は wiki上 ですが、Linux仮想トンネルインターフェース（vti）デバイスを使用して非常に広いソースと宛先の範囲（0.0.0.0/0）でトンネルを確立し、次にlibreswanにルーティングを設定します（vti-routing=no）。次に、単純なルートステートメント（ip route add 10.0.0.0/8 dev vti01）を使用して、このトンネル経由で到達する宛先を選択できます。

私はこれを生産で働いています。複数の同時トンネルもサポートします。後のトンネルでは、異なるmark=およびvti-interface=構成オプションを使用します。 Amazonは、VPNとトランジットゲートウェイ（TGW）との関連付けもサポートするようになりました。TGWには、同じAWSリージョン内の多くのVPNを関連付けることができるため、実際には、AWSリージョンごとに1つのVPNのみが必要であり、スケーラブルです。

1
MadHatter

使ってみてください：

leftsubnets={10.43.4.0/24,10.43.6.0/24,}

の代わりに：

leftsubnets={10.43.4.0/24 10.43.6.0/24}

注：2つのコンマを追加します。最初と最後の後も。

1
Rajesh Gupta