私はArch Linuxを実行しているSBCをVPNサーバーとして使用し、ISP NATで処理せずにグローバルにアクセスできるIPアドレスを持つ唯一のデバイスであるため、3つの異なるネットワークを接続します。 Wireguard VPN 10.11.12.0/24に接続されている192.168.0.0/24、192.168.2.0/24、192.168.10.0/24.各 192.168.. ネットワークは、192.168..10 LAN アドレスを使用して VPN の単一 VPN ゲートウェイ (実際に IP 転送が「オン」に設定されたピア、1 つは Windows 10 Home を実行し、もう 2 つは Linux を実行します. ）を介して接続されます。 10.11.12.2-4 VPNアドレスと対応する各WAN / LANルーター（192.168..1）は、10.11.12.0/24アドレスをローカルVPN「ゲートウェイ」ピア（192.168..）への静的ルートにルーティングするように設定されています。 10)パス。サーバーのVPNアドレスは10.11.12.1です。ローカルIPを使用してすべてのネットワーク上のすべてのデバイスにシームレスに接続できますが、外部ネットワーク上のほとんどの時間パケットは、パブリックWebインターフェイス（プリンタ、ローカルWebサーバーなど）を持つデバイスを除くすべてのデバイスから破棄されます。
「兄弟」ネットワーク内のパケットが外部パケットとしてドロップされないように、各VPNゲートウェイデバイスにNATを設定する必要があることを理解してください。どうすれば正しい方法でこれを行うことができますか？
修正する:説明のために画像が追加されました。オレンジ色のオブジェクトは、VPN通信、青いオブジェクト（LANまたはWAN通信）を視覚化します。
私は192.168.0.20システムにあり、192.168.10.20デバイス（VPN経由で「兄弟」ネットワークデバイス）にアクセスしようとしているとします。トラフィックは次のとおりです。192.168.0.20 -> 192.168.0.10/10.11.12.2（LAN VPNゲートウェイ） - > 10.11.12.1（VPNサーバー） - > 192.168.10.10 / 10.11.12.4 .10.20（目的地）。問題は、パケットの送信元IPが依然として宛先ネットワークの外にあるため、ピアネットワークの多くのサービス（リモートアクセスが制限されているルータWebUI、システムのSSHなど）がこれらのパケットを破棄することです。
ベストアンサー1
方法：パケットに従ってください
OPによって提供された接続例を使用してパケットのパスを追跡し、そのパケットが正しい宛先に移動し続けるために必要な構成変更を追加することによって実行する必要がある作業について説明します。ルーティングとWireGuardの設定に対するこれらの変更は、3つのLANのそれぞれから他の2つのLANと中央VPNサーバーへの到着を考慮して、同じように複数回複製する必要があります（合計2つのリモートLAN x 3個のLAN = 6）。接続された3つのLANで3回
特に明記しない限り、OP（VPN）によって完全に制御されるネットワークではNATを使用する必要はありません。これは接続を妨げる可能性があります。
すべてのステップで、パケットがネクストホップに達することを確認してください。
原産地とは
192.168.0.20 のシステムが VPN 経由で 192.168.10.20 にアクセスしようとします。
- 192.168.0.10でルートを設定し、このゲートウェイを介してパケットを送信します。
- またはパスがないので、192.168.0.1に送信するか、
- 192.168.0.10から192.168.10.20までのパスを持ち、192.168.0.20にICMPリダイレクトを送信して、宛先に対して正しいゲートウェイを使用してキャッシュするように指示し、受信した最初のパケットを転送し続けます。
- または、パケットはISPにルーティングされ、近いうちにインターネットのどこかで破棄または失われます。何も変わらないとこうなる。
OPが書いたように、これを実行する10.11.12.0/24用のルーターに定義されているスタティックルートがすでに追加されています。 OPはルータにスタティックルートを再追加でき、追加する必要があります。
192.168.0.10 をゲートウェイとして使用して、ルータの 192.168.10.0/24 にルートを追加します。
Linuxコマンドは次のとおりです。
ip route add 192.168.10.0/24 via 192.168.0.10 dev eth0オプションですが、可能であれば、LAN上のすべてのシステムに同じパスを追加することをお勧めします（最適化されていないICMPリダイレクトを防ぐため）。
- 各システムで手動で
- または、ルータのDHCPを設定してDHCP オプション 121+（非標準ですがMicrosoftです...）DHCPオプション249。この機能を提供するには、通常の既製のホームルーターよりも優れている必要があります。
これで、192.168.0.10にルートを追加してパケットを中央VPNサーバーにルーティングできるようになりました。
ip route add 192.168.10.0/24 dev wg
via 10.11.12.1レイヤ3デバイスでは役に立ちません。しかし、とにかくWireGuardにはピア選択を強制する独自の方法もあります。）：成功するには、AllowedIPs関連（および単一）ピアのパラメータを一般的に次のように変更する必要があります。
AllowedIPs = 10.11.12.0/24
到着する：
AllowedIPs = 10.11.12.0/24, 192.168.10.0/24
またはただ一つだけだから一つWireGuardピアインターフェイスでは、wgこれは宛先（ピアに送信）または送信元（ピアから受信）に関係なく、トラフィックが常にそのピアに関連付けられていることを意味します。
AllowedIPs = 0.0.0.0/0
これは、後で追加の変更なしに関連していない3番目のLAN（192.168.2.0/24）でも機能します。
中央VPNサーバー（SBC Arch Linux）
パケットは中央VPNサーバーのwgインターフェイスに到着します（より正確には、最初にWireGuardがトンネリングプロトコルを受信するUDPポートのUDPパケットで、次に表示される機会がありますwg）。
中央VPNサーバーは、AllowedIPs関連するピアがそれを介して到達する送信元IPアドレスに関連付けるようにWireGuard設定、特にパラメータを変更する必要があります。
通常、ピアエントリを次に置き換えます。
AllowedIPs = 10.11.12.2
そして：
AllowedIPs = 10.11.12.2, 192.168.0.0/24
ルートを変更しない場合、パケットはデフォルトルートを使用してインターネットに追加ルーティングされます。rp_filter=1同様の理由で設定されます）。それでもCentral VPN Serverのインターフェイスを介して192.168.10.0/24へのパスを追加しますwg。
ip route add 192.168.10.0/24 dev wg
また、前述のようにAllowedIPs正しいWireGuardターゲットピアを決定するためにも使用されます。また、関連する送信ピアのエントリを置き換えます。
AllowedIPs = 10.11.12.4
到着する：
AllowedIPs = 10.11.12.4, 192.168.10.0/24
これでパケットが宛先 LAN にルーティングされます。
宛先LAN
宛先 LAN の VPN ゲートウェイ 10.11.12.4 でパケットが受信されるが、wgWireGuard 設定が変更されない場合、パケットは破棄されます。ノードは以前のように単一のピアを持つWireGuardノードなので、単に次のように言うのは安全です。
AllowedIPs = 0.0.0.0/0
パケットは、eth0からパケットを受信する最終ノード192.168.10.20にルーティングされます。たとえば、ICMPエコー要求の場合、ノードはICMPエコー応答で応答します...そしてまったく同じ説明が反転値で繰り返されます。
アドレスが192.168.10.20のシステムがVPNを介して192.168.0.20にアクセスしようとした場合：
- 192.168.10.10 経由のパスを持ち、このゲートウェイ経由でパケットを送信します。
- またはパスがないので、192.168.10.1に送信するか、
- 192.168.10.10 を経由して 192.168.0.20 にパスを指定し、192.168.10.20 に ICMP リダイレクトを送信し、その宛先に正しいゲートウェイを使用してキャッシュするように指示し、受信した最初のパケットを転送し続けます。
- または、パケットはISPにルーティングされ、近いうちにインターネットのどこかで破棄または失われます。何も変わらないとこうなる。
[...]
前の2つの部分のように、必要に応じて体系的に設定を変更して、192.168.0.0/24と192.168.10.0/24の間に接続を確立しました。NATは必要ありません。
最後のLAN
LANがLAN0、LAN2、およびLAN10と呼ばれる場合、LAN0からLAN2へ、LAN10からLAN2へのパケットの追跡および後処理を繰り返すと、関連するすべてのシステム（少なくとも4つのVPNサーバーと3つのルーター）ですべての構成が完了します。 ）。
ノート
3つのLAN VPN WireGuardサーバーはすべて十分な
PersistentKeepaliveオプションが必要です。（ISP）NATによる。これにより、彼らはいつも受け取る輸送。これがなければ、中央VPNサーバーへのトンネルは、次の場合にのみ実際に確立されます。送るトラフィックがなく、ルータまたはISPのルータがUDPフローを忘れた場合、パケットは消えます。宛先 LAN 自体が独自のトンネルを確立していないため、これらのパケットは宛先 LAN に到達できない可能性があります。一般的に提案されているように25以上で
man wgあり、いくつかの検証テストの後はそれ以上です。PersistentKeepalive = 25中央 VPN サーバーには必要ありません。
単純化する
各サイトで2つの192.168.x.0/24パスの代わりに単一の追加パス192.168.0.0/16を使用するとうまく機能します。 LANの/ 24はまだより一般的な/ 16パスよりも優先されます。
中央VPNサーバーの場合も同様です。単一の192.168.0.0/16パスは、3つの/ 24パスを置き換えることで、インターフェイスを介してそのパスをルーティングできます
wg。もちろん、それ自体はAllowedIPs単純化することはできず、各ピアに関する正確な情報を維持する必要があります。ICMPはノードのローカルファイアウォールによって削除されてはいけません。
この場合、エンドポイントがその設定またはDHCPを介して追加のルートを受信しない場合は、正しいルーティングのためにICMPリダイレクトが必要です。
ICMP 必須タイムアウト。パスMTUの検索これは、VPNがMTUを1420に減らしてTCP MSSを減らすためです。そうしないと、TCP接続が中断される可能性があります。
mtu 1420PMTUDおよび関連ICMPは、以前に示されたさまざまなパスに追加されたように、適切な場所（WireGuardサーバーには必要ありませんが、そこにも設定できるエンドポイントとルーター）から1420 MTUのパスを指定することで削除できます。考慮する価値がなく、すべてのケースに対処するわけではなく（ISPがWGの1420 MTUをさらに制限する独自のVPNを持っている場合はどうなりますか？）、DHCPのクラスレスルーティングオプション121はそのようなMTU情報を提供しないようです。
ルーターに付属のファイアウォール（ある場合）は、あまりにも情熱的ではありません。
一部のパケットは、ICMPリダイレクトが開始される前に非対称ルーティングに従い、その後関連キャッシュが期限切れになり、ルータが単一方向のトラフィック部分のみを表示できるようにします。これは、ステートフルファイアウォールによってドロップされる可能性があります（これは可能です）TCPはファイアウォールの規則と設定によって異なります。
net.netfilter.nf_conntrack_tcp_be_liberalまたはnet.netfilter.nf_conntrack_tcp_loose）。このシナリオでは、将来の IP ネットワークの追加が既存のネットワークと競合しないと仮定します。
将来、このような衝突が発生した場合、NATは避けられないでしょう。 1:1 NATを使用する（例：Linuxiptables'
NETMAP）通常、競合するLANは依然として各リモートLANのノードへの別々のアクセスを許可します。詳細については、独自のQ&Aが必要です。