Ich habe also einen VPS-Server (KVM), auf dem Debian Bullseye mit einer öffentlichen IP läuft. Auf diesem Server läuft auch ein Wireguard-Server. Zu Hause habe ich einen weiteren Server (hinter NAT) mit einem Wireguard-Client, der mit meinem VPS verbunden ist. Der Tunnel ist aktiv, d. h. ich kann über das Wireguard-VPN ordnungsgemäß kommunizieren.
+----------------------------------+ +-------------------------------
| Homeserver (behind NAT) | | VPS (KVM) with public IP |
| 192.168.1.10 | | 1.2.3.4 |
| +------------------------| |--------------------+ |
| | wg-homeserver | - - - - - - | wg-vps | |
| | 192.168.200.2 | | 192.168.200.1 | |
| +------------------------| |--------------------+ |
| | | |
+----------------------------------+ +------------------------------+
Auf meinem Heimserver laufen mehrere Docker-Container, die auf Ports (auf allen IP-Adressen) lauschen, d. h. diese Ports sind von 192.168.1.0/24 aus erreichbar. Ich muss jetzt einen TCP- und einen UDP-Port an die öffentliche IP-Adresse meines VPS weiterleiten und den Verkehr über die Wireguard-Verbindung an dieselben Ports auf meinem Heimserver weiterleiten:
1.2.3.4:10000/tcp -> 192.168.200.2:10000/tcp
1.2.3.4:10001/udp -> 192.168.200.2:10001/udp
Die IP-Weiterleitung ist auf beiden Maschinen aktiviert, d. h. es cat /proc/sys/net/ipv4/ip_forwardwird angezeigt 1.
Zum Weiterleiten des TCP-Ports habe ich diese Regeln:
iptables -A FORWARD -d 192.168.200.2/32 -i wg-vps -p tcp --dport 10000 -j ACCEPT
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 10000 -j DNAT --to-destination 192.168.200.2:10000
Wenn ich es versuche, ssh -p 10000 1.2.3.4sehe ich keine Pakete, die von protokolliert werden wireguard -i wg-vps. Ich habe zahlreiche andere Dinge probiert, konnte aber nicht herausfinden, was ich falsch mache oder übersehe.
Wie dem auch sei, ich habe diese Regel für den UDP-Port erstellt, mit etwas mehr Erfolg:
iptables -t nat -A PREROUTING -d 1.2.3.4/32 -i eth0 -p udp --dport 10001 -j DNAT --to-destination 192.168.200.2:10001
So sende ich mein UDP-Testpaket:
echo -n test | nc -4 -u 1.2.3.4 10001
Wenn ich dies tue, kann ich tcpdump -i wg-vpsin meinem VPS-Protokoll Folgendes sehen ( 4.5.6.7das ist meine öffentliche IP-Adresse):
11:35:47.497622 IP 4.5.6.7.43357 > 192.168.200.2.10001: UDP, length 4
Es scheint, als würde es versuchen, das Richtige zu tun und das Paket zu nehmen, das Ziel auf zu aktualisieren 192.168.200.2und es dann auf die Wireguard-Schnittstelle zu legen wg-vps. Aber tcpdump -i wg-homeserverauf meinem Heimserver wird dieses Paket nie als angekommen angezeigt.
Tatsächlich ist mir aufgefallen, dass watch ip -s link show wg-homeserverjedes Mal, wenn ich auf meinem Homeserver ein UDP-Paket an diesen Port schicke, die RX-Fehler um eins erhöht werden.etwasschafft es bis dorthin, aber was auch immer es ist, es wird nicht angezeigt tcpdumpund scheint irgendwo weiter unten abgelegt zu sein. Das ist seltsam, weil sowohl UDP als auch TCP über die Wireguard-Verbindung in beide Richtungen einwandfrei funktionieren.
Soweit ich es verstehe, tcpdumpwerden Pakete vor iptables angezeigt. Daher vermute ich, dass das Paket, obwohl es scheinbar in die Wireguard-Schnittstelle geschrieben wird, irgendwo verloren geht.
AKTUALISIEREN: Ok, ich habe also einen Weg gefunden, die Wireguard-Protokollierung zu aktivieren:
echo module wireguard +p > /sys/kernel/debug/dynamic_debug/control
Und wenn man die Protokolle mit verfolgt, dmesg --followsieht es so aus, als würde Wireguard das Paket aus folgendem Grund löschen:
wireguard: wg-homeserver: Packet has unallowed src IP (4.5.6.7) from peer 20 (xxxxxx)
Ich denke, das bedeutet, dass es ihm nicht gefällt, dass die Quelladresse die ursprüngliche Adresse ist, von der die Anfrage kam. Ich möchte kein SNAT verwenden, also muss ich ihm wohl irgendwie beibringen, dass es jede beliebige Quelladresse zulassen soll.
Es stellt sich heraus, dass es sich um die AllowedIPsEinstellung im [Peer]Abschnitt meiner Wireguard-Konfiguration handelt. Dies löst das Problem:
AllowedIPs = 0.0.0.0/0, ::0/0
Zuvor hatte ich die Schnittstellenmasken ähnlich denen im [Interface]Abschnitt eingefügt, ohne zu wissen, dass dies die Quelladressen der Pakete einschränken würde.
Dies kapert jedoch den gesamten Datenverkehr und versucht, ihn über den Wireguard-Link umzuleiten, da dieser dies wg-quicküberprüft AllowedIPsund denkt, dass er eine Route hinzufügen und den gesamten Datenverkehr über das VPN umleiten sollte. Dies ist offensichtlich nicht erwünscht, aber zum Glück gibt es eine Lösung: Durch Hinzufügen Table = offzum [Interface]Abschnitt wird dies verhindert.
Antwort1
Sehen Sie in Ihrer Regeltabelle nach, um zu verstehen, wie die ausgehenden Pakete am Heimserver geroutet werden. wg-quick wird einige Regeln hinzufügen.
ip rule show
Ich musste einige von wg-quick generierte Regeln entfernen (dadurch werden alle Pakete an wg weitergeleitet) und dann Regeln hinzufügen, die die erforderlichen Ports weiterleiten. Sie können die wg-Tabellennummer aus dem obigen Befehl sehen.
ip -4 rule add sport 80 table XXXXX
ip -4 rule add sport 443 table XXXXX
Das oben genannte hat eine Zeit lang funktioniert. Aber systemd-networkd entfernt benutzerdefinierte Regeln, wenn die DHCP-Lease abläuft oder das LAN-Kabel getrennt und wieder angeschlossen wird. Daher habe ich wg-quick vollständig entfernt und verwende systemd-networkd, um die wg-Schnittstelle und die Routing-Regeln zu konfigurieren.