Raspberry PiがOpenVPNクライアントを実行してVPNプロバイダーとWireguardサーバーに接続しているので、外部から自宅のLANに接続できます。ワイヤーガード経由で自宅に接続し、Openvpn接続経由ですべてのトラフィックを送信したい。
これは私のifconfig出力です
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.5 netmask 255.255.255.0 broadcast 192.168.1.255
wg0: flags=209<UP,POINTOPOINT,RUNNING,NOARP> mtu 1420
inet 172.1.1.1 netmask 255.255.255.0 destination 172.1.1.1
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet 10.8.8.17 netmask 255.255.255.0 destination 10.8.8.17
eth0-インターネットへのゲートウェイです(私のホームルーターに接続されています)
OpenVPNクライアントを実行せずにwireguardサーバーに接続すると、内部LAN(192.168.1.X)に到達でき、Raspberry Pi(eth0)を介してインターネットにリクエストを転送することもできます。 OpenVPNクライアント(tun0 up)を有効にすると、内部LANに到達できず、インターネットにも到達できません。
私がやりたいのは、wireguardを介して自宅に接続し、openvpn接続(tun0)を介してすべてのトラフィックをトンネリングすることです。
これは「route-n」からの私の出力です:
OpenVPNが開始する前(wireguardは正常に機能します):
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.1 0.0.0.0 UG 202 0 0 eth0
172.1.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wg0
192.168.1.0 0.0.0.0 255.255.255.0 U 202 0 0 eth0
OpenVPN tun0が開始した後(wireguard接続がインターネットおよびLANクライアントに到達しない):
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.8.8.1 128.0.0.0 UG 0 0 0 tun0
0.0.0.0 192.168.1.1 0.0.0.0 UG 202 0 0 eth0
10.8.8.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
95.142.172.143 192.168.1.1 255.255.255.255 UGH 0 0 0 eth0
128.0.0.0 10.8.8.1 128.0.0.0 UG 0 0 0 tun0
172.1.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wg0
192.168.1.0 0.0.0.0 255.255.255.0 U 202 0 0 eth0
私のファイアウォールルール:
-A FORWARD -i wg0 -j ACCEPT
-A POSTROUTING -o eth0 -j MASQUERADE
ファイアウォールルールが欠落している、またはこれを機能させるために追加する必要のあるルートはありますか?何が必要ですか?
ありがとう!
新しいルーティングテーブルを作成します。
ip route add default via 192.168.1.5 dev eth0 table 7
ip rule add fwmark 0x55 priority 1000 table 7
ip route flush cache
ここで、192.168.1.5は外部インターフェース(eth0)のIPです。次に、これをwg0.confに追加します。
FwMark = 0x55
これで、OpenVPNトンネルが開いている場合でも、WireGuardを介してホームサーバーに接続できるようになります。
OpenVPNトンネルを開始すると、新しいルートがメインルーティングテーブルに設定されます。このルートは次のようになります。0.0.0.0/1 via 10.8.8.1 dev tun0
は、すべてのインターネットトラフィックをトンネル経由で送信する必要があることを意味します。
これは素晴らしいことですが、保護されていないインターフェイスを介してルーティングマシンと通信する場合は常に、マシンの応答もトンネルに送信されます。そのため、ポート443をサーバーに転送した場合でも、https経由でサーバーにアクセスできなくなります。答えは単にトンネルに送信され、失われます。
ip route show table 7
と0x55ルールを介して表示できる2番目のルーティングテーブルを設定する際、基本的に、マークされたすべてのパケットを通常の保護されていないeth0インターフェイス経由でルーティングするようにマシンに指示しました。残りはまだトンネルに送られます。
私が実際に解決策を見つけたのは、私がWireGuardについて聞いたこともないときでした。当時、OpenVPN経由でホームネットワークに接続したかったのですが、サーバーがトンネルを通過したときに接続できませんでした。ただし、私自身のOpenVPNサーバーはポート993でリッスンしていたため、そのポートを通過するすべてのパケットに「0x55」のマークを付けました。
Sudo iptables -t mangle -A OUTPUT -p tcp -m multiport --sport 993 -j MARK --set-mark 0x55
これにより、VPN接続サーバーへのVPN接続が可能になりました。
私のVPNプロバイダーは、SPAMの問題があったため、VPNを介したメールの送信を許可していません。このルールは、トンネルを通過せずに接続を私のメールアカウントにルーティングします。
iptables -t mangle -A PREROUTING -p tcp --dport 25 -j MARK --set-mark 0x55
「保護されていない」完全なデバイスが必要な場合があります。スウェーデン語のサーバーを使用していて、タブレットにスウェーデン語のYouTube広告を表示したくない場合は、次のようにします。
iptables -t mangle -A PREROUTING -m mac --mac-source 4c:h7:9f:0l:17:k1 -j MARK --set-mark 0x55
もちろん、タブレットのMACアドレスを使用する必要があります。
私はまったく同じ設定(openVPN-Server <-> openVPN-Client/Wireguard-Server(MiddleMan)<-> Wireguard-Client)を持っていますが、半分しか解決できませんでした。
MiddleMan WireGuard構成のMiddleManに以下のiptablesルールを追加すると、次のようになります。
PreUp = iptables -t nat -A POSTROUTING -s 10.200.200.0/24 -o tun0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -s 10.200.200.0/24 -o tun0 -j MASQUERADE
ここで、10.200.200.0はwg0ネットワーク、tun0はopenvpnインターフェースであり、MiddleManのopenVPN構成に次のルールを追加します。
route-nopull
route 192.168.178.0 255.255.255.0
192.168.178.0はopenVPNサーバーの内部ネットワークですが、WireGuardクライアント(携帯電話)から192.168.178.0ネットワークにpingしてアクセスできます。
しかし、私はまだインターネットをopenVPNサーバーからWireguardクライアントに転送する方法を知りません。 openVPNサーバーからMiddleManへのすべてのルートをプルすると、MiddleManのデフォルトゲートウェイが置き換えられ、WireGuardクライアントからMiddleManへのアクセスがなくなります。 MiddleManのデフォルトゲートウェイを置き換えることなく、openVPNサーバーからWireGuardクライアントにインターネットトラフィックを転送する方法について、正しいルーティングを知る必要があります。
「Wireguard経由で自宅に接続し、Openvpn接続経由ですべてのトラフィックを送信したい」と言っていましたが、これは意味がありません。私はそれを「ワイヤーガードを介して自宅に接続し、Openvpn接続を介して他のすべてのトラフィックを送信したい」と解釈しています。
OpenVPNサーバーを起動すると、デフォルトルートが192.168.1.1から10.8.8.1に変更され、tun0を介してルーティングされます。 tun0のピアアドレスは95.142.172.143のようで、独自の/ 32ルートが定義されているため、そのトラフィックは常にeth0を介してインターネットに直接送信されます。その静的ルートは、トンネルエンドポイントをデフォルトのルーティングから除外します。これがないと、トンネルは機能しません。
これは、OpenVPNクライアントがすべてのトラフィックをOpenVPNトンネルのリモート側にルーティングするように構成されていることを示しています。これは典型的なOpenVPN構成であり、ローカルネットワークを信頼せず、すべてのトラフィックを安全に暗号化してOpenVPNサーバー経由でルーティングする場合に使用されます。
OpenVPNサーバーを起動すると、Wireguardサーバーのすべてのトラフィックは、OpenVPNトンネルを介してそのデフォルトルートによって再ルーティングされ、トンネルの反対側にあるものに送られ、そこでドロップされる可能性があります。
OpenVPNがサーバーに/ 32ルートを追加した方法(95.142.172.143)と同様に、ワイヤーガードサーバーへの静的ルートを指定する必要があると思います。たとえば、Wireguardサーバーが100.100.100.10の場合、そのIPがeth0を経由するように静的ルートを追加します。上記の95.142.172.143のルーティングテーブルにある出力に似ているため、正しく処理されたかどうかを確認できます。コマンドラインでテストするには、OpenVPNサーバーを起動した後、次のことを試してください。
# route add -Host IP-OF-REMOTE-WIREGUARD-SERVER gw DEFAULT-GATEWAY-IP
ここで、「DEFAULT-GATEWAY-IP」はISPルーターのIPアドレスであり、上記の例では192.168.1.1のようになります。次に「netstat-rn」を実行すると、質問の「netstat」出力の95.142.172.143ルートと同じように、「UGH」フラグが付いた新しいルートが表示されます。
要約すると、トンネルは生のインターネット接続を経由する必要があります。 OpenVPNトンネル内にWireguardトンネルを詰め込もうとしているため、セットアップが壊れています。