☰

2つのIPsecトンネル間のトラフィックをルーティングする

tag-icon • tag-icon vpn ipsec strongswan backend libreswan
2つのIPsecトンネル間のトラフィックをルーティングする

私はDOインフラストラクチャのバックエンドを運営しています。これをサイトと呼びますイヴィ、サードパーティのサイトに接続する地方IPsec トンネル経由で、次の libreswan 設定を使用します。

conn prov-client
  ...
  right=$YVI_IP
  rightsourceip=10.31.3.1
  rightsubnet=10.31.3.0/28
  left=$PROV_IP
  leftsubnet=10.70.0.36/28

地方にはサーバーが稼働しており10.70.0.37、私はそこから対話することができますイヴィ。

私の問題は、ローカル開発環境（別のネットワークのUbuntuボックス）を設定しており、変更を加えるたびにデプロイする必要があることです。イヴィそこからのみAPIにアクセスできるため地方これを回避したいのですが地元にイヴィそのトラフィックをルーティングする地方APIにアクセスできるようにするには地方から地元開発を容易にします。

私は接続する地元にイヴィ次の構成を持つロード ウォリアーとして:

conn remote-dev-client
  ...
  left=$YVI_IP
  leftsubnet=10.31.3.0/28
  right=%any
  rightaddresspool=10.31.4.1-10.31.4.254

接続が正常に確立され、地元私は到達10.31.3.1できるイヴィ私が望んでいるの10.70.0.37は地方から地元ネットワークへのルート10.70.0.36/28は自動的に追加されないので、手動でいくつかのルールip xfrmを設定してみました。ip route地元:

# Outgoing
ip xfrm policy add dst 10.70.0.37 src 10.31.4.1 dir out tmpl src $LOCAL_IP dst $YVI_IP proto esp spi $SPI reqid $REQID mode tunnel priority 100000

# Incoming
ip xfrm policy add dst 10.31.4.1 src 10.70.0.37 dir fwd tmpl src $YVI_IP dst $LOCAL_IP proto esp reqid $REQID mode tunnel priority 100000
ip xfrm policy add dst 10.31.4.1 src 10.70.0.37 dir in tmpl src $YVI_IP dst $LOCAL_IP proto esp reqid $REQID mode tunnel priority 100000

ip route add table 220 src 10.31.4.1 10.70.0.37 via $LOCAL_IP dev $LOCAL_IF proto static

私は今走りip xfrm monitor続けるイヴィそして地元ping 10.70.0.37; パケットが到着しているのがわかりますイヴィ（xfrmモニターからイヴィ）ですが、送信のみで、応答はありません（例えば10.31.3.1にpingすると、応答が見られます）。イヴィトラフィックを受信して​​いるが、ルーティングしていない地方? これをどう解釈したらいいのか本当にわかりません。

ルートを追加する必要があると思いますイヴィトラフィックをルーティングする地方API は正しく機能していますが、上記と同様のルールを追加しても機能しません。何が欠けているのか、何が間違っているのかを理解するために助けていただければ幸いです。

異なるアプローチの提案も歓迎しますが、地方私が管理していないIPsecトンネル経由でイヴィ、それは私がコントロールしています。

答え1

私は iptables NAT ルールでこの問題を解決できました。ip xfrmポリシーは必要ありませんでした。これは、専門家ではない私のために、私が行ったことの簡単な説明です。

からイヴィ私はロードウォリアーに10.31.4.0/24サブネットを割り当てているので、そのネットワークのルートはキーデーモン（私の場合はlibreswan）によって自動的にインストールされるので、NATルールを追加しました。イヴィ(/etc/ufw/before.rules私は UFW を使用していますが、直接使用しても同じ結果が得られますiptables):

*nat
-F
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]

# PRE 
-A PREROUTING -s 10.31.4.0/24 -d 10.31.3.2 -j DNAT --to-destination 10.70.0.37


# POST
-A POSTROUTING -s 10.31.4.0/24 -d 10.70.0.37 -j SNAT --to-source 10.31.3.1

COMMIT

は*nat、iptables に NAT テーブルにルールを適用するように指示し、 はCOMMIT実際にルールを保存します。 は-F利便性のためだけに存在します。UFW は にルールを追加しますufw enableが、 ではルールを削除しないufw disableため、重複が生じてしまいます。そのため、フラッシュ フラグが使用されます-F。

このPREROUTINGルールは、ロードウォリアーサブネットから 宛てに着信するパケットに適用され10.31.3.2、宛先アドレスを ではなく に変更し10.70.0.37、10.31.3.2実質的にそのIPアドレスを に割り当てます。地方ロードウォリアーの観点から見たサーバー。

このPOSTROUTINGルールは、ロードウォリアーサブネットから送信されようとしているパケット10.70.0.37（つまり、事前ルーティングルールにヒットしたパケット）に適用され、宛先アドレスを のアドレスから に変更します10.31.4.0/0。10.31.3.1これは、 のルート、サーバー、その他のものを制御できないため必要です。地方なので、もし地方サブネットから要求を受け取った場合10.30.4.0/24、どのように応答すればよいかわかりません。しかし、次のことは知っています10.31.3.1。

これで完了です！これで地方から地元経由イヴィで10.31.3.2。

関連情報