Wie viele der Einträge muss man eigentlich übernehmen? Insgesamt werden mir bei de desec 3 Einträge angezeigt, 2 DS Records und ein DNSKEY Record. Allerdings kann ich davon nur einen erfolgreich bei netcup eintragen. Den DNSKEY Record kann ich gar nicht eingeben, dazu passt die Eingabemaske nicht. Und von den DS Records wird nur einer übernommen, beim anderen kommt die Fehlermeldung, dass beim Speichern ein Fehler aufgetreten sei.
Beiträge von frank_m
-
-
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 12055
Da stimmt noch was nicht.
-
Oder direkt eine input drop Regel für alles und dann SSH freigeben.
Das ist der Weg. Alles droppen und nur die erlaubten Dinge öffnen.
-
meine global alles zu blockieren außer die Ports die auch erreichbar sein sollen.
Genau das meine ich auch. Abe rman muss sich überlegen, welche Ports man wo braucht. Bei Linux wird strikt unterschieden zwischen INPUT und FORWARD. INPUT braucht man für alles, was direkt auf dem Server verarbeitet wird. FORWARD braucht man dann, wenn der Server was weiterleitet. Wenn Port 8080 als Weiterleitung übers VPN ins Heimnetz dienen soll, kann er beim INPUT zugemacht werden, denn der Port ist auf der externen IP weg und wird lokal auf dem Server garantiert (bzw. hoffentlich) nicht mehr benutzt. Und nur weil man einen Port für FORWARD benutzt, muss er nicht auch bei INPUT geöffnet werden.
-
und zum abrunden sollte es doch reichen mit einer drop regel alle Ports die nicht benötigt werden zu sperren.
Genau. Man kann auch die Default Policy auf DROP stellen.
glaub man kann das doch negieren und somit alles dicht machen außer z.b. 8080 + Wireguard selbst.
Du musst unterscheiden zwischen INPUT und FORWARD. Für INPUT brauchst du den Wireguard Port, aber keine 8080 Regel. Für FORWARD brauchst du die Regeln für dein Heimnetz (8080 z.B.), aber keinen Wireguard Port.
dann kann man ja sogar den ssh Port dicht machen wenn man alles direkt über Wireguard macht.
Ein Fallback ist nie weg. Allerdings würde ich den SSH Port auf irgendwas Ungewöhnliches verlegen, in dem möglichst wenig "22" vorkommt. Das SCP bleibt natürlich als Fallback, ist aber auch echt unkomfortabel.
-
-
-
Multiport Regeln kannst du eigentlich immer einsetzen, wenn Portnummern vorkommen (bei DNAT natürlich nur, wenn Quell- und Zielport identisch sind). Also anstatt
kannst du
Codeiptables -A FORWARD -i eth0 -p tcp -m multiport --dports 8080,8081,8082 -d 192.168.1.21 -j ACCEPTbenutzen.
Alle anderen Regeln kannst du synonym anlegen. Im Grunde brauchst du für jede Zieladresse und jedes Protokoll (tcp, udp) dann einen Eintrag, der alle nötigen Ports beinhaltet. Das natürlich jeweils für die drei PREROUTING, FORWARD, POSTROUTING Regeln oben aus dem Beispiel.
Dann braucht es für ein komplettes Setup vermutlich noch die ESTABLISHED,RELATED Regel. Generell muss das ganze Setup dann abgerundet werden mit einem Regelset, dass den Server an sich schützt. Also alles bis auf VPN zu oder so.
-
Wenn man dann snat nutzen möchte im POSTROUTING dann muss man das dann für jede interne IP machen und braucht dann kein Masquerade mehr?
Man muss es für jede Kombination aus Port, Protokoll (tcp, udp) und interner IP machen. Natürlich kann man eine Multi-Port Regel machen, wenn man möchte, dann ist es nur ein iptables Eintrag, das ist auch ein wenig performanter (weniger Einträge, die iptables durchsuchen muss).
-
Ich hatte ja in meinem letzten Beitrag schon beschrieben, die Regel macht ein Masquerading für die Pakete vom Server über VPN in dein Heimnetz. Damit funktioniert das Split-Routing, weil du nicht den kompletten Internetverkehr über den VPN Tunnel leitest.
Ohne diese Regel werden die Pakete vom Server mit ihrer öffentlichen Absender-IP weitergeleitet (Hast du ja im tcpdump gesehen). Damit werden sie entweder sofort von den Allowed IPs kassiert und kommen gar nicht am Ziel an, oder dein Heimnetz kann nicht richtig drauf antworten. Denn wenn die Absenderadresse der Pakete in deinem Heimnetz noch eine öffentliche IP ist, dann will dein Heimnetz die Antwort über die Default-Route schicken, und das ist nicht der VPN Tunnel. Beim ursprünglichen Absender käme die Antwort von einer anderen Quell-IP an, als er ursprünglich mal als Ziel-IP benutzt hat. Das Antwortpaket wird verworfen, da der Absender die Antwort nicht seiner Frage zuordnen kann.
Mit der Regel ersetzt der Server die originale öffentliche Absender-IP durch die VPN Transportnetz-IP. Das geht durch den Tunnel, und dein Heimnetz weiß, wohin mit der Antwort. Man könnte die generische Masquerade Regel durch spezifischere SNAT Regeln ersetzen, aber ob es was bringt? Viel nicht. Was aber wieder gilt: Die Masquerade Regel darf nur 1x existieren!
Vielleicht noch zur Anschauung:
https://www.tech-island.com/kb/linux/reference/unterschied-zwischen-masquerade-snat-und-dnat
Zur Anschauung noch mal ein kompletter Regelsatz für einen Port mit SNAT anstatt generischem MASQUERADE:
Codeiptables -t nat -A PREROUTING -i eth0 -d ÖFFENTLICHE_IP -p tcp --dport 8080 -j DNAT --to-destination 192.168.1.21:8080 iptables -A FORWARD -i eth0 -p tcp --dport 8080 -d 192.168.1.21 -j ACCEPT iptables -t nat -A POSTROUTING -o VPN -d 192.168.1.22 -p tcp --dport 8080 -j SNAT --to-source 10.0.0.1Zunächst wird die Zieladresse auf die Adresse im Heimnetz umgeschrieben. Dann wird das Forwarding für diese Zieladresse und den Zielport erlaubt. Zuletzt wird die Quelladresse für die Zieladresse und den Zielport umgeschrieben.
Die spezifischen Regeln haben den Vorteil, dass sie nur exakt in dem Moment greifen, wenn ein Paket für die Portweiterleitung bearbeitet wird. Die generische MASQUERADE Regel greift immer, und es kann ja durchaus Anwendungsfälle auf dem VPN abseits der Portweiterleitung geben, für die das nicht erwünscht ist.
-
Ja, was du jetzt halt noch machst, ist ein Masquerade auf den VPN Traffic. Damit kommen in deinem Heimnetz keine Pakete von öffentlichen IPs an, die dein Heimnetzgerät dann natürlich über seine Default-Route beantworten würde. Das wird nicht klappen.
Dennoch würde ich das Forwarding ins Heimnetz einschränken, schon aus Sicherheitsgründen.
-
Vergleiche mal die tcpdumps auf dem Server mit der neuen und der alten Konfig. Gibt es da einen sichtbaren Unterschied?
-
Oh, Moment. In deinen neuen Regeln nutzt du eth0 als Interface, in den alten ens3. Das könnte der entscheidende Unterschied sein. Ist mir vorher nicht aufgefallen, sorry.
-
Also bei einem tcpdump auf das Wireguard Interface mit der neuen Regel passiert nichts.
Die Aussage lässt knapp eine Millionen unterschiedliche Interpretationen zu. Auf dem Server? Auf dem Client? Von außen? Durch den Tunnel?
bei der altern Regel sieht das Ergebnis so aus. Der Port wurde zum Test auf ein SSH Server gelegt.
Was für ein Ergebnis? Ist das eine Weiterleitung komplett durch den Pfad? Dabei ist NAT auf Client-Seite aktiv? Von SSH sieht man da übrigens nichts, das ist Port 8080. Vielleicht solltest du dir angewöhnen, tcpdump mit "-n" aufzurufen, das macht es übersichtlicher.
Und wie sieht es mit der neuen Regel aus?
-
Jetzt hast du mich völlig verwirrt.
Also die Fritzbox hat die 192.168.10.1
Oha. Wo kommt das Netz denn plötzlich her? Davon war bislang überhaupt noch nie die Rede. Spielt das eine Rolle in dem VPN Setup?
es wurde ein Ping vom Server zu dem Gerät hinter dem Wireguard Client gemacht
Das Testszenario hilft natürlich nicht weiter. Von einem kommt das Paket direkt vom Server, zum anderen gibt es für Ping keine FORWARD Regel (die gab es gestern noch, in den neuen Regeln nicht mehr). Es sollte schon ein Zugriff auf einen weitergeleiteten Port sein, den du testest, um die komplette Kette zu überprüfen.
-
Mh, war wohl doch etwas zu voreilig,
aus irgendeinem Grund geht es nicht mehr.
Was ging denn mal? Nach dem "ich werde es testen" kam ja nichts mehr.
Der Client macht NAT und leitet nicht sein Internet über den Tunnel. Hm. Da müsste man jetzt noch mal genauer hinsehen. Kannst du dir mal mit tcpdump ansehen, wie die Pakete den VPN Client in Richtung LAN verlassen? Also vor allem Quell- und Ziel-Adresse?
-
Spart euch doch mal diese ständigen Einwände der Art "Du machst das falsche, weil ich es anders machen würde".
Es geht nicht darum, ob ich es anders machen würde. Es geht um die objektiven Risiken, die man dabei eingeht.
-
Es geht offenbar darum, dass die Nutzer des Wireguard-Tunnels nicht erfahren sollen, was auf dem selben Server über IPv4 läuft bzw. wessen Server das ist.
Aber warum? Was will man darüber machen, um diesen Rückschluss zu unterbinden.
Zum einen wird der Dienst, der auf IPv4 läuft, höchstwahrscheinlich auch auf IPv6 laufen, zumindest wenn sowas wie HTTPS Dienste involviert sind. Dann ist es unwahrscheinlich, dass der Wireguard Dienst, von dem niemand zurückschließen soll, nur über die IP erreicht wird, d.h., ich brauche auch da sowas wie eine Domain. Nicht zuletzt: Mit dem Wireguard Tunnel bin ich auf dem Server. Und zwar unmittelbar drauf. Wenn die anderen Dienste so sensibel sind, sollte man niemanden über VPN einladen.
-
Ich möchte, dass mein WireGuard die öffentliche IPv6 anzeigt, weil auf dem gleichen Server noch ein anderer Dienst läuft.
Ich verstehe kein Wort. Wie soll Wireguard den eine IP "anzeigen"? Meinst du bei einem Verbindungscheck, oder was? Sowas wie "https://www.wieistmeineip.de/"?
Blöd ist dabei, dass bei einem IPv4 Lookup die FQDN meines Dienstes angezeigt wird.
Meinst du damit einen Reverse DNS Lookup, oder was? Da will ich doch hoffen, dass der FQDN angezeigt wird. Warum sollte man das vermeiden wollen? Im Gegenteil, viele Dienste laufen nicht, wenn es anders wäre.
Beim Aufruf der IPv4 im Browser kommt auch eine SSL Warnung, worin die FQDN zu erkennen ist.
Kein Wunder, die steht ja auch im Zertifikat, und auch das muss zwangsläufig so sein.
Es ist zwar möglich, dass Schema HTTP und HTTPS nicht den Inhalt meiner FQDN anzeigen, trotzdem wird über das Schema HTTPS in der SSL Warnung die FQDN angezeigt, worüber man diese erfährt.
Ist das maschinell übersetzt? Der Satz macht für mich keinen Sinn. Warum sollte man den FQDN nicht erfahren?
Ich glaube, wir stehen hier vor einem klassischen XY Problem. Du willst irgendwas erreichen, von dem du glaubst, Wireguard oder IPv6 könnten dir helfen. Aber das Ergebnis wird nicht zielführend sein.
-
Ist es notwendig, dass mein Internetanbieter IPv6 unterstützt, sodass sich mein Client die IPv6 verwenden kann?
Was genau möchtest du erreichen? Soll der Client eine Verbindung über IPv6 aufbauen können? Oder willst du innerhalb des Tunnels IPv6 nutzen und deinem Client damit eine IPv6 Adresse bereitstellen?
Letzteres geht ohne IPv6 Unterstützung des Providers, aber bei netcup nur mit Klimmzügen (außer man nutzt ein zusätzliches IPv6 Netz).