FRITZ!Box-VPN verbindt maar niets antwoordt: WireGuard of IPSec
Een verbonden FRITZ!Box-tunnel die het LAN niet bereikt, is een adresseringsprobleem. Controleer de vier IPSec-velden of de WireGuard-peer voordat u opnieuw importeert.
De tunnel meldt verbonden, het pictogram is groen, en niets op het thuis-LAN antwoordt. Dat is de meest voorkomende klacht over FRITZ!Box-toegang op afstand, en het is bijna nooit de tunnel zelf. Het adresplan, de identiteit van het subnet of de routetabel van de client klopt niet. Welke daarvan u uiteindelijk debugt, hangt af van of u WireGuard of de oudere IPSec Fernzugang hebt gekozen, dus begin met te weten welke u werkelijk hebt geconfigureerd.
De tunnel komt op en het LAN blijft stil
Een tunnel die tot stand komt, bewijst dat de sleutels en het eindpunt kloppen. Hij bewijst niet dat de client een adres heeft gekregen waar de box naartoe kan routeren, of dat de client weet welke prefixen bij de tunnel horen. Dat zijn twee aparte successen, en alleen het tweede laat u een printer bereiken.
Controleer eerst het adres van de client, dan zijn routetabel.
Als het toegewezen adres buiten het LAN-subnet ligt, heeft de box niets om naar terug te routeren. Als het binnen het DHCP-bereik ligt, kan de box hetzelfde adres aan een lokaal apparaat geven. Beide leveren een tunnel die verbindt en een LAN dat u negeert.
Wat elke optie werkelijk configureert
De IPSec-optie genereert een configuratiebestand voor één gebruiker, met de vooraf gedeelde sleutel en de adressering. U importeert het in een client die hetzelfde profiel spreekt, wat op Windows meestal het hulpmiddel van de fabrikant betekent en niet de ingebouwde client. De WireGuard-optie genereert een peer voor één apparaat: een sleutelpaar, een adres in de tunnel en een eindpunt.
Dat verschil bepaalt uw onderhoudsmodel. Elk WireGuard-apparaat is een aparte peer met een eigen sleutel, dus een verloren telefoon intrekken betekent één peer verwijderen terwijl de andere blijven werken. IPSec trekt in door het gedeelde geheim of de configuratie van de gebruiker te wijzigen, wat grover is en elk apparaat raakt dat het gebruikt.
Geen van beide opties is verouderd. Het IPSec-pad blijft het ondersteunde pad waar de andere kant WireGuard niet kan draaien.
De IPSec-velden die een dode tunnel opleveren
Vier waarden moeten overeenkomen met uw LAN, en drie ervan falen op een manier die op een kapotte tunnel lijkt.
| 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 |
Het netwerkadres is degene die mensen vangt. Een subnet wordt geïdentificeerd door het eerste adres, dat meestal op nul eindigt, en een hostadres daar invoeren levert een configuratie op die volstrekt plausibel lijkt en nooit verbindt. Het DHCP-bereik is om een andere reden belangrijk: tunnelclients krijgen meestal een adres boven dat bereik, dus een bereik dat het hele subnet opeet, laat niets over om uit te delen.
Overlappende subnets zijn het andere klassieke geval. Als het externe LAN waar u bij aansluit hetzelfde prefix gebruikt als het LAN waarop u zit, kan routing de twee niet onderscheiden, en alleen één kant opnieuw nummeren is de enige echte oplossing. Geen enkele hoeveelheid clientconfiguratie lost dat op.
Waarom WireGuard anders faalt
WireGuard heeft geen vooraf gedeelde sleutel om verkeerd te typen, dus de fouten groeperen zich rond de peer-definitie. Een lijst met toegestane IP’s waarin het LAN-prefix ontbreekt, levert een tunnel op die niets vervoert, omdat de client nooit verkeer richting het LAN erin stuurt. Een verouderde openbare sleutel aan een van beide kanten levert een handdruk op die nooit voltooid wordt. Een ontbrekend eindpunt of een verkeerde poort levert stilte in plaats van een fout.
Vergelijk beide kanten veld voor veld in plaats van het bestand opnieuw te importeren en te hopen.
De enige gemeenschappelijke fout is de subnetbotsing. WireGuard bouwt met plezier een tunnel naar een netwerk dat uw lokale netwerk overlapt, en dan beslist de routetabel welk van de twee identieke prefixen wint.
Bewijs het van buitenaf en houd dan een weg terug open
Test vanaf een mobiele verbinding, nooit van binnenuit het LAN, want van binnenuit test u een pad waar de tunnel helemaal niet aan te pas komt. Noteer welke poort elke optie gebruikt voordat u die activeert, en stuur die poort door naar de box.
Bewaar het gegenereerde bestand ergens waar u zonder de tunnel komt, en noteer meteen de externe naam van de box.
Een configuratie die nooit van buitenaf is getest, is een plan en geen werkend pad voor toegang op afstand. Test één LAN-host op adres in plaats van op naam, zodat een DNS-fout niet voor een routingfout wordt aangezien.