web-dev-qa-db-ja.com

ipsec / strongswan-routeコマンドを使用してリモートルーターをローカルゲートウェイとして使用する方法

わかりました、これは簡単なものであるはずですが、それは私を狂わせます。

シナリオ：

サイトA（サンフランシスコ）サイトB（コロンビア）

両方のサイトはIPSec（openswan、debian 8）を介して正常に接続されています。

SiteA --------------- SiteB
10.2.0.1 <== inet ==> 10.3.0.1

SiteAから10.3.0.1を正常にPINGできます。また、10.3.0.0サブネット内の10個の内線電話がSiteAに接続します。甘い、問題ありません。

ただし、10.3.0.1 リストされていません SiteAのカーネルルーティングテーブルの下の任意の場所のルートとして注意してください。ただし、10.2.0.1からpingを実行すると、機能します。

問題：

OK。 SiteBにSIPルーター10.11.208.93を追加しました。SiteAは10.11.208.94である必要があり、10.3.0.1経由で10.11.208.93に到達できる必要があります。このブリッジを正常に追加しました。 SiteBの10.3.0.1。

SiteAの10.3.0.1経由でSIPルーターへの静的ルートを作成しようとすると、routeコマンドはホストに到達できないと表示しますが、SiteAから10.3.0.1にpingを実行できます。

ip route add -net 10.11.208.92/30 via 10.3.0.1

SIOADDR：ホストに到達できません

質問は次のとおりです。トンネル経由で10.3.0.1に到達するようにLinuxルーティングテーブルを構成するstrongswan（ipsec）はどこで/どのようになっていますか？ルーティングテーブルには表示されません。

10.3.0.1にpingを実行できる場合、トンネルがすでに機能しているのに、背後のサブネットに到達するためのルートとして使用できないのはなぜですか？

routingstrongswan
1
Pedro Guillem

strongSwanは、デフォルトでルーティングテーブル220にルートをインストールします。これらはip route list table 220で確認できます。

ただし、ルートを追加しても、トラフィックはトンネリングされません。 IPsecはポリシーベースであるため（これらはip xfrm policyで確認できます）、たとえば、IPsecポリシーが10.2.0.0/16および10.3.0.0/16は、一致するトラフィックのみが実際にトンネリングされます。これは、10.11.208.94から10.11.208.93に送信されたパケットには当てはまりません。したがって、これらのIPをカバーするトンネルを明示的に追加する必要があります。

4
ecdsa