PiVPN、Wireguard、Fritzbox - ルーティングを担当する人 - ドイツの Raspberry Pi フォーラム (2024)

こんにちは、親愛なる皆さん、こんにちは。

私の Pi (4B V1.4) は、特に Wireguard を実行するようになりました。VPN(10.6.0.0/24 と想定)、フル トンネルとスプリット トンネルを使用してホーム ネットワーク (192.168.178.0/24 と想定) に問題なくアクセスできます。セットアップは次の手順で行います。これを強くお勧めします。WireGuard Raspberry Pi: 完全な VPN セットアップ手順! - ワンダーテック

ここで、ホーム ネットワークからクライアントにアクセスできるようにする試みはこれまでのところすべて失敗していることを認識しなければなりません。クライアントへの ping が失敗します。

静的ルートはフリッツ!ボックス7590 は次のデータで設定しましたが、これでは問題は解決されませんでした。

• ネットワーク: 10.6.0.0
• サブネットマスク: 255.255.255.0

• ゲートウェイ: RPi の IP

Fritzbox でのポート共有はアクティブであり、RPi でのパケット転送もアクティブです (net.ipv4.ip_forward=1/etc/sysctl.conf 内)。

それ以外の場合は、私の構成は次のとおりです。

[インターフェース]秘密鍵 =アドレス = 10.6.0.1/24PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT; iptables -t nat -A ポストルーティング -o eth0 -j マスカレードPostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -D FORWARD -o wg0 -j ACCEPT; iptables -t nat -D ポストルーティング -o eth0 -j マスカレードリッスンポート = 51820[ピア]公開鍵 =事前共有キー=許可された IP = 10.6.0.2/32[ピア]公開鍵 =事前共有キー=許可されたIP = 10.6.0.3/32

何かルートが欠けているのでしょうか？ 「はい」の場合、どれですか?

ネットワークに関する私の知識にはまだ改善の余地がたくさんあるので、ヒントをいただければ幸いです

バックマニアックからの引用

まだ行方不明かも知れません…

これは役に立つかもしれません糸。

rpi444より引用

See Also

FAQ: WireGuard を使用した VPN独自の Wireguard VPN サーバーを 5 分でインストールしますPiVPN を使用した Wireguard VPN のセットアップと管理PiVPN を使用した Wireguard VPN のセットアップと管理

これは役に立つかもしれません糸。

ありがとう、とても助かります！私の研究でそれを見逃したに違いありません。

どうやら私にはまだ理解に問題があるようです。

ホーム ネットワーク内のデバイス間の通信を有効にするために、AllowedIP を追加しました。許可された IP = 10.6.0.2/32、192.168.178.0/24そして許可された IP = 10.6.0.3/32、192.168.178.0/24

192.168.178.XXX IP からのパケットは、おそらくリストに含まれていなかったため、これまで転送されなかったのでしょう。これが私の考えです。ここで私のミスがあったに違いありません。サーバー設定でAllowedIPが拡張されるとすぐに、クライアントへのpingが失敗し続けるだけでなく、ホームネットワークからRPiに到達できなくなったためです。これはアクセスが有効な場合にのみ機能しましたVPN開催されました。

バックマニアックからの引用

ホーム ネットワーク内のデバイス間の通信を有効にするために、AllowedIP を追加しました。許可された IP = 10.6.0.2/32、192.168.178.0/24そして許可された IP = 10.6.0.3/32、192.168.178.0.24

次の許可された IP を使用して、両側 (サーバーとクライアント) でテストします。

許可された IP = 10.6.0.0/24、192.168.178.0/24

残念ながら全く同じ結果でした。

クライアントの構成ファイルには、少なくとも分割トンネル プロファイルを含む 192.168.178.0/24、10.6.0.0/24 がすでに含まれています。これは、これらが使用できる唯一のアドレスであるためです。VPN指示されるべきだ。

バックマニアックからの引用

ここで、ホーム ネットワークからクライアントにアクセスできるようにする試みはこれまでのところすべて失敗していることを認識しなければなりません。クライアントへの ping が失敗します。

ホーム ネットワークからのクライアントにはどの OS が搭載されており、共有アパートメント経由で ping できる共有クライアントにはどの OS が搭載されていますか?VPN、ホームネットワーク内のクライアントに？

PI (ホーム ネットワーク内の共有 VPN サーバー) 上の出力は何ですか:

ルート -nアルプオフsudo iptables -nvx -L -t nat

?

Win 10 20H2 (WG クライアント) 上の RPi (Raspbian Buster 5.10.17 lite) と OSX Catalina (両方ともホーム ネットワーク内) の両方から ping を試行します。

(もちろんその逆も同様ですが、それは機能します)。

ここでの出力は次のとおりです。

• ルート -n

宛先ゲートウェイの Genmask フラグ メトリック参照 Iface の使用0.0.0.0 192.168.178.1 0.0.0.0 AND 202 0 0 eth010.6.0.0 0.0.0.0 255.255.255.0 U 0 0 0 wg0192.168.178.0 0.0.0.0 255.255.255.0 U 202 0 0 eth0

• アルプオフ

? (192.168.178.44) eth0 の X:X:X:X:X:X [ether]? (192.168.178.43) eth0 の X:X:X:X:X:X [ether]? (192.168.178.23) eth0 の X:X:X:X:X:X [ether]? (192.168.178.25) eth0 上の X:X:X:X:X:X [ether]? (192.168.178.34) eth0 上の X:X:X:X:X:X [ether]? (192.168.178.35) eth0 の X:X:X:X:X:X [ether]? (192.168.178.32) eth0 の ? (192.168.178.1) eth0 上の X:X:X:X:X:X [ether]? (192.168.178.31) eth0 の X:X:X:X:X:X [ether]? (192.168.178.71) eth0 の エントリ: 10 スキップされた: 0 見つかった: 10

• sudo iptables -nvx -L -t nat

チェーン PREROUTING (ポリシー ACCEPT 1224 パケット、206450 バイト)pkts バイト ターゲット プロト オプトイン ソース 宛先チェーン INPUT (ポリシー ACCEPT 550 パケット、48474 バイト)pkts バイト ターゲット プロト オプトイン ソース 宛先チェーン ポストルーティング (ポリシー ACCEPT 124 パケット、9417 バイト)pkts バイト ターゲット プロト オプトイン ソース 宛先392 92067 すべてマスカレード -- * eth0 10.6.0.0/24 0.0.0.0/0 /* Wireguard-nat-rule */471 33093 すべてマスカレード -- * eth0 0.0.0.0/0 0.0.0.0/0チェーン出力 (ポリシー ACCEPT 595 パケット、42510 バイト)pkts バイト ターゲット プロト オプトイン ソース 宛先

バックマニアックからの引用

Win 10 20H2 (WG クライアント) 上の RPi (Raspbian Buster 5.10.17 lite) と OSX Catalina (両方ともホーム ネットワーク内) の両方から ping を試行します。

この状況はまだ理解できません。

ホーム ネットワークに (共有サーバーとして) PI があり、このホーム ネットワークには 2 つの共有クライアント (OSX と Windows) もありますか?

10.6.0.x IP アドレスで ping を実行していますか? 「はい」の場合は、PI (WG サーバー) から次の出力を投稿します。

sudowgfping -a -q -g 10.6.0.0/24

まさに、RPi は WG サーバーです。実際には PC をクライアントとしてのみ使用します。楽しみのために、別のデバイスでも問題が同じかどうかをテストしていました。そのため、macOS を含めました。

fping は 10.6.0.1 のみを吐き出します。

sudo -wg提供します:

公開鍵:秘密鍵:リスニングポート: 51820ピア:事前共有鍵：終点：許可される IP: 10.6.0.3/32最新のハンドシェイク: 59 秒前転送: 3.66 MiB 受信、24.40 MiB 送信永続的なキープアライブ: 25 秒ごとピア:事前共有鍵：終点：許可される IP: 10.6.0.2/32最新のハンドシェイク: 54 分 2 秒前転送: 受信 119.18 KiB、送信 309.07 KiB永続的なキープアライブ: 25 秒ごと

バックマニアックからの引用

fping は 10.6.0.1 のみを吐き出します。

sudo -wg提供します:

コード

ピア:事前共有鍵：終点：ピア:事前共有鍵：終点：

私の考えでは、これはクライアントの構成にのみ起因すると考えられます。私も同様のコンスタレーションを持っています (ただし、ホーム ネットワーク内のクライアントでは、Mac と Win、Linux、FreeBSD の代わりに)。例えば。：

:~# fping -a -q -g 192.168.22.0/24WG サーバーとしての 192.168.22.1 #PI192.168.22.14 #WG-クライアント 1192.168.22.99 #WG-クライアント 2

エンドポイントのピアの「sudo wg」の出力にはどの IP アドレスが表示されますか?

編集：

ところで: 私の場合は静的ルートが必要ですフリッツボックスない。 WG クライアントにソース NAT ルール (MASQUERADE) を設定しました (wgx インターフェイスの場合は iptables または pf を使用)。

Mac 上の wg インターフェイスを嗅ぎ分けて、ping がそこに到着し (icmp-echo-r​​equest)、単に戻ってこないのかどうかを確認します。

編集2:

私の意見では、「AllowedIP」については、Linux の wg-man ページと比較して、OpenBSD の wg-man ページの方がもう少し詳しく説明されています。

引用

ここで、ホーム ネットワークからクライアントにアクセスできるようにする試みはこれまでのところすべて失敗していることを認識しなければなりません。クライアントへの ping が失敗します。

引用

チェーン ポストルーティング (ポリシー ACCEPT 124 パケット、9417 バイト)

pkts バイト ターゲット プロト オプトイン ソース 宛先

392 92067 すべてマスカレード -- * eth0 10.6.0.0/24 0.0.0.0/0 /* Wireguard-nat-rule */

471 33093 すべてマスカレード -- * eth0 0.0.0.0/0 0.0.0.0/0

NATを取り外せば動作します。