5
Port-Weiterleitung - keine Antwort vom Zielserver
Hallo Leute,
ich bin auf ein kleines Problem bei meinem Projekt für ein Internetgateway gestoßen. Folgendes Szenario:
Ich habe einen Client-Rechner, einen Server1 (Main-Server) und einen Server2 (Web-Gateway). Auf beiden Servern (VPS) ist Debian aufgesetzt. Alle 3 Rechner sind via Wireguard VPN über die Schnittstelle wg0 miteinander verbunden, wobei Server1 der Endpunkt (Wireguard-Server) ist.
Nun möchte ich Web-Requests (443) vom Client-Rechner, die bisher bedingt durch den Wireguard-Tunnel über den Server1 und von hier aus ins www liefen, nun zunächst auf Server2 weiterleiten und den Request erst vom Server2 aus ins www weiterleiten. Ich route (iptables) daher die auf Server1 eingehenden Daten von wg0 weiter auf Server2. Die Datenpakete werden auf Server2 dann von wg0 auf die physische Schnittstelle (ens6) per iptables weitergeleitet. Ich sehe mittels tcpdump auch die weitergeleiteten Requests vom Client-Rechner an der ens6 Schnittstelle auf Server2, jedoch erhalte ich keine Antwort an ens6 vom Zielserver. Ich habe keine Ahnung wo die Antworten hängen bleiben:
iptables rules auf Server2:
tcpdump von ens6 port 443 auf Server2:
Der Zielserver ist nat. an diesem Port verfügbar.
Es spielt jetzt erstmal keine Rolle ob auch Port 443 Requests vom Server1 ausgeführt, an Server2 weitergeleitet werden sollen oder nicht (komplett definiertes Routing). Mir geht es erst einmal nur darum, dass ich auf der ens6 Schnittstelle vom Server2 mal eine Antwort vom Zielserver sehe. Mit ChatGPT drehe ich mich mit dieser Frage seit Tagen im Kreis. Daher nun meine Frage hier im Forum. Vielleicht weiß einer einen Rat, was ich noch testen kann, bzw. wo der Fehler liegen könnte.
Vielen Dank!
ich bin auf ein kleines Problem bei meinem Projekt für ein Internetgateway gestoßen. Folgendes Szenario:
Ich habe einen Client-Rechner, einen Server1 (Main-Server) und einen Server2 (Web-Gateway). Auf beiden Servern (VPS) ist Debian aufgesetzt. Alle 3 Rechner sind via Wireguard VPN über die Schnittstelle wg0 miteinander verbunden, wobei Server1 der Endpunkt (Wireguard-Server) ist.
Nun möchte ich Web-Requests (443) vom Client-Rechner, die bisher bedingt durch den Wireguard-Tunnel über den Server1 und von hier aus ins www liefen, nun zunächst auf Server2 weiterleiten und den Request erst vom Server2 aus ins www weiterleiten. Ich route (iptables) daher die auf Server1 eingehenden Daten von wg0 weiter auf Server2. Die Datenpakete werden auf Server2 dann von wg0 auf die physische Schnittstelle (ens6) per iptables weitergeleitet. Ich sehe mittels tcpdump auch die weitergeleiteten Requests vom Client-Rechner an der ens6 Schnittstelle auf Server2, jedoch erhalte ich keine Antwort an ens6 vom Zielserver. Ich habe keine Ahnung wo die Antworten hängen bleiben:
iptables rules auf Server2:
iptables -t nat -A PREROUTING -i wg0 -p tcp --dport 443 -j DNAT --to-destination GATEWAY_IP
iptables -A FORWARD -i wg0 -p tcp --dport 443 -o ens6 -j ACCEPT
iptables -A FORWARD -i ens6 -p tcp --dport 443 -o wg0 -j ACCEPT
iptables -t nat -A POSTROUTING -o ens6 -j SNAT --to-source PUBLIC_IP_OF_SERVER2tcpdump von ens6 port 443 auf Server2:
12:45:09.093140 IP my-vps.62183 > _gateway.https: Flags [S], seq 3435070700, win 65535, options [mss 1380,nop,wscale 6,nop,nop,TS val 442870757 ecr 0,sackOK,eol], length 0
12:45:09.237013 IP my-vps.62183 > _gateway.https: Flags [S], seq 3435070700, win 65535, options [mss 1380,nop,wscale 6,nop,nop,TS val 442870902 ecr 0,sackOK,eol], length 0
12:45:09.383046 IP my-vps.62183 > _gateway.https: Flags [S], seq 3435070700, win 65535, options [mss 1380,nop,wscale 6,nop,nop,TS val 442871047 ecr 0,sackOK,eol], length 0
12:45:09.527056 IP my-vps.62183 > _gateway.https: Flags [S], seq 3435070700, win 65535, options [mss 1380,nop,wscale 6,nop,nop,TS val 442871191 ecr 0,sackOK,eol], length 0Der Zielserver ist nat. an diesem Port verfügbar.
Es spielt jetzt erstmal keine Rolle ob auch Port 443 Requests vom Server1 ausgeführt, an Server2 weitergeleitet werden sollen oder nicht (komplett definiertes Routing). Mir geht es erst einmal nur darum, dass ich auf der ens6 Schnittstelle vom Server2 mal eine Antwort vom Zielserver sehe. Mit ChatGPT drehe ich mich mit dieser Frage seit Tagen im Kreis. Daher nun meine Frage hier im Forum. Vielleicht weiß einer einen Rat, was ich noch testen kann, bzw. wo der Fehler liegen könnte.
Vielen Dank!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 92272612016
Url: https://administrator.de/contentid/92272612016
Ausgedruckt am: 19.11.2024 um 11:11 Uhr
5 Kommentare
Neuester Kommentar
Hi.
Also ein DNAT ist schon mal der vollkommen falsche Weg denn das entfernt ja das ursprüngliche Ziel das der Client ja erreichen will aus den Paketen, folglich bleibt es dann an Server 2 hängen weil das dann das neue Ziel des Pakets ist. Du hast stattdessen folgende TODOs um dein Ziel zu erreichen
Die Route und Rule Befehle sind natürlich eine On The Fly Config. Die musst du dann wenn es läuft noch als permanente Konfiguration in deinem von dir genutzten Netzwerkmanager hinterlegen.
So wird ein Schuh draus 😉
Gruß wrk
Also ein DNAT ist schon mal der vollkommen falsche Weg denn das entfernt ja das ursprüngliche Ziel das der Client ja erreichen will aus den Paketen, folglich bleibt es dann an Server 2 hängen weil das dann das neue Ziel des Pakets ist. Du hast stattdessen folgende TODOs um dein Ziel zu erreichen
- Entferne also das DNAT
- Das Forwarding muss sowohl auf Server 1 als auch auf Server 2 in der Firewall durchgängig sein.
- Füge 0.0.0.0/0 in den AllowedIPs des Peers Server2 auf Server1 ein. (Dies ist nötig damit der Rücktraffic der Gegenstelle des Clients auch über Wireguard an Server 1 angenommen wird, alternativ aber unschön der Performance wegen ist wenn du alles was an Server2 über wg0 geht auf seine WG IP SRCNATest )
Table = Off in der Wireguard Interface Config erreichen, muss dann aber sämtliche Routen zu den WG Peernetzen, sollte es welche geben, selbst anlegen).- Füge die IP des Clients in den AllowedIPs der Wireguard Config auf Server2 ein falls diese oder das Subnetz dort noch nicht hinterlegt ist.
- Erstelle auf Server1 eine neue Routing-Table in der
/etc/iproute2/rt_tables, z.B.10 table100 - Füge der neuen Routing-Tabelle auf Server 1 die WG IP von Server 2 als Default-Gateway hinzu:
ip route add default via <WG-IP-von-Server2> table table100 - Erstelle auf Server 1 eine Routing Rule für die Client IP damit für diesen die neue Routing-Tabelle genutzt wird:
ip rule add from x.x.x.x/32 iif wg0 table table100 - Das sämtlicher ausgehender Traffic an Server 2 ausgehend über ens6 geMASQUERADED wird sollte klar sein das hast du ja bereits.
- Setze die Default-Route am Client über den Wireguard Tunnel.
Die Route und Rule Befehle sind natürlich eine On The Fly Config. Die musst du dann wenn es läuft noch als permanente Konfiguration in deinem von dir genutzten Netzwerkmanager hinterlegen.
So wird ein Schuh draus 😉
Gruß wrk
2
Definiere mal den Zielserver. Soll das Server2 sein?
Du hast zwar die Route ins Internet beschrieben, gibt es denn auf den Servern auch eine Route zurück? Wenn du auf Server1 NATtest, muss das Paket vom Server2 auch wenigstens wieder zum Server1 zurück finden, zu der Schnittstelle, die geNATtet hat.
Du hast zwar die Route ins Internet beschrieben, gibt es denn auf den Servern auch eine Route zurück? Wenn du auf Server1 NATtest, muss das Paket vom Server2 auch wenigstens wieder zum Server1 zurück finden, zu der Schnittstelle, die geNATtet hat.
Keine Antwort ist auch eine Antwort.
Bitte dann den Haken am Beitrag nicht vergessen.
Bitte dann den Haken am Beitrag nicht vergessen.
Hallo,
vielen Dank für Eure Beiträge! Sorry, ich bin noch nicht wieder dazu gekommen. Ich melde mich aber alsbald!
vielen Dank für Eure Beiträge! Sorry, ich bin noch nicht wieder dazu gekommen. Ich melde mich aber alsbald!
Die von wrk beschriebene Lösung umzusetzen ist augenscheinlich sehr komplex und bei vielen Peers mit unterschiedlichen Berechtigungen (welcher Peer darf im VPN auf welchen Peer und welchen Port zugreifen) sehr unübersichtlich, da die Wireguard-Routen dann alle manuell erstellt werden müssten (viele manuelle Routen gepaart mit vielen iptable rules). Vielleicht ist in meinem Fall die bessere Lösung ja doch ein WebProxy, bei dem die Web-Requests der Clients nur über den Wireguard-Server an den WebProxy und von dort aus ins www geleitet werden? Das wäre doch wesentlich weniger Konfigurationsaufwand? Was meint ihr?
