この場合、サーバーはネットワーク間でパケットをルーティングしますが、ネットワーク番号が異なるふりをして、希望的観測を与えることが残っています。 リッチLinuxアーセナルには、そのような操作のためのツールがあります。NETMAPを使用したiptablesとipユーティリティです。
目的
LAN1から、LAN2にパケットを送信します。 ただし、番号が同じネットワークに送信することはできません。 最も一般的なケースでは、192.168.0.0 / 24。 そのようなパケットがLAN1に表示される場合、彼はLAN2が何であるかを知らず、LAN1でそのようなマシンを探します。 これらはデフォルトのルーティングルールです。
そのため、ルーターに送られる他のアドレスを持つパケットを送信する必要があります。
LAN1からオブザーバーを探す方法
たとえば、LAN1のユーザーには、LAN2が10.8.1.0/24と表示されます。 アドレスの交差はありません。 LAN1は幸せです。
両側でどのように見えるか
パケットは、192.168.0.100の送信者アドレスと10.8.1.200の宛先アドレスでLAN1から到着します。 10.8.1.100の送信者アドレスと192.168.0.200の宛先アドレスを持つ同じパケットは、LAN2インターフェイスからルーターから送信されます。 パケットは宛先アドレスに送信され、送信者アドレスに応答してそのアドレスとともに送信されます。 パケットはルーターに送られます。 その中で、逆変換が行われ、ユーザーLAN1はパケットを送信したアドレスから応答を受け取ります。
理論 ルーターのコアのパッケージパス：netfilter
ここでは、Linuxルーターを通過する通過トラフィックについて説明します。 パッケージの移動プロセスを完全に理解するには、netfilterチェーンに沿ったウィキペディアからの通過のスキームを確認することをお勧めします。
[ソース|宛先] [192.168.0.100 | 10.8.1.200]のパケットは、ルーターのネットワークインターフェイスに到達し、その最初のチェーンはPREROUTINGになります。
事前準備
チェーンを通り抜けると、彼はテーブルPREROUTINGマングルに入ります。 ここで、iptablesを介して、送信元のインターフェイスと送信元アドレスを決定します。 これが患者である場合、MARKアクションでマークします。
次に、パケット[192.168.0.100 | 10.8.1.200 |（マーク付き）]がnatテーブルに到達します。 このテーブルはアドレス変換用です。 10.8.1.200には実際のアドレスがないため、次のルーティングステージで、パケットはドロップされるか、未知の方向に進みます。 したがって、私たちは彼を実際に行くべき宛先アドレス[192.168.0.100 | 192.168.0.200 |（マーク）]に置き換えます。 これは、ネットワーク番号をマスクで置き換えるNETMAPアクションによって実行されます。
ルーティング
パッケージパッケージは、次に進むべき場所を決定する段階になります。 マークされているため、このケース用に作成した特別なルーティングテーブルに送信できます。 そこで、パッケージはローカルコンピューター用ではなく、LAN2に移動する必要があるという決定が下されます。
パッケージはFORWARDINGチェーンを正常に渡します。 ルーティングステージに戻ります。 フォワーディングで彼に何も起こらなかったとしても、理論的にはそうではないはずです。 彼は同じように行きます。 次に、ポストルーティングに入ります。
ポストルーティング
natテーブルに到達する変更はありません。 送信元アドレスを変更する必要があります。 結局、パケット[192.168.0.100 | 192.168.0.200]への応答は、ルーターではなくローカルネットワークに送信されます。 彼がルーターに戻るように、送信元アドレスを存在しない[10.8.1.100 | 192.168.0.200]に変更します。 再びNETMAP。 その後、パケットはLAN2に送られます。
応答パッケージを使用して、元のソースに到達するように逆の手順を実行します。
実装
iptables -t mangle -A PREROUTING -i tun0 -d 10.8.1.0/24 -j MARK --set-mark 8
netfilterでさらに識別するために、存在しないネットワーク上の着信パケットにマークを付けます。 ラベルなしで、ソースアドレス、入力インターフェイス、および宛先アドレスを基準として使用できますが、個別のルーティングテーブルを使用した複雑なルーティングの場合は、ラベルごとにパケットを送信する場所を決定するのが最も簡単です。
iptables -t nat -A PREROUTING -m mark --mark 8 -j NETMAP --to 192.168.0.0/24
ラベルによってパケットを認識し、PRERROUTINGテーブルのNETMAPアクションがネットワーク番号を置き換えます。
iptables -t nat -A POSTROUTING -m mark --mark 8 -j NETMAP --to 10.8.2.0/24
POSTROUTINGでは、NETMAPが送信元アドレスを置き換えます。
その後、10.8.1.0 / 24サブネットへのすべての呼び出しは、10.8.2.0 / 24サブネットからの呼び出しと同様に、LAN2内で検索されます。
ルーティング
パケットをラベルでルーティングするには、独自のルーティングテーブルを作成する必要があります/ etc / iproute2 / rt_tablesを編集し、一意の番号と新しいテーブルの名前を追加します。
256 netmap
次に、パケットをこのテーブルにルーティングするルールを追加する必要があります。
ip ru add fwmark 8 lookup netmap
これで、マークされたパケットはネットマップテーブルへのルーティングに使用されます。
最後のステップは、netmapテーブルでルートを定義することです。
ip route add default dev eth1 table netmap
または、特別な場合には、ルーターからネットワークへのトラフィックが通過する場合、別のゲートウェイを指定できます。 精神の何か：
ip route add default via 192.168.1.254 dev eth1 table netmap
喜ぶには時期尚早で、LAN2 [192.168.0.100 | 10.8.2.200]から回答を受け取ります。
すべて同じように実行する必要がありますが、元に戻すだけです。 残念ながら、netfilter自体はそうではありません。 すべてのアクションについては既に説明しましたが、アドレスを一方向および逆方向に変換するための一連のコマンドのみを提供します。 （この場合、最初のルーティングテーブルは必要ありませんが、他の状況では必要になる場合があります。）
ip rule add fwmark 8 lookup netmap ip route add 192.168.0.0/24 dev eth1 table netmap iptables -t mangle -A PREROUTING -i tun0 -d 10.8.1.0/24 -j MARK --set-mark 8 iptables -t nat -A PREROUTING -m mark --mark 8 -j NETMAP --to 192.168.0.0/24 iptables -t nat -A POSTROUTING -m mark --mark 8 -j NETMAP --to 10.8.2.0/24 # ip rule add fwmark 9 lookup netmap2 ip route add 192.168.0.0/24 dev tun0 table netmap2 iptables -t mangle -A PREROUTING -i eth1 -d 10.8.2.0/24 -j MARK --set-mark 9 iptables -t nat -A PREROUTING -m mark --mark 9 -j NETMAP --to 192.168.0.0/24 iptables -t nat -A POSTROUTING -m mark --mark 9 -j NETMAP --to 10.8.1.0/24
結果
tcpdumpの書き込み内容は次のとおりです（最初の例はvnc、2番目はping）。
tcpdump -i any port 5900
12:46:46.358969 IP 192.168.0.100.41930 > 10.8.1.200.5900: Flags [P.], seq 647:657, ack 261127, win 1213, options [nop,nop,TS val 460624 ecr 171318], length 10
12:46:46.358978 IP 10.8.2.100.41930 > 192.168.0.200.5900: Flags [P.], seq 647:657, ack 261127, win 1213, options [nop,nop,TS val 460624 ecr 171318], length 10
12:46:46.505847 IP 192.168.0.200.5900 > 10.8.2.100.41930: Flags [.], ack 657, win 64879, options [nop,nop,TS val 171320 ecr 460624], length 0
12:46:46.505861 IP 10.8.1.200.5900 > 192.168.0.100.41930: Flags [.], ack 657, win 64879, options [nop,nop,TS val 171320 ecr 460624], length 0
tcpdump -i any icmp
12:47:46.363905 IP 192.168.0.100 > 10.8.1.200: ICMP echo request, id 2111, seq 1, length 64
12:47:46.363922 IP 10.8.2.100 > 192.168.0.200: ICMP echo request, id 2111, seq 1, length 64
12:47:46.364049 IP 192.168.0.200 > 10.8.2.100: ICMP echo reply, id 2111, seq 1, length 64
12:47:46.364054 IP 10.8.1.200 > 192.168.0.100: ICMP echo reply, id 2111, seq 1, length 64
Tcpdumpは、1つのインターフェイスへの入力と、他のインターフェイスへの出力、およびその逆のアドレス変換がどのように発生するかを完全に示しています。
Sambaやそれに対応するWindowsなどの他のサービスも正常に機能します。
ご注意
ネットワーク間の接続がOpenVPNトンネルを介して確立される場合、クライアント側からの正しいルーティングのために、トンネルを通る追加のルートをサーバー構成に追加する必要があります。
push "route 10.8.1.0 255.255.255.0"
警告！
構成をデバッグするときは、ゲートウェイがあるサーバーに接続しないでください。 LAN2で背後のマシンと接続します。
そして、ここに理由があります。 ルールは、パケットがゲートウェイを通過するように設計されています。
PREROUTING->ルーティング->フォワード->ルーティング-> POSTROUTING
パケットが（サーバーへの）10.8.2.1にアドレス指定されている場合、ルーティングの結果としてINPUTチェーンに送られ、送信元アドレスはPOSTROUTINGに変換されません。
PREROUTING-> Routing-> INPUT-> Application
したがって、送信元アドレスは変更されず、回答は10.8.2.xyではなく192.168.0.xyに送信されます。この範囲のデフォルトルート、つまりLAN1ではなくLAN2に送信されます。