web-dev-qa-db-ja.com

iptables：VPNサーバーでLANから接続されたopenvpnクライアントにアクセス

私は本質的にルーティングの問題を抱えていますが、ネットワークのニーズを効果的にトラブルシューティングして設定するためのルーティングとiptablesに精通していません。

何が機能していますか

私はopenVPNネットワークをセットアップして機能させています。クライアントはインターネット経由でLANに接続できます。

私が起こりたいこと

...クライアントが特定のサブネット上のVPNに接続するとき。

  • クライアントはVPNネットワークからアクセスできる必要があります

ルールで次のいずれかを実行できる場合のボーナスポイント：

  • クライアントがVPNへの接続を開始できないようにする必要があります
  • クライアントはDNSに表示されます

トポロジー

ネットワークトポロジは次のようになります。

   ______        ____________________
 /        \     /                    \
| internet |---| client (10.8.8.0/24) |
 \________/     \____________________/
     |
   ______
 /        \
| gateway  |
 \________/
     |
-----LAN------ (10.10.10.0/24)
|    |   |   |
             L_____VPN Server `VPN1` 10.10.10.2 (fictional name/subnet)

現在の設定

ゲートウェイには次のルートが定義されています。

10.8.8.0    255.255.255.0   10.10.10.2  LAN & WLAN

VPN1では、iptablesには次のルールがあります

# Flush the filter and nat tables
iptables -t filter -F
iptables -t nat -F

iptables -A INPUT -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT

iptables -A INPUT -i eth0 -j ACCEPT -d 10.8.8.0/24
iptables -A FORWARD -i eth0 -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.10.10.0/16 -d 10.8.8.0/24 -o tun+ -j MASQUERADE

現在起こっていること

コマンドmtr 10.8.8.1（VPNに接続されたクライアントのIP）を実行すると、現在のルートがVPN1とゲートウェイの間で往復していることがわかります。

iptablesroutingopenvpntun
4
jobu1324

Iptablesのオンライン学習の狂気の別の過酷なラウンドの後、私は解決策を発見しました。

ただし、最初に、iptablesに関する無効な仮定があります。ルールへの最初のアプローチは、パケットが受信されると、INPUTチェーンとOUTPUTチェーンを通過するというものでした。そうではありません。ルールがパケットに一致する分、テーブルを離れます。指定されていない限り（「-t nat」など）、フィルターテーブルが想定されるため、リストされているほとんどのルールはフィルターテーブルで実行されます。

チェーンについて

  • [〜＃〜] input [〜＃〜]：サーバー宛てのパケットで実行
  • [〜＃〜] output [〜＃〜]：サーバーからのパケットで実行
  • [〜＃〜] forward [〜＃〜]：その他すべて-ルールがここに一致する場合、および「ジャンプ」（私は-jas "job";）はACCEPTであり、パケットは適切にルーティングされます

ルールの内訳

これは、上記の現在の設定でのルールの説明です

iptables -t filter -F
iptables -t nat -F

これらのルールは、filterおよびnatテーブルをフラッシュするだけです。 iptablesルールをクリアするためのより多くのテーブルとより徹底的な方法があることに注意してください。

iptables -A INPUT -i tun+ -j ACCEPT

このルールは何もしません、なぜなら：

  • 別のネットワークではなく、VPN1宛てのトラフィックで実行されます
  • 着信トラフィックにはポリシーが設定されていないため、デフォルトで許可されています

次に進みます...

iptables -A FORWARD -i tun+ -j ACCEPT

このルールにより、10.8.8.0/24からのトラフィックのルーティングが許可されます。 natテーブルのルールは、このルールに一致するパケットで実行されます。

iptables -A INPUT -i eth0 -j ACCEPT -d 10.8.8.0/24

10.8.8.0/24トラフィックの宛先がVPN1サーバーではないため、このルールは目的のルーティングにも影響しません。

iptables -A FORWARD -i eth0 -j ACCEPT

このルールにより、10.10.10.0/16からのトラフィックのルーティングが許可されます。

iptables -t nat -A POSTROUTING -s 10.10.10.0/16 -d 10.8.8.0/24 -o tun+ -j MASQUERADE

このルールにより、10.10.10.0/16からのVPN宛てのトラフィックはVPN1からのように見え、実質的にVPN1はゲートウェイのように見えます。

どうしましたか？

あるネットワークから次のネットワークへのトラフィックを取得するには、ルールは「OK」である必要があります。実際の保護機能はありません。デフォルトの「ドロップ」ポリシーなどですが、それは問題のポイントではありません。

VPNを介してトラフィックをルーティングできるようにiptablesが設定されている場合、何がeth0を介してゲートウェイに送り返されるのでしょうか？ VPN1が10.8.8.0/24について知らなかった場合。 VPNサーバーがそのネットワークを認識していない場合、VPNサーバーはインターネットトラフィックとして扱われ、ゲートウェイに送り返されます。

修正

解決策は、ネットワークについてVPNサーバーに通知することでした（これはopenvpnサーバーです）。これを行うには2つの方法があります。サーバーが1つのネットワークのみにサービスを提供している場合、それは単純な構成設定です。

server 10.8.8.0 255.255.255.0

私の場合、サーバールートをセットアップしていて、追加のネットワークについて知るためにそれが必要でした。構成は次のようになりました。

server 10.5.5.0 255.255.255.0
route 10.8.8.0 255.255.255.0

それでおしまい！ VPN1がネットワークへのルートを取得すると、FORWARDチェーンはトラフィックをルーティングできます。

より良いiptables設定

Iptablesをフラッシュした後、より良い構成は次のようになります。

# Forward established traffic so that (in the above case) VPN1 doesn't
# drop responses from the client, A.K.A. "the magic"
iptables -t filter -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -t filter -A FORWARD     -s 10.10.10.0/16 -d 10.8.8.0/24  -j ACCEPT
iptables -t nat    -A POSTROUTING -s 10.10.10.0/16 -d 10.8.8.0/24  -j MASQUERADE

# Drop everything else that wants to be forwarded
iptables -P FORWARD DROP

10.8.8.0/24からのトラフィックには明示的なルールがないことに注意してください。つまり、デフォルトでは、トラフィックは10.10.10.0/16ネットワークに到達しません-10.10.10.0/16から送信されたトラフィックに応答するトラフィックを除きます。 。 iptablesが設定されたので、クライアントにVPN構成でIPを割り当て、完全なソリューションのためにDNSに追加できます。

3
jobu1324