☰

構成で発生する状況の説明です。

tag-icon • tag-icon iptables vpn openvpn
構成で発生する状況の説明です。

この問題を解決するのに役立ちますか？ tun0インターフェイス（OpenVPNトンネル）のすべてのトラフィックをeth1インターフェイスにリダイレクトする必要があります。 eth1はこのシステムの背後にある内部ネットワークであり、特別なファイアウォールとして使用されます。

iptables -t nat -A PREROUTING -i tun0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.199.115.146

VPN のトラフィックが正しく転送されます。 iptables統計（iptables -L -v）で見ることができますが、逆方向トラフィックは通過しません。 iptablesに次のエラーが表示されます。

99689.703349 x_tables: ip_tables: tcp match: only valid for protocol 6

ファイアウォールの背後にあるコンピュータからのすべてのトラフィックは、ton0インターフェイスを介してのみリダイレクトする必要があります。私もこのルールを使います：

iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

私はそれを活性化しました。ルールなしでip_forwardルールを使用すると、ルールのiptables統計アクティビティで表示できます。-p tcp-m tcpiptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

相互作用

VPNサーバー（A）：

eth0      Link encap:Ethernet  HWaddr 00:...
          inet addr:MY_PUBLIC_IP  Bcast:MY_PUBLIC_IP.255  Mask:255.255.255.0
          inet6 addr: .../64 Scope:Global
          inet6 addr: .../64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:41909528 errors:0 dropped:0 overruns:0 frame:0
          TX packets:373639 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2150448064 (2.1 GB)  TX bytes:185713075 (185.7 MB)
          Interrupt:10

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.1.1.1  P-t-P:10.1.1.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:82014 errors:0 dropped:0 overruns:0 frame:0
          TX packets:164251 errors:0 dropped:24 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:5945388 (5.9 MB)  TX bytes:147587733 (147.5 MB)

ファイアウォールマシンで：

eth0      Link encap:Ethernet  HWaddr 08:...
          inet addr:10.0.2.15  Bcast:10.0.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:189399 errors:0 dropped:0 overruns:0 frame:0
          TX packets:103528 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:180399131 (180.3 MB)  TX bytes:14844868 (14.8 MB)


tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.1.1.2  P-t-P:10.1.1.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:153314 errors:0 dropped:0 overruns:0 frame:0
          TX packets:80986 errors:0 dropped:8 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:145341797 (145.3 MB)  TX bytes:5818996 (5.8 MB)

eth1      Link encap:Ethernet  HWaddr 08:...
          inet addr:10.199.115.1  Bcast:10.199.115.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6890 errors:0 dropped:0 overruns:0 frame:0
          TX packets:23022 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:710721 (710.7 KB)  TX bytes:43966879 (43.9 MB)

機械B：

eth0      Link encap:Ethernet  HWaddr 08:...
          inet addr:10.199.115.146  Bcast:10.199.155.255  Mask:255.255.255.0
          inet6 addr: .../64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:24185 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8044 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:29645960 (28.2 MiB)  TX bytes:842414 (822.6 KiB)

建築学:

VPN server (A) /eth0 - public IP, tun0 VPN/ <-> Firewall (F) /tun0 VPN, eth1 - internal network/ <-> Server (B) (eth0 - internal network)

ファイアウォールの背後にあるコンピュータから開始された通信が正しく機能します。助けてくれてありがとう。

ルーティングテーブル：

VPNサーバーA： - VPSサーバー。

10.1.1.2 dev tun0  proto kernel  scope link  src 10.1.1.1
MY_PUBLIC_IP.0/24 dev eth0  proto kernel  scope link  src MY_PUBLIC_IP
10.199.115.0/24 via 10.1.1.2 dev tun0
default via MY_PUBLIC_IP.1 dev eth0  metric 100

///物理サーバー

ファイアウォールF：仮想マシンVirtualBox Ubuntu - eth0はVirtualBox NATですが、tun0を使用する必要があり、eth1はBのローカルネットワークです。

0.0.0.0/1 via 10.1.1.1 dev tun0
default via 10.0.2.2 dev eth0  metric 100
10.0.2.0/24 dev eth0  proto kernel  scope link  src 10.0.2.15
10.1.1.1 dev tun0  proto kernel  scope link  src 10.1.1.2
10.199.115.0/24 dev eth1  proto kernel  scope link  src 10.199.115.1
MY_PUBLIC_IP via 10.0.2.2 dev eth0
128.0.0.0/1 via 10.1.1.1 dev tun0

eth1側のマシンB（eth0なし）は仮想マシンDebian 7です。

default via 10.199.115.1 dev eth0 proto static
10.199.115.0/24 dev eth0 proto kernel scope link src 10.199.115.146

パケットルーティングはできるだけ透明または見えてはいけません。

iptablesルール：

VPNサーバー（A）から：

テーブルNATのみ：

-P PREROUTING ACCEPT
-P POSTROUTING ACCEPT
-P OUTPUT ACCEPT
-A PREROUTING -i eth0 -p tcp -m tcp --dport 0:1192 -j DNAT --to-destination 10.1.1.2
-A PREROUTING -i eth0 -p tcp -m tcp --dport 1195:65535 -j DNAT --to-destination 10.1.1.2
-A PREROUTING -i eth0 -p udp -m udp --dport 0:1192 -j DNAT --to-destination 10.1.1.2
-A PREROUTING -i eth0 -p udp -m udp --dport 1195:65535 -j DNAT --to-destination 10.1.1.2
-A POSTROUTING -s 10.0.0.0/8 -o eth0 -j MASQUERADE

フィルタテーブル 

is empty

マンゲルテーブル 

is empty

ファイアウォール（F）から：

現在の最後の修正後

NATテーブル：

none

フィルタテーブル 

contains many specific rules for mitigation etc...

マンゲルテーブル 

is empty

マシンBで

without iptables rules

ベストアンサー1

サーバーAにはVPNを介してネットワークに接続するための推奨パスがない10.199.115.0/24ため、デフォルトのパスを使用します（たとえば、パブリックIPを介してBに接続しようとします）。

動作していることを確認してください。

ip route add 10.199.115.0/24 via 10.1.1.2

AからBへの接続はサーバーAで許可されています（ファイアウォールFにはNATルールはありません）。

これがうまくいけば、Aで接続を開始したときに自動的にパスを生成するようにopenvpnを設定できます。

構成で発生する状況の説明です。

3つのシナリオでルーティング/ NATが発生する方法は次のとおりです。

ケース 1: B ping PUBLIC_IP

  • パケットはdefault一致する唯一のパケットであるため、そのルートを使用してBを残しますPUBLIC_IP。10.199.115.1最終宛先PUBLIC_IPと送信元アドレスを含むルーティング用のIPアドレスに送信されます10.199.115.146。
  • パケットは F によってルーティングされます。多くのパスが適用されます。最も具体的な方法は、PUBLIC_IP/32マシンA（デフォルトのopenvpn接続）であるマシンからルーティングするパケットを送信することです。10.0.2.2eth0
  • マシンAはパケットを受信し、送信元アドレスで応答します10.199.115.146。私が示すルールがない場合、これはインターネットアドレスとして解釈され、応答がインターネットを介して送信されます。
  • 私が提案したルートを使用して、パケットはtun0システムFを介して返されます。マシンFは、それをeth1マシンBが応答パケットを受信した場所に再ルーティングします。ただし、10.1.1.1送信元パケットに応答して認識されないように送信元がタグ付けされています。 pingに失敗しました。

ケース2：Bping 10.1.1.1

  • 以前と同様に、パケットは B を出て F にルーティングされます。
  • 今回は、宛先アドレスが規則10.1.1.1/32と一致するため、パケットは通過します。tun0
  • ルールはパケットの送信時に適用され、tun0パケットMASQUERADEの送信元をに変更します10.1.1.2。 （私が提案したルーティングルールを使用している場合は、これを行う必要はありません。以下を参照してください。）
  • マシンAはパケットを受信して​​応答します10.1.1.2（マシンF）。これがなければMASQUERADE返送されます10.199.115.146。私が提案したルートテーブルエントリを使用すると、パッケージはまだルートに送信されるため、あまり変わりませんがエントリが10.1.1.2ない場合、ターゲットは10.199.115.146インターネット経由でルーティングされます。
  • 応答パケットはシステムＦによって受信される。マスカレーディングが実行されると、パケットは応答として認識され、宛先アドレスが再び変更されます10.199.115.146。パケットはeth1最終宛先にルーティングされます。
  • マシンBはそれを応答パケットとして認識します。 pingの成功。

ケース3：ping 10.199.115.146

  • 私が提案したルールがない場合、元のパケットはインターネットに送信され、失われます。それ以外の場合は、10.1.1.2送信元アドレス=のパスに送信されます10.1.1.1。
  • Fマシンはパケットを受信し、それを介してルーティングしますeth1。
  • Bはパケットを受信し、応答を送信します10.1.1.1。
  • 返信はを介してルーティングされますtun0。このMASQUERADEルールはソースアドレスをに変更します10.1.1.2。
  • 10.1.1.2機械Aは（元の宛先ではなく）から応答を受け取り、無関係と見なして捨てます。 ping失敗

ご覧のとおり、内部ネットワークからVPNにコンピュータを接続する方法は2つあります。

  • パブリックルーティング：両方のネットワークは互いにIPアドレスを知っており、それらを照会するための特定のルーティングテーブルエントリがあります（私が示したように）。
  • SNAT / MASQUERADE：1つのネットワークだけが別のネットワークに到達する方法を知っており、ファイアウォールはそのネットワークから送信されるパケットの送信元IPアドレスをファイアウォール自体のIP（別のネットワークに知られている）に変更します。

どちらかを使用しないでください。 SNAT / MASQUERADEが使用されている場合、プライベートネットワークのパケットは元のアドレスを送信元として使用しないため、外部ホストのルーティングテーブルは適用されません。

PUBLIC_IP10.1.1.1BからシステムAにアクセスできるかどうかを使用または選択できます。どちらも機能するようにファイアウォールを設定することが可能かもしれませんが、努力する価値はありません。

おすすめ記事