Wireguardサーバーとクライアントは相互にpingを実行できますが、Wireguardクライアントは相互にpingを実行できません
次のエンティティがあるWireguard構成をセットアップしています。
GoogleCloudやAmazonawsなどのホスト上のリモートVMインスタンス。これは私のwireguardサーバーへのリモートクライアントです。これを呼びましょう
gcp_clientLANでホストされているマシン上のwireguardサーバー。これを呼びましょう
srvlan。
- IPv4転送は、このデバイスでによって有効になり
sysctlます。 - WANとLANの間にUbiquitiEdgerouter4があります。このデバイスでポートフォワーディングとヘアピンNATを有効にしました。また、このルーターにダイナミックDNSを設定しました。
- LAN上の1つ以上のクライアント。これは、LAN上のマシンであるかのようにリモートクライアントに接続できる必要があります。私は最初のクライアント自体で問題に直面しているので、それを呼びましょう
client1。
私のセットアップでは、私は間でpingを実行することができていますsrvlanし、gcp_client両方の方法との間client1とsrvlan同様に。しかしながら。からgcp_clientへのping client1（およびその逆）は失敗します。
の結果を読んでtcpdump -i wg0 -n icmp、私は次のことを観察しました。
- から到達
client1するgcp_clientようにpingを実行しますsrvlanが、ルーターには転送されません。 - からpingを実行
gcp_clientしclient1てルーターに到達すると、ルーターがに転送しますsrvlan。しかし、パケットがによって転送されませんsrvlanへclient1。
これから私が結論付けることができる唯一のことは、上の転送ルールsrvlanがどういうわけか欠陥があるということです。私はnftablesこのデバイスを管理するために使用しています。
これは私のワイヤーガード構成です。IPアドレスとポート番号が変更されました。
# wg0.conf for gcp_client
[Interface]
Address = 10.0.1.2/24
ListenPort = 50000
PrivateKey = gcp_client_privkey
[Peer]
PublicKey = srvlan_pubkey
AllowedIPs = 10.0.1.0/24
Endpoint = srvlan_ddns:50000
# wg0.conf for srvlan
[Interface]
Address = 10.0.1.1/24
ListenPort = 50000
PrivateKey = srvlan_privkey
[Peer]
PublicKey = gcp_client_pubkey
AllowedIPs = 10.0.1.2/32
Endpoint = gcp_client_domainname:50000
PersistentKeepalive = 25
[Peer]
PublicKey = client1_pubkey
AllowedIPs = 10.0.1.3/32
Endpoint = client1_lanhostname:50000
PersistentKeepalive = 25 # I realise this one is unnecessary, but I had added it while testing just in case the problem got fixed.
# wg0.conf for client1
[Interface]
Address = 10.0.1.3/24
ListenPort = 50000
PrivateKey = client1_privkey
[Peer]
PublicKey = srvlan_pubkey
AllowedIPs = 10.0.1.0/24
Endpoint = srvlan_lanhostname:50000
これは私のファイアウォールsrvlanです。
# nft list ruleset
table inet firewall {
chain inbound {
type filter hook input priority filter; policy drop;
ct state established,related accept
ct state invalid drop
iif "lo" accept
ip protocol icmp accept
ip6 nexthdr ipv6-icmp accept
ip protocol igmp accept
tcp dport 22 accept
iifname "eno1" tcp dport { 80, 443 } ct state new accept
iifname "eno1" udp dport 50000 ct state new accept
iifname "wg0" udp dport 53 ct state new accept
iifname "wg0" tcp dport { 80, 443 } ct state new accept
iifname "wg0" udp dport 50000 ct state new accept
}
chain forward {
type filter hook forward priority filter; policy drop;
ct state established,related accept
ct state invalid drop
iifname "wg0" oifname "eno1" ct state new accept
}
chain outbound {
type filter hook output priority filter; policy accept;
ct state invalid drop
}
}
table ip router {
chain prerouting {
type nat hook prerouting priority filter; policy accept;
}
chain postrouting {
type nat hook postrouting priority srcnat; policy accept;
oifname "eno1" ip saddr 10.0.1.0/24 masquerade
}
}
回答
ときsrvlan転送WireGuard-トンネルトラフィック、それから、それを受信WG0に...とルートそれをWG0再：二度同じインターフェイスを。
したがって、このエントリをnftablesのinetファイアウォールフォワードチェーンに追加する必要があります。
iifname "wg0" oifname "wg0" accept
その他の問題、チェーンインバウンド：
ip protocol icmp accept ip6 nexthdr ipv6-icmp accept ip protocol igmp accept
ながらプロトコルはIPv4で動作し、nexthdrプロトコルIPv6における次にヘッダーのICMPv6になることはない保証はない：いくつか存在することができる拡張ヘッダ固定ヘッダと上位層プロトコルヘッダとの間。そのような拡張ヘッダーが一部のパケットに表示さnexthdr ipv6-icmpれると、一致しなくなります。IPv4およびIPv6には、正しい構文を使用してください。
meta nfproto ipv4 meta l4proto icmp accept
meta nfproto ipv6 meta l4proto ipv6-icmp accept
meta nfproto ipv4 meta l4proto igmp accept
nftablesのバージョンによっては、より簡略化された形式で表示されます。
iifname "wg0" udp dport 50000 ct state new accept
ポート50000は、WireGuardインターフェイスの内部には表示されませんが（WireGuard内でWireGuardをトンネリングする場合を除く）、外部に表示されます（既にルールがあります）。必要ないはずです。
（正しく行ったように）WireGuardクライアント/ピアを追加するときは、標準ルーティングの後に適切なピアを選択するためにWireGuardで発生する暗号化ルーティングを決定するため、srvlanのAllowedIPsエントリに重複がないことを忘れないでください。また、場合gcp_clientを介して接続srvlanサーバーへのWireGuardトンネルを使用していないし、彼らのLANアドレスも両方を追加する必要がありますAllowedIPsとのルーティングテーブルgcp_client。AllowedIPsは、送信元に基づいてパケットを受け入れる（および、ローミングの場合にどのピアを決定し、場合によってはエンドポイントを更新する）ためと、宛先に基づいてパケットを送信するピアを決定するための両方に使用されます。