Docker auf RootServer

Also entweder hast du uns nicht alles verraten, oder die Konfiguration macht so keinen Sinn.

Einige Fragen: Warum macht der Server NAT, und warum wird im Client der ganze Internetverkehr über VPN geleitet, wenn es nur darum geht, Port 81 auf dem Docker zu erreichen? Wofür IPv6 Regeln, wenn es gar keine IPv6 Adressen im Tunnel gibt? Waum ist die Allowed IP im Server 10.8.0.2/32, während die Adresse des Clients 10.8.0.3/32 ist? Es wird nie ein Paket den Client erreichen.

Zitat von h725rk

Damit ich nun den Port 81 über Wireguard erreich kann. Habe ich in der Compose-Datei von NPM die folgende Zeile hinzugefügt

...

Ports:

- '10.8.0.1:81:81'

Das ist gefährlich. Existiert der VPN Tunnel nicht, scheitert der Docker Aufruf. Das ist besonders nach einem Reboot gerne der Fall. Öffne Port 81 einfach nur lokal und erlaube den Zugriff aufs Docker Interface über die Allowed IPs des Tunnels.

Zitat von h725rk

Ich würde die Portfreigabe gerne über ufw steuern. Docker kann gerne die Ports öffnen, aber ich würde die gerne mit, z.B. sudo ufw deny 81/tcp sperren.

Kann mir einer sagen, ob das eine gute Lösung ist oder gibt es eine bessere?

Ja. Öffne den Port gar nicht erst auf dem WAN Interface. Mach eine Weiterleitung, falls nötig. Aber das sollte bei einem Zugriff über den Tunnel nicht nötig sein.

Zitat von h725rk

Ich würde die Portfreigabe gerne über ufw steuern. Docker kann gerne die Ports öffnen, aber ich würde die gerne mit, z.B. sudo ufw deny 81/tcp sperren.

Da kannst du dir mal ufw-docker anschauen:

https://github.com/chaifeng/ufw-docker

Zitat von h725rk

Gute Fragen, kann ich dir wirklich nicht beantworten. Ich habe für wireguard eine Anleitung verwendet.

Deshalb sage ich immer, nie eine Anleitung blind abtippen. Lesen, verstehen, auf die eigene Situation adaptieren, umsetzen.

Zitat von h725rk

Ich denke, ich muss wohl das ganze Konzept nochmal überarbeiten.

Das Konzept ist ok, die Umsetzung ist schlecht. In erster Linie solltest du den VPN Tunnel umbauen.

Du solltest nur die Funktionen aktivieren und nur den Datenverkehr durchs VPN leiten, den du wirklich brauchst. Also wenn es nur um den Zugriff auf Docker geht, dann weg mit den NAT Regeln und der Defaultroute, dafür das Docker Netz in die Allowed IPs aufnehmen.

Ja, aber nur der Server. Der VPN Client soll ja nicht über den Tunnel ins Internet gehen. Was du auf dem Server erreichen kannst, kannst du ja sehr einfach über die Allowed IPs und Firewallregeln beeinflussen.

Du solltest deine Configs vor dem Abspeichern immer auf Konsistenz prüfen. Zum Beispiel sieht man hier auf den ersten Blick, dass die "Address" in der Server Konfig ein Subnetz ist und keine Adresse. Das darf natürlich nicht sein und wird in der Folge auch nicht funktionieren. In der SSH Konfig hast du es hingegen richtig gemacht, womit auch direkt deutlich wird, dass die beiden nicht zusammen passen.

Und dann sind da immer noch NAT Regeln in der Server Konfig und die Default Route im Client. Beides ist Unsinn für deinen Anwendungsfall.

Wenn du SSH auf der öffentlichen Adresse lauschen lässt, solltest du einige Sicherheitsmaßnahmen ergreifen: Anderer Port (nicht 22), keine Anmeldung via Passwort, nur per Zertifikat, und fail2ban sollte sauber laufen. Dann musst du natürlich den Port in der Firewall freigeben.

Zitat von h725rk

- Das mit dem NAT verstehe ich nicht, sind das die PostUp und PostDown Regeln und diese sollte ich löschen?

- Was meinst du mit Default Routes im Client. Sind das die AllowedIPs?

Du administrierst einen vServer, der öffentlich aus dem Netz erreichbar ist. Wenn du das nicht weißt, dann ist das hier:

Zitat von h725rk

Zum Thema SSH.

Das ist abgesichert.

garantiert gelogen. Es nützt nichts, SSH abzusichern, wenn du dann hintenrum wieder haufenweise Lücken einbaust.

Zitat von h725rk

- Das mit dem NAT verstehe ich nicht, sind das die PostUp und PostDown Regeln und diese sollte ich löschen?

Ob du da alles löschen darfst, weiß ich nicht. Die NAT Regeln auf jeden Fall, aber dafür brauchst du vielleicht andere, die jetzt noch nicht drin sind. Anleitung lesen, verstehen, auf die eigene Situation adaptieren, umsetzen.

Zitat von h725rk

- Was meinst du mit Default Routes im Client. Sind das die AllowedIPs?

Momentan steht die Default Route in deinen Allowed IPs. Das sollte für deinen Anwendungsfall aber nicht so sein. Grundlagen IP Routing.

Zitat von h725rk

Ich lasse mich nicht als Lügner bezeichnen, nur weil ich von einer Software (Wireguard) mal keine Ahnung habe und Hilfe benötige.

Wenn du nur von Wireguard keine Ahnung hättest, dann wäre es ja nicht so schlimm. Aber es ist ja offensichtlich, dass du von IP, Routing und Firewalls keine Ahnung hast. Wie willst du dein System schützen, wenn du nicht weißt, welchen Weg die Datenpakete in dein System nehmen? Wie soll das gehen?

Du musst hier nicht antworten. Beantworte dir einfach nur ehrlich diese Frage abends vorm Spiegel, und dann beurteile selber, ob es eine gute Idee ist, einen vServer öffentlich am Netz zu betreiben, oder ob du nicht besser noch einige Monate mit einer VM zu Hause übst.

Ich klinke mich hier ein, da uns in der Moderation eine Beschwerde über den Umgangston erreicht hat.
Während man hier auf der einen Seite direkt ausgedrückte Besorgtheit herauslesen kann, ist nach Prüfung und Abstimmung auch nachvollziehbar, dass sich die Formulierungen teils unfreundlich lesen lassen.

Wir befinden uns hier in einem Online-Forum ohne Tonalität und Mimik, was das Interpretieren vom Geschriebenen oft schwieriger macht, als es in persönlichen Gesprächen bereits der Fall ist.

Das Einzige, das wir hier als allgemeinen Tipp geben können ist: Sollte sich jemand mal im Ton vergreifen zu versuchen nicht vom Schlimmsten auszugehen und weiters, wenn möglich, nur auf den Inhalt, nicht aber auf die (vermeintliche) Tonalität zu reagieren.

In diesem Sinne versucht einander gerne erneut anzunähern. Wenn das nicht gelingt, gibt es für jedes Mitglied im Worst Case auch die Möglichkeit bestimmte andere Mitglieder zu blockieren, um die Nachrichten des anderen nicht mehr angezeigt zu bekommen.

Zitat von h725rk

Vielen Dank, das hat mir geholfen.

Wireguard ist erstmal kein Thema mehr für mich.

Das WireGuard kein Thema mehr für Dich ist, ist schade. WireGuard hat einige Eigenheiten über die man auch stolpern kann wenn man Ahnung von Firewalls, Routing und Co hat. Ich wollte gerne etwas konstruktives beitragen daher:

WireGuard erstellt die Routen anhand der AllowedIPs Einstellung eines Peers, steht dort 0.0.0.0/0 wird alles über das wg-Interface geleitet. Ob die Gegenstelle also in dem Fall der Server das auch akzeptiert steht dort in der [Peer] Konfiguration ebenfalls in den AllowedIPs.

In Deinem Fall wäre wichtig, das in der Interface-Konfiguration immer eine IP und kein Subnet stehen sollte wie frank_m zuvor bereits geschrieben hat.

Hat dein Server in der Interfacekonfiguration z.B. die IP 10.8.0.1/24 eingetragen und dein Client die 10.8.0.2/24, könnte in den AllowedIPs des Clients die 10.8.0.0/24 stehen sodass der Traffic für dieses Subnet über den Tunnel geleitet wird. In der [Peer] Konfiguration des Servers könnte dann als AllowedIP die 10.8.0.2/32 stehen. Somit kann dein Client den Server und ggf. andere Peers im selben Subnet erreichen.

PS: Ich finde der Lernaufwand für WireGuard lohnt sich, das Cryptokey-Routing ist faszinierend und ich hoffe das funktioniert so für Dich!

PPS (Edit): Ich hatte irgendwann mal mit dieser Anleitung begonnen, die fand ich ganz hilfreich am Anfang.