Du machst gar nichts falsch. Das ist so. Wurde auch schon mehrfach hier im Forum diskutiert.
Einer der Gründe, so schnell wie möglich zu einer funktionierenden SSH-Verbindung zu kommen.
Posts by frank_m
-
-
danke für deine Antwort. Beachte meinen ersten Beitrag in diesem Thread. Mein Hauptziel ist es ja mit dem Smartphone von unterwegs unabhänig von IPv6 und IPv4 auf das Netzwerk zu Hause zugreifen zu können. Also genau das "Road Warrior Client" Szenario.
Ja, wie gesagt, kein Problem. Halte dich für die Verbindung zwischen VPS und Fritzbox an die AVM Anleitung. Die sieht ja bereits ein lokales Netz für den Router der anderen Seite vor, dass ist in deinem Fall das Netz der Roadwarrior Clients. Für eine zweite Fritzbox fügst du einfach deren Netz als Allowed IP hinzu. Die Clients kannst du gemäß jeder gängigen Wireguard-Anleitung konfigurieren. Bedenke dabei auch die Allowed IPs aus dem Fritzbox Netz. Das wars schon.
-
Der Ton gefällt mir nicht, ich bin deshalb hier raus.
Wenn du meinst, bitte. Ich will nur verhindern, dass sich über solche Threads wieder irgendwelche Mythen im Internet festsetzen, die technisch einfach nur hanebüchen sind. Am Ende lesen es andere und glauben es vielleicht auch noch.
Denn es gibt bei Wireguard auf technischer Ebene keine Zuordnung von Server oder Client, Initiator oder Responder. Diese Rollen können nur durch externe Einflüsse festgelegt werden, und nicht durch die Wireguard-Technologie an sich. Und das bedeutet auch, sie haben keinerlei Einfluss auf die grundlegende Konfiguration, z.B. bei den IP-Adressen. Das Einzige, was eine wichtig werden könnte, sind die keep-alive Pakete, die nötig werden, damit ein Client hinter einem NAT Router erreichbar bleibt.
Ich müsste dann die IP-Adresse des Wireguard Transfernetzes auf das IP-Band der Fritz!Box (192.168.0.xxx) ändern, oder?
Du brauchst gar kein Transfernetz bei einer LAN-2-LAN Verbindung. Das bräuchtest du erst, wenn Road Warrior Clients hinzukommen. Und dann auch nur für die, in den Fritzbox taucht es dann nur als allowed IP auf.
Dann frage ich mich, wie das funktionieren soll, wenn ich wirklich eine zweite Fritz!Box reinhängen möchte.
Genauso. Wie gesagt: LAN-2-LAN Verbindungen brauchen kein Transfernetz.
Wenn die Fritzbox das Laden einer korrekten VPN-Konfig verweigert, dann gibt es häufig einen Konflikt mit einer anderen existierenden VPN-Konfiguration. Ggf. hilft es, alle (!) existierenden VPN Konfigurationen für Wireguard und IPSec zu löschen. Reicht das nicht, muss man einen Reset auf Werkseinstellungen durchführen.
-
Sollte das nicht dauerhaft stabil sein, dann würde ich zuerst das hier überprüfen:
Source Port(s): <Port-Wireguard>
Wie gesagt, nur weil eine App einen Port eingehend öffnet, bedeutet das nicht, dass sie auch ausgehend alles darauf sendet.
-
Icb kenne die netcup Firewall noch nicht so genau, aber meines Erachtens sind in den Regeln mehrere Dinge falsch.
Inbound:
Destination(s) (IPs / Netzwerke): *
Hier sollte eine konkrete Zieladresse stehen. Auch wenn man Netzwerke angeben kann: Der Server lauscht ja nur auf einer IP, oder?
Outbound:
Source(s) (IPs / Netzwerke): 64831
Das ist Unsinn: eine Portnummer bei der IP-Adresse. Hier sollte wieder die konkrete Adresse des Servers rein.
Source Port(s): *
Bevor du auf die Idee kommst, hier den offenen UDP-Port von Wireguard einzutragen: Nur weil der Port eingehend offen ist, heißt das noch lange nicht, dass auch die ausgehenden Pakete von diesem Port kommen. Von daher ist "*" vermutlich richtig.
-
Um es noch einmal sehr deutlich zu sagen: Technisch gibt es bei Wireguard weder Server noch Client, weder Initiator noch Responder. Die Rollen sind NICHT fest verteilt, jede Seite kann bei Bedarf jede Rolle übernehmen. Natürlich könnt ihr durch euer Setup Konstellationen erzeugen, dass es einen zentralen Knoten gibt, der alle Clients (Netze und Road-Warrior) miteinander verbindet. Es ist auch denkbar, dass es eine Seite das erste Paket senden MUSS, weil die Gegenseite die Adresse nicht kennt.
Das ist aber eher ein Problem, als ein Feature, denn bedenkt: Das betrifft nicht nur den initialen Verbindungs-Aufbau, sondern auch laufende Verbindungen. Der zustandslose Charakter der Wireguard Verbindung kann nach verhältnismäßig kurzer Zeit dazu führen, dass ein mobiles Endgerät den Tunnel zum "Server" verliert, besonders, wenn das mobile Endgerät wirklich mobil ist (spätestens, wenn sich die abgehende IP-Adresse im NAT ändert). Solche Dinge muss man beim Design eines Wireguard Netzes auf dem Schirm haben. Und da macht es wenig Sinn, in den althergebrachten Rollen von Server zu Client zu denken, wenn die reale Technologie diese Rollen so nicht abbildet.
-
Das stimmt so nicht ganz: Es gibt zwar nicht den klassischen Server und Client, aber einen Initiator.
Nein. Wenn eine Seite ein Paket für die andere Seite hat, schickt sie es rüber. Dabei ist egal, was vorher war, wann das letzte Paket geschickt wurde, usw. Ggf. muss dann noch ein Schlüsselaustausch gemacht werden, wenn die letzten Schlüssen abgelaufen sind.
Wenn aufgrund von NAT oder ähnlichen Mechanismen eine Seite der Verbindung nicht erreichbar ist, dann hat man das Problem, dass die Gegenseite kein Paket schicken kann, bevor sie nicht vom NAT-Partner ein Paket empfangen hat. Dafür gibt es dann auch die Keep-Alive Pakete. Aber das ist unabhängig vom Verbindungsstatus, Server oder Client Rollen.
Ein weiteres Problem sind sich ändernde IP-Adressen während einer laufenden Verbindung. Wireguard aktualisiert nämlich keine Adressen von Kommunikationspartnern zur Laufzeit. Da muss man mit externen Scripten nachhelfen, wenn man das Problem hat.
-
Naja, es kommt darauf an wer den Verbindungsaufbau initialisieren soll.
Zum einen: Bei wireguard initiiert niemand den Verbindungsaufbau. Es gibt in dem Sinne keinen Client und keinen Server, sondern eine Punkt-zu-Punkt-Verbindung zweier gleichberechtigter Partner, die sich zustandslos UDP Pakete zuschicken.
Zum Anderen: Für die IP Einstellung ist es vollkommen egal, wer die Verbindung initiiert. Damit das Routing arbeitet, müssen die in jedem Fall stimmen, sonst fließen gar keine Pakete, weder in die eine, noch in die andere Richtung.
-
Edit: Die Fritz!Box verweigert das Laden des Konfigfiles wenn in der Interface Section irgendeine IP-Adresse aus ihrem Adressbereich angegeben ist.
Die Konfig mit der IP der Fritzbox muss ja auch nicht in die Fritzbox, sondern in den anderen Router (also den VPS).
-
Um noch kurz auf die ursprüngliche Frage zu antworten, falls du doch Wireguard auf dem VPS betreiben willst (das könnte spätestens dann interessant werden, wenn es ein zweites Heimnetz gibt, dass integriert werden soll, oder wenn du mehrere Roadwarrior Clients einbinden willst):
Du hast die Hinweise in der AVM Doku nicht beachtet. AVM nutzt kein Transfernetz und routet dann auf die Heimnetz Clients. D.h., die die Fritzbox hat keine 10.8.x.y Adresse, sondern die Wireguard-Konfiguration muss um die Heimnetz-Adresse der Fritzbox herumgestrickt werden. Siehe in dieser Anleitung den Hinweis mit dem blauen Dreieck in Kapitel 2:
Generell ist das die Anleitung, der du beim Einrichten deines Setups folgen solltest. Dann klappt’s auch mit dem Zugriff aufs Heimnetz.
-
Wie lange ist es her, dass du Domains und DNS Einträge vorgenommen hast? Vielleicht haben sie sich weltweit noch nicht herumgesprochen? Das dauert durchaus auch mal länger, als in der TTL angegeben.
-
Dafür müsste man wissen, was das für ein VPN ist und wie es arbeitet. Bei dem VPN scheint einiges krude zu sein, vor allem die DNS Funktionalität.
Die Fehlermeldungen lassen darauf schließen, dass bei der DNS Auflösung was schief geht und am Ende ein Standard-Plesk Zertifikat ausgeliefert wird. Wenn der Zugriff ohne VPN problemlos funktioniert, dann scheint da beim VPN einiges im Argen zu liegen.
-
Ich könnte mir vorstellen, dass die dedizierte Routing Adresse aus dem Zielsubnetz auf einem Interface außerhalb des eigentlichen docker Adapters Ärger macht. Das Gateway muss ja nicht aus dem Zielsubnetz sein, ich würde da die link-lokale Adresse des Docker Bridge Devices auf dem Host nehmen.
-
Ist das nicht eher das Problem von Docker im Zusammenhang mit LXC und apparmor? Das wird ja seit einigen Tagen in den Debian/Ubuntu Foren diskutiert.
-
Wir brauchen die Übersicht der Wireguard Konfiguration, der IP- und Routenkonfiguration des Servers und der Firewall-Regeln, ganz wichtig, inkl. der Forwarding und NAT Regeln. Am besten von Debian 12 und 13.
-
IPv6 Adressen müssen händisch konfiguriert werden, DHCPv6 oder RAs gibt es nicht.
-
Und die zusätzlichen Netze hast du schon getestet? Die werden nämlich nicht auf die ::1 geroutet.
-
Ich habe das Subnetz auf /64 korrigiert, und jetzt funktioniert alles!
Das ist immer noch falsch. Du hast 2a03:4000::/64 auf deinen Systemen ja nicht in Benutzung. Damit wirst du Systeme aus diesem konkreten Prefix nicht erreichen. Die Route muss komplett weg, und die Prefix-Länge der Adresse muss auf /64 geändert werden.
Daneben sieht man die EUI-64 Adresse nicht, die fürs Routing der zusätzlichen Subnetze erforderlich ist. Wenn du sie nicht weg-editiert hast, musst du noch mal ran an die Konfiguration.
-
Ich stelle gerade fest, dass der Server a noch eine Route zusätzliche eingetragen hat: 2a03:4000::/32 dev eth0 proto kernel metric 256 pref medium, aber da eh alles über eth0 geroutet wird, sollte das keinen Unterschied machen, oder?
Doch, natürlich, genau die ist das Problem. Damit sucht dein Server die Pakete aus den anderen Prefixes dieses Netzes im LAN, also über NDP und Schicht 2. Das wird für die meisten dieser Prefixes nicht funktionieren. Exakt sowas hab ich erwartet, deshalb die Frage nach den Prefix Längen der Routen.
Hmm, ne, das sollten verschiedene Prefixe sein, oder nicht?
Das /32 ist für alle das Gleiche. Und genau das ist in diesem Fall das Problem.
-
Das Problem ist: Die beiden Server erreichen sich gegenseitig nicht über IPv6.
Zeig das doch mal anhand von Traces auf die jeweiligen Adressen beim Zugriff von außen und beim Zugriff zwischen den VServern.
Kommen die Adressen der beiden Server aus dem gleichen Prefix? Passen die Prefix-Längen der Routen auf deinen Servern? Du schreibst von mehreren Subnetzen. Das Routing dieser zusätzlichen Netze auf die Standard-EUI-64 Adresse des Servers funktioniert einwandfrei?
