☰

Ubuntuを再起動した後、Wireguardクライアントはネットワーク上の他のホストに接続できなくなりました

tag-icon • tag-icon networking wireguard
Ubuntuを再起動した後、Wireguardクライアントはネットワーク上の他のホストに接続できなくなりました

私は在宅勤務者です。私はWireGuard VPNを約16ヶ月間よく使用してきました。仮想マシン内のUbuntu Serverのインストールで実行されます。ハイパーバイザーはTrueNAS COREで実行されます。

WireGuardを初めて設定した後、クライアントがVPN経由でパブリックインターネットに接続できないという問題がありました。ただし、VPNを設定する主な目的は、サーバーをリモートで管理し、ネットワーク上のデバイスにアクセスすることだけであるため、これは大きな問題ではありません。AllowedIPsクライアント設定の設定を使用して、192.168.10.0/24VPN経由でマイサブネットにのみトラフィックをルーティングし、パブリックインターネットへのトラフィックはWireGuardには影響しません。

最近、Ubuntu仮想マシンを再起動しました。オンラインに戻ったときにWireGuard VPNに接続でき、VPNを介してUbuntu VM（192.168.10.240）で実行されているすべてのサービスに接続できました。ただし、ネットワークの他のデバイスには接続できません。

Ubuntu VMを使用していますが、curlまだ他のデバイス（TrueNAS Coreなど）を表示できます。 SSHトンネリングを使用してこれらの他のデバイスにアクセスすることもできます。ただし、通常どおりWireGuardを介してアクセスすることはできません。

最後に、Ubuntu VMを再起動した後に私が知っている唯一の変更は、DockerにPterodactyl Wingsをインストールしたことです。これにより、Dockerブリッジインターフェイスが追加されます。 （サブネット172.19.0.0/16、ゲートウェイ172.19.0.1）しかし、私が知っている限り、これがWireGuardのネットワークと競合する理由はありません。

私はこの問題をどこから始めるべきかわかりません。皆さんのアドバイスを聞きたいです。

編集：以下に示すように、IPテーブルがMASQUERADEを正しく処理していることを確認するためにPostUp / PostDownコマンドを使用しました。私のWireGuardサブネット（10.8.0.1/24）はネットワークの他のサブネットと競合しません。複数のピアを構成し、各ピアには/32このサブネットに固有のピアがあります。私のクライアントのAllowedIPはトラフィックを192.168.10.0/24。

私のクライアントが接続したら、10.8.0.2サーバーとクライアントから正常にpingを送信することもできます。別のクライアントから1つのクライアントをpingすることもできます。

192.168.10.240に接続できるため、これはおそらくWireGuardサーバー10.8.0.0/24がからのパスを提供することを意味します192.168.10.0/24。トラフィックが物理的にそのホストを離れなければならないときに問題が発生しているようです。もしそうなら、問題は私のUSGルーターにあるかもしれません（しかしVMを再起動したときに何も変更しなかった場合）、またはUbuntuがNICから関連トラフィックを受け入れないことです。

この問題を解決する方法がわかりません。

編集2：クライアントデバイスをホームラップネットワークに物理的に接続し、期待どおりにすべてのサーバーにアクセスできました。ところで（物理接続は維持しながら）WireGuardを有効にしましたが、192.168.10.240を除くすべてのサーバーにアクセスできませんでした。そのため、WireGuard クライアントが確実にトンネルを介してこれらのアドレスにトラフィックをルーティングしていることを示します。

また、非常に最小限の構成（以下を参照）を一時的に試してみましたが、iptables変更されませんでした。

WireGuardサーバーの設定：

[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = [redacted]
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
[Peer]
PublicKey = [redacted]
AllowedIPs = 10.8.0.2/32

WireGuardクライアントの設定：

[Interface]
PrivateKey = [redacted]
Address = 10.8.0.2/24

[Peer]
PublicKey = [redacted]
AllowedIPs = 10.8.0.1/24, 192.168.10.0/24
Endpoint = example.org:51820

ネットワークの詳細：

  • サブネット 192.168.10.0/24
  • ゲートウェイ 192.168.10.1 (UniFi USG)
  • DHCP 範囲 192.168.10.100 - 192.168.10.199

関連ホスト：

  • TrueNASサーバー（物理） - 192.168.10.221
  • QuickSyncサーバー（物理） - 192.168.10.222
  • TrueNAS用IPMI（物理） - 192.168.10.231
  • TrueNASサーバーでホストされているUbuntu VM - 192.168.10.240（WireGuardサーバー！）
  • QuickSyncサーバー（macvlan）のDockerコンテナ - 192.168.10.241

道：

C:\Users\test>tracert 192.168.10.221

Tracing route to 192.168.10.221
over a maximum of 30 hops:

  1     *       25 ms    20 ms  10.8.0.1
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.
  4     *        *        *     Request timed out.
  5     *        *        *     Request timed out.
  6     *        *        *     Request timed out.
  7     *        *        *     Request timed out.
  8     *        *        *     Request timed out.
  9     *        *        *     Request timed out.
 10     *        *        *     Request timed out.
 11     *        *        *     Request timed out.
 12     *        *        *     Request timed out.
 13     *        *        *     Request timed out.
 14     *        *        *     Request timed out.
 15     *        *        *     Request timed out.
 16     *        *        *     Request timed out.
 17     *        *        *     Request timed out.
 18     *        *        *     Request timed out.
 19     *        *        *     Request timed out.
 20     *        *        *     Request timed out.
 21     *        *        *     Request timed out.
 22     *        *        *     Request timed out.
 23     *        *        *     Request timed out.
 24     *        *        *     Request timed out.
 25     *        *        *     Request timed out.
 26     *        *        *     Request timed out.
 27     *        *        *     Request timed out.
 28     *        *        *     Request timed out.
 29     *        *        *     Request timed out.
 30     *        *        *     Request timed out.

Trace complete.

サーバーからクライアントへのping

PING 10.8.0.2 (10.8.0.2) 56(84) bytes of data.
64 bytes from 10.8.0.2: icmp_seq=1 ttl=128 time=20.4 ms
64 bytes from 10.8.0.2: icmp_seq=2 ttl=128 time=27.0 ms
64 bytes from 10.8.0.2: icmp_seq=3 ttl=128 time=19.4 ms
64 bytes from 10.8.0.2: icmp_seq=4 ttl=128 time=27.1 ms
64 bytes from 10.8.0.2: icmp_seq=5 ttl=128 time=27.2 ms
^C
--- 10.8.0.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 19.409/24.223/27.209/3.536 ms

クライアントから独自にping（VPNから）

Pinging 10.8.0.2 with 32 bytes of data:
Reply from 10.8.0.2: bytes=32 time<1ms TTL=128
Reply from 10.8.0.2: bytes=32 time<1ms TTL=128

Ping statistics for 10.8.0.2:
    Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

クライアントから他のクライアントへのping

Pinging 10.8.0.2 with 32 bytes of data:
Reply from 10.8.0.2: bytes=32 time=64ms TTL=127
Reply from 10.8.0.2: bytes=32 time=41ms TTL=127
Reply from 10.8.0.2: bytes=32 time=39ms TTL=127

Ping statistics for 10.8.0.2:
    Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 39ms, Maximum = 64ms, Average = 48ms

ミニマリストiptablesの設定

# Generated by iptables-save v1.8.7 on Sun Apr 14 14:57:35 2024
*filter
:INPUT DROP [0:0]
:FORWARD DROP [119314:15037722]
:OUTPUT ACCEPT [169491:32755967]
:DOCKER-USER - [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -j ACCEPT
-A FORWARD -j DOCKER-USER
-A FORWARD -i wg0 -j ACCEPT
-A FORWARD -o wg0 -j ACCEPT
-A DOCKER-USER -j RETURN
COMMIT
# Completed on Sun Apr 14 14:57:35 2024
# Generated by iptables-save v1.8.7 on Sun Apr 14 14:57:35 2024
*nat
:PREROUTING ACCEPT [222:56161]
:INPUT ACCEPT [14:1327]
:OUTPUT ACCEPT [248:13567]
:POSTROUTING ACCEPT [256:16075]
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
# Completed on Sun Apr 14 14:57:35 2024

答え1

WireGuardサーバーでLANインターフェイス名が変更されたか、以前に転送されたNAT接続に一時iptablesルールを追加しましたが、サーバーを再起動するとルールが失われる可能性があります。

サーバーから WireGuard サーバーからその LAN への WireGuard 接続をなりすます一般的なパターンは次のとおりです。

  1. 転送を有効にするカーネルパラメータ（たとえばsysctl net.ipv4.conf.all.forwarding=1）。
  2. ファイアウォールを介したWireGuard接続の転送を許可する（例：iptables -A FORWARD -i wg0 -j ACCEPTその逆）
  3. NATはその接続をLANに転送します（例iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE：）

お客様の場合：

  1. その設定にLANサブネットを追加しますAllowedIPs。

これらすべてがありますが、NATルールのインターフェイス名はeth0最初のイーサネットインターフェイスの伝統的な名前ですが、多くのLinuxディストリビューションではそうです。滑りやすい。

考えられる問題を特定するためにサーバーで実行できる良いコマンドセットは次のとおりです。

sudo wg
sudo cat /etc/wireguard/wg0.conf
sysctl net.ipv4.conf.all.forwarding
ip address
ip route
ip rule
sudo iptables-save
sudo nft list ruleset

他のすべての方法が失敗した場合は、以下を実行してみることもできます。tcpdump各ホストで（このようにTcpdumpを使用したWireGuardのトラブルシューティング記事の説明）は、トラフィックが削除される正確な場所を特定しようとします。

関連情報