oh, IPv6 NAT auf eine ULA. welche vorteile hat das gegenüber einem forward auf eine public IP?
Man umgeht ggf. das NDP Proxy Problem, wenn man mit dem mitgelieferten /64 arbeitet. Aber ansonsten würde ich das auch nicht machen.
Beiträge von frank_m
-
-
Und hatte die Config halt kopiert und vervierfacht, es sollte ja nicht so schlimm sein wenn was doppelt ist.
Falsch. Bei iptables ist die Reihenfolge der Regeln von essentieller Bedeutung, da sie der Reihe nach abgearbeitet werden und bei einem Match die Abarbeitung beendet wird. man sollte sich sehr genau überlegen, welche Regel wo steht.
-
Meines Erachtens ist das Regelset kompletter Unsinn, und die entscheidenden sind auch syntaktisch falsch.
Zunächst braucht jede Regel nur 1x drin zu sein. Einmal "iptables -A FORWARD -i ens3 -o wg0 -j ACCEPT" reicht. Wobei ich das Forwarding nicht so uneingeschränkt erlauben würde, sondern eher eine Regel für die Antworten auf etablierte Verbindungen und dann port-spezifsche Regeln nutzen würde. Dann macht "multiport" nur Sinn, wenn es auch mehrere Ports in der Regel gibt. Und bei DNAT muss man einen Zielport eingeben. Bei mehreren öffentlichen IPs macht es ggf. Sinn, die mit anzugeben, weil ja vielleicht das Ziel der zweiten IP anders sein soll, als das der ersten (wofür braucht man sonst zwei öffentliche IPs?).
Ein korrektes Beispiel sähe für mich so aus:
Codeiptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -i ens3 -p tcp --dport 8080 -d 192.168.1.21 -j ACCEPT iptables -t nat -A PREROUTING -i ens3 -d <öffentliche IP 1> -p tcp --dport 8080 -j DNAT --to-destination 192.168.1.21:8080 iptables -A FORWARD -i ens3 -p tcp --dport 8080 -d 192.168.1.22 -j ACCEPT iptables -t nat -A PREROUTING -i ens3 -d <öffentliche IP 2> -p tcp --dport 8080 -j DNAT --to-destination 192.168.1.22:8080 iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o ens3 -j MASQUERADESo leitest du Port 8080 von deiner ersten öffentlichen IP auf 192.168.1.21 weiter, und von der zweiten öffentlichen IP auf 192.168.1.22. Außerdem erlaubst du Antworten auf etablierte Verbindungen. Das ganze für UDP dann synonym.
-
Der würde mein Test-Server werden. Im Moment hab ich nur einen Produktiv-Server, und hab mich schon oft geärgert, dass ich nicht mal eben schnell Dinge ausprobieren kann.
-
Habe die IP in der /etc/network/interfaces eingetragen so wie es im netcup wiki steht mit z.B. ens3, ens3:1 usw natürlich das Gateway und so angepasst auf mein system.
Gateway angepasst? Die zweite IP wird doch auf die erste geroutet. Da ändert sich nichts am Gateway. Die 2. IP hat ja üblicherweise auch Subnetzmaske /32. ens3:1 macht man ja häufig auch nicht mehr, sondern weist die IPs direkt dem Hauptinterface zu. Das sollte aber für deinen Anwendungsfall keinen Unterschied machen.
Habe dann versucht in der WG config die vorhandenen regeln zu kopieren und anzupassen auf das neue interface + andere IP im Heimnetz. Ohne Erfolg.
Ganz ehrlich: Ich hätte nicht erwartet, dass dies 2. IP überhaupt einen Einfluss auf die WG conf hat. An den Allowed IPs ändert sich ja nichts, da du ja eh natten musst.
Vielleicht hab ich aber auch das Problem nicht richtig verstanden.Du willst von zwei öffentlichen IPs Ports in ein Heimnetz leiten, richtig? Das geht problemlos über einen Tunnel.
-
Nur wenn ich die Firewall von Proxmox aktiviere, dann klappt das POSTROUTING nicht mehr.
Was macht die Firewall denn? Die muss ja irgendwie auch Regeln eintragen (oder löschen). Das würde ich doch mal als erstes analysieren.
Alternativ würde es mir auch reichen, wenn ich iptables komplett manuell auf dem Host konfiguriere und die Proxmox-Lösung einfach nicht benutze, aber dafür müsste ich wissen, welche Ports Proxmox nutzt.
https://pve.proxmox.com/wiki/Ports. Da ist die Frage, was du davon öffentlich verfügbar machen willst. Meines Erachtens ist das alles was für hinter einem VPN.
-
Der Internet Zugriff auf die IPv4 Internet Welt via AFTR Gateway des Provider ist nicht performant.
Das allein kann es aber nicht sein, da Prime ja gut läuft und auch da durch muss. Prime arbeitet nämlich auch mit IPv4.
-
Amazon Prime und alle Dienste die zu Google gehören funktionieren immer, und sind auch performant.
Dann ist das AFTR Gateway aber raus, denn zumindest Prime läuft auch über IPv4.
Ich möchte mit dem IPv6 Wireguard Tunnel eigentlich nur das schlechte CGNAT meines ISP umgehen, und wieder Spaß am schnellen und zuverlässigen Surfen im Internet haben.
Wie gesagt, hat Nachteile. Wenn deine Abgangs-IP nicht aus einem Pool für Privatkundenanschlüsse kommt, dann verweigern viele Dienste die Zusammenarbeit.
Was mich noch stutzig macht: Du beklagst dich beim direkten Zugriff über deinen Provider über die langsame Übertragung und schlechten Zugriff. Und du beklagst dich bei deiner VPN Verbindung über langsame Übertragung und schlechten Zugriff. Merkst du was? Ich würde mal in Erwägung ziehen, abseits der Internetverbindung nach Ursachen zu suchen.
-
Für ausgehenden Datenverkehr nutze ich so einen VPN Tunnel auch nur im Notfall (hinter restriktiven Firewalls). So eine VPN Lösung eignet sich hervorragend für Portweiterleitungen an DS-Lite oder CGNAT Anschlüssen.
-
Also genau so wie ich es haben wollte, aber ist das dann ohne MAQUERADE überhaupt möglich?
Eine MAQUERADE Regel hast du ja drin. Möglicherweise greift die, weil der Traffic vom VPN Client kommt.
Fakt ist, um die Daten ins Internet zu routen, musst du NAT machen, denn private Adressen werden im Internet nicht geroutet. Und sowohl dein 192er Netz als auch das 10er VPN Netz sind private Adressen.
-
Wenn ich alles jetzt nachverfolgt habe geht der Internetverkehr über den eth0 Adapter mit der IPv6 Adresse statt über den VPN
Das ist natürlich denkbar, wenn der VPN Client eine IPv6 Verbindung hat, kann er die anstatt des Tunnels benutzen. Dann musst du entweder IPv6 auch über den Tunnel leiten, oder IPv6 im Client deaktivieren (oder zumindest die Default-Route entfernen.
Auf jeden Fall braucht es dann aber auch noch eine MASQUERADE fürs 192er Netz auf dem VPN Server.
-
Ich habe das so verstanden, dass er einen Dienst auf dem VPS nutzen will und das dieser nur über VPN erreichbar sein soll.
Ok, dann machen die Regeln Sinn. Aber die Fragestellung war eine andere, wie man am verlinkten Thread erkennt:
https://unix.stackexchange.com/questions/449853/port-forwarding-using-openvpn-client
Der Dienst ist hinter dem VPN Client und soll durch die öffentliche IP des VPN Servers erreicht werden.
-
# Was rein geht auf dem Interface wg0 mit Ziel 10.8.0.0/24 wird akzeptiert. Man könnte auch 10.8.0.1 einsetzen.
iptables -A INPUT -m state --state NEW -i wg0 -d 10.8.0.0/24 -j ACCEPT
Die Frage ist, was die Regel bewirken soll. Damit kann man über VPN einen Serverdienst auf dem vServer erreichen. Für die ursprüngliche Fragestellung, also Eine Portweiterleitung von außen und Internetzugriff für die VPN Clients, hilft die Regel nicht.
Das gleiche auch für ipv6, denn dort stehen die Policy default auch auf ACCEPT.
Wenn die Default INPUT Policy Accept ist, dann braucht es die Regel gar nicht.
-
iptables -A INPUT -m state --state NEW -m udp -p udp --dport <openVPN-Port> -j ACCEPT
Die Regel erlaubt es, eine OpenVPN Verbindung aufzubauen.
iptables -A INPUT -m state --state NEW -i wg0 -d 192.168.206.0/24 -j ACCEPT
Die Regel erlaubt Datenverkehr mit den Zieladressen 192.168.206.0/24 auf dem wg0 Interface. Da es eine INPUT Regel ist, betrifft es nur den vServer selber und die Dienste, die darauf laufen. Auf andere Dienste oder Geräte hinter einem VPN Tunnel hat diese Regel keinen Einfluss, dafür würde es Forward Regeln brauchen.
Wenn du die Regel hast, um Daten in einen VPN Tunnel zu leiten, dann bin ich mir nicht sicher, ob die überhaupt irgendwas tut. Schau doch mal nach mit iptables -Lv, wie oft die Regel verwendet wurde.
-
Warum um Himmels willen soll ein einzelner Server in deinem Heimnetz seinen Internetverkehr über das VPN abwickeln? Das macht für mich überhaupt keinen Sinn.
Die Ports nach draußen sind nicht geblockt. Aber ausgehender Traffic vom Grafana-Server kommt beim OpenVPN Server mit Quell-Adresse 192.168.1.91 an. Das hat zwei Dinge zur folge:
- Der VPN Server kennt den Rückweg nicht
- Der VPN Server leitet die Pakete nicht ins Internet, weil private Adressen nicht ins öffentliche Netz geroutet werden dürfen.
Es gibt bei dir ja schon eine MASQUERADE Regel für 10.8.0.0/24. Genau die brauchst du auch noch mal für 192.168.1.0/24. Dazu muss sichergestellt sein, dass es eine Subnetz Route für 192.168.1.0/24 gibt, mit Gateway 10.8.0.2.
-
Kannst du mal an einem konkreten Beispiel erläutern, wie genau das funktionieren soll?
-
Joa. Aber das kann jede(r) andere im Internet dann auch machen..
Nicht unbedingt. Wenn adguard.domain.de eine private IP zurückliefert, die nur über VPN erreichbar ist, dann hängt er nicht im Internet.
-
Und es ist auch keine cron Alternative drin? anacron oder sowas?
-
Wenn ich mich aber auf dem Server bin, auf dem das grafana läuft, habe ich keine Verbindung zum Internet.
Das liegt an dieser Einstellung in deiner Server.conf:
Codepush "redirect-gateway def1 bypass-dhcp"Du sagst dem VPN Client, er solle das Internet über die VPN Verbindung leiten soll. Er wird die Daten vermutlich mit seiner 192er Adresse absenden, und das führt dazu, dass der Internetzugang nicht funktioniert, weil auf dem Server die MASQUERADING Regel fehlt.
Soll das Internet des Servers über den VPN Tunnel laufen? Ansonsten entferne die Option.
Bei der Gelegenheit: Du pusht auch andere DNS Server zum Client. Ist das gewollt?
-
Nur der Vollständigkeit halber:
client-config-dir /etc/openvpn/ccd
Sind da noch Client-spezifische Konfigurationen aktiv?
iptables -t nat -I PREROUTING 1 -d 89.58.X.X -p tcp --dport 3000 -j DNAT --to-dest 192.168.1.91:3000
Warum steht in der Regel hinter dem PREROUTING eine 1?
Ich vermute, deine Einbeziehung der 192er Adresse aus deinem Heimnetz ist das Problem, denn die wird auf dem Server nicht maskiert. Eine MASQUERADE Regel gibt es nur für das 10er Netz.
Generell hab ich nicht verstanden, warum du das 192er Netz in deinem Setup einbeziehst. Der Server läuft ja anscheinend direkt auf dem VPN Client, also kannst du auch die 10.8.0.2 als Ziel in deinen Regeln benutzen. Die SNAT Regel kannst du dann ganz sparen. Also mein Vorschlag für ein Regel-Set ist:
Codesysctl net.ipv4.ip_forward=1 iptables -t nat -I PREROUTING -d 89.58.X.X -p tcp --dport 3000 -j DNAT --to-dest 10.8.0.2:3000 iptables -I FORWARD -d 10.8.0.2 -p tcp --dport 3000 -j ACCEPTMeines Erachtens brauchst du auch die statische Route in der Fritzbox nicht, da der VPN Client die Route ins VPN Netz schon kennt.
Wenn später andere Geräte aus dem 192er Netz einbezogen werden sollen, dann muss man die Regeln überarbeiten. Ich würde da nicht mit SNAT arbeiten, sondern fürs VPN vollwertig routen, dann eine statische Route fürs VPN Netz in die Fritzbox und eine MASQUERADING Regel fürs 192er Netz auf den Server. So nutze ich es im Moment mit einer Wireguard Verbindung.
