FRITZ!Box-VPN verbindet, aber niemand antwortet: WireGuard oder IPSec
Ein verbundener FRITZ!Box-Tunnel, der das LAN nicht erreicht, ist ein Adressierungsproblem. Prüfen Sie die vier IPSec-Felder oder den WireGuard-Peer, bevor Sie erneut importieren.
Der Tunnel meldet verbunden, das Symbol ist grün, und nichts im Heim-LAN antwortet. Das ist die häufigste Beschwerde zum Fernzugriff der FRITZ!Box, und fast nie ist der Tunnel selbst schuld. Der Adressplan, die Identität des Subnetzes oder die Routing-Tabelle des Clients stimmt nicht. Was davon Sie am Ende debuggen, hängt davon ab, ob Sie WireGuard oder den älteren IPSec Fernzugang gewählt haben, also beginnen Sie damit zu wissen, was Sie tatsächlich eingerichtet haben.
Der Tunnel kommt hoch, und das LAN bleibt stumm
Ein Tunnel, der zustande kommt, beweist, dass die Schlüssel und der Endpunkt richtig sind. Er beweist nicht, dass der Client eine Adresse bekommen hat, zu der die Box routen kann, oder dass der Client weiß, welche Präfixe zum Tunnel gehören. Das sind zwei getrennte Erfolge, und nur der zweite lässt Sie einen Drucker erreichen.
Prüfen Sie zuerst die Adresse des Clients, dann seine Routing-Tabelle.
Liegt die zugewiesene Adresse außerhalb des LAN-Subnetzes, hat die Box nichts, wohin sie zurückrouten kann. Liegt sie innerhalb des DHCP-Bereichs, kann die Box dieselbe Adresse an ein lokales Gerät vergeben. Beides ergibt einen Tunnel, der verbindet, und ein LAN, das Sie ignoriert.
Was die einzelnen Optionen tatsächlich konfigurieren
Die IPSec-Option erzeugt eine Konfigurationsdatei für einen Benutzer, die den vorab geteilten Schlüssel und die Adressierung enthält. Sie importieren sie in einen Client, der dasselbe Profil spricht, was unter Windows meist das Werkzeug des Herstellers bedeutet und nicht den eingebauten Client. Die WireGuard-Option erzeugt einen Peer für ein Gerät: ein Schlüsselpaar, eine Adresse im Tunnel und einen Endpunkt.
Dieser Unterschied entscheidet über Ihr Wartungsmodell. Jedes WireGuard-Gerät ist ein eigener Peer mit eigenem Schlüssel, ein verlorenes Telefon zu sperren bedeutet also, einen Peer zu löschen, während die anderen weiterarbeiten. IPSec sperrt über eine Änderung des gemeinsamen Geheimnisses oder der Benutzerkonfiguration, was gröber ist und jedes Gerät trifft, das sie nutzt.
Keine der Optionen ist veraltet. Der IPSec-Weg bleibt der unterstützte, wo die Gegenseite WireGuard nicht ausführen kann.
Die IPSec-Felder, die einen toten Tunnel erzeugen
Vier Werte müssen zu Ihrem LAN passen, und drei davon scheitern so, dass es wie ein kaputter Tunnel aussieht.
| Value | What breaks when it is wrong |
|---|---|
| LAN subnet | The client routes nothing, or routes the wrong prefix |
| Network address | The configuration looks valid and the tunnel never establishes |
| DHCP range | No address is left to assign to tunnel clients |
| DNS server | The tunnel works and name resolution does not |
Die Netzwerkadresse ist die, die Leute erwischt. Ein Subnetz wird durch seine erste Adresse gekennzeichnet, die normalerweise auf null endet, und dort eine Hostadresse einzutragen erzeugt eine Konfiguration, die völlig plausibel aussieht und nie verbindet. Der DHCP-Bereich ist aus einem anderen Grund wichtig: Tunnelclients werden typischerweise oberhalb davon zugewiesen, ein Bereich, der das ganze Subnetz verbraucht, lässt also nichts zum Verteilen übrig.
Überlappende Subnetze sind der andere Klassiker. Nutzt das entfernte LAN, dem Sie beitreten, dasselbe Präfix wie das LAN, auf dem Sie sitzen, kann das Routing die beiden nicht unterscheiden, und nur eine Seite neu zu nummerieren ist die einzig echte Lösung. Keine Menge Clientkonfiguration löst das.
Warum WireGuard anders scheitert
WireGuard hat keinen vorab geteilten Schlüssel, den man vertippen könnte, deshalb gruppieren sich seine Fehler stattdessen um die Peer-Definition. Eine Liste erlaubter IPs, die das LAN-Präfix auslässt, ergibt einen Tunnel, der nichts befördert, weil der Client nie Verkehr ins LAN hineinschickt. Ein veralteter öffentlicher Schlüssel auf einer der Seiten ergibt einen Handshake, der nie fertig wird. Ein fehlender Endpunkt oder ein falscher Port ergibt Schweigen statt eines Fehlers.
Vergleichen Sie beide Seiten Feld für Feld, statt die Datei erneut zu importieren und zu hoffen.
Der eine gemeinsame Fehler ist die Subnetz-Kollision. WireGuard baut ohne Weiteres einen Tunnel zu einem Netz, das sich mit Ihrem lokalen überschneidet, und dann entscheidet die Routing-Tabelle, welches der beiden identischen Präfixe gewinnt.
Beweisen Sie es von außen und halten Sie dann einen Weg zurück offen
Testen Sie aus einer Mobilfunkverbindung, nie von innerhalb des LANs, denn von innen testen Sie einen Weg, der den Tunnel überhaupt nicht berührt. Notieren Sie, welchen Port die jeweilige Option nutzt, bevor Sie sie aktivieren, und leiten Sie diesen Port auf die Box.
Bewahren Sie die erzeugte Datei dort auf, wo Sie ohne den Tunnel hinkommen, und notieren Sie gleich den externen Namen der Box.
Eine Konfiguration, die nie von außen getestet wurde, ist ein Plan und kein funktionierender Fernzugriffsweg. Testen Sie einen LAN-Host über die Adresse statt über den Namen, damit ein DNS-Fehler nicht für einen Routingfehler gehalten wird.