web-dev-qa-db-ja.com

7つ(7つ!)のサブネット間のルーティング。そのうちの2つには動的に割り当てられたIPがあります。

非常に複雑なルーティングスキームでRaspberryPi(Raspbian OS)を使用しています。これは、サブネットの数が5になるまで管理できました:)

現在、ifconfigで示されているように、次のインターフェイスがあります。

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
    inet 192.168.1.251  netmask 255.255.255.0  broadcast 192.168.1.255
eth0:1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
    inet 192.168.44.1  netmask 255.255.255.0  broadcast 192.168.44.255
    ether b8:27:eb:b9:ca:47  txqueuelen 1000  (Ethernet)
eth0:2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
    inet 192.168.45.1  netmask 255.255.255.0  broadcast 192.168.45.255
    ether b8:27:eb:b9:ca:47  txqueuelen 1000  (Ethernet)
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
    inet 10.35.0.74  netmask 255.255.255.255  destination 10.35.0.73
tun1: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
    inet 10.35.0.18  netmask 255.255.255.255  destination 10.35.0.17
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
    inet 192.168.42.1  netmask 255.255.255.0  broadcast 192.168.42.255
wlan1: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
    inet 192.168.46.1  netmask 255.255.255.0  broadcast 192.168.46.255

eth外の世界へのインターネットアクセスを提供します(固定IP)

tunおよびtun1は異なるVPNサーバーへのVPNインターフェースであり、それぞれのサーバーから動的に割り当てられたIPを取得します(thisが主要な問題のようです)

wlanおよびwlan1はwifiネットワーク(アクセスポイントとして機能します!)であり、トラフィックのalltun経由でルーティングする必要があります。およびtun1、それぞれ

eth0:1およびeth0:2は、ハードウェアをeth(RaspberryPiでは1つのイーサネットポートのみ)と共有するインターフェイスであり、同じものを提供する必要がありますwlanおよびwlan1としての機能ですが、有線クライアントに対してです。

DHCPサーバーはRaspberryPiで実行され、wlanおよびwlan1がそれぞれのクラスのアドレスをワイヤレスクライアントに確実に提供します。もちろん、共有ワイヤにはDHCPは提供されていません-各デバイスを構成しますclientデバイスは、必要なVPN(またはVPNなし)に応じて、192.168.44.1または192.168.45.1のいずれかを介してトラフィックをルーティングしますそれらを接続します。

明確でない場合は、次のすべてのネットワークを処理する必要があります。

eth0、192.168.1.1/24(アップストリームインターネット)

eth0:1、192.168.44.1/24(tun0を経由するダウンストリーム有線クライアント)

eth0:2、192.168.45.1/24(tun1を経由するダウンストリーム有線クライアント)

tun0、10.35.0.74/32(最初のアップストリームVPN)

tun1、10.35.0.18/32(2番目のアップストリームVPN)

wlan0、192.168.42.1/24(tun0を通過するダウンストリームワイヤレスクライアント)

wlan0、192.168.46.1/24(tun1を通過するダウンストリームワイヤレスクライアント)

これはcurrent VPNサーバーによって提供される太字のIPを使用した構成であることに注意してください。

問題は太字で示されます-VPNサーバーによって提供されるIPは、再接続のたびに動的に変更されます(変更されない場合でも可能です)。私にとって、すべてのアドレスが固定されていれば、そのような多方向ルーティングでさえ理解するのは非常に簡単です。 1つのVPN、1つのワイヤレス、およびeth0:1も簡単です。これは、VPNサーバーが接続時にデフォルトルートをプッシュで、残りが簡単だからです。いずれにせよ、1つのVPNにルーティングされる1つのwifiに対してNATを設定することを知っています

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

ここに示すように:

https://pimylifeup.com/raspberry-pi-vpn-access-point/

ただし、2つのVPN接続サーバーがルーティングを混乱させないようにする必要があります。もちろん、次の方法でそれを行うことができます。

pull-filter ignore redirect-gateway

vPNクライアント構成ファイル内。

これをした後、私は迷子になります。トラフィックは明らかにtunまたはtun1にルーティングされません。 VPNサーバーと私との違いは、サーバーが正確なルートをプッシュできることです正確なIPを知っています VPNインターフェース(サーバーがそれを決定します)、そして私は知りません!

iptablesを使用して、純粋にネットワークデバイス名に基づいてルーティングを設定しようとしましたが、これまでのところ失敗しています。このルーティングを設定するために私が取ることができる正しいルート(原文のまま)を誰かが提案できますか?

3
xmp125a

VPNサーバーと私との違いは、サーバーがVPNインターフェイスの正確なIPを知っているので(サーバーがそれを決定する)、正確なルートをプッシュできることです。

あなたはする必要はありません。 VPNクライアントによって作成された「tun」インターフェースは「レイヤー3」インターフェースであり、ルートゲートウェイアドレスをまったく使用しません。デバイス全体にトラフィックをルーティングするだけで同じ結果が得られます。例えば:

ip route add <dstA>/24 dev tun0
ip route add <dstB>/24 dev tun1

または、クライアントのIPアドレスに基づいて作成する場合:

ip route add 0.0.0.0/0 dev tun0 table 10
ip rule add pref 100 from 192.168.44.0/24 lookup 10

(イーサネット、Wi-Fi、または「タップ」などのレイヤー2インターフェイスでは、同じインターフェイスが、パケットの送信先のMACアドレスに基づいて複数のローカルデバイスに接続します。「ゲートウェイ」または「経由」アドレスルートで指定することは、MACアドレスに解決されるという1つの目的でのみ使用されます。

ただし、「tun」や「ppp」などのレイヤ3インターフェイスには、MACアドレス指定がまったくありません。両端が2つしかないため、「オンリンク」ホストと「遠隔」ホストの区別はありません。したがって、送信するものに関係なく、パケットは常に同じ宛先(この場合はVPNサーバー)に到達するため、ルートにゲートウェイを設定する必要はありません。)

最後に、didデフォルトゲートウェイアドレスを知る必要がある場合は、VPNクライアントに通知させることができます。 OpenVPNは、ネットワーク構成に関するすべての情報を受け取る--upスクリプトをサポートしています。

eth0:1およびeth0:2は、ハードウェアをeth0と共有するインターフェースです。

それらは、ifconfigが歴史的な理由であなたに言っているという嘘です。これらの「エイリアス」インターフェースは、実際にはLinux上に長い間存在していませんでした。現在、OSはそれらを単一のeth0インターフェイスとして管理し、複数のアドレスが割り当てられているだけです。

別の注意点として、前のセクションと同じ理由で、ゲートウェイとしてeth0:1とeth0:2を使用しているクライアント間に実際の違いはありません。両方のIPアドレスはまったく同じMACアドレスに解決されます。パケットは、クライアント自身の送信元IPアドレスによってのみ区別できます。

6
user1686