FRITZ!Box VPN forbinder, men intet svarer: WireGuard eller IPSec
En forbundet FRITZ!Box-tunnel, der ikke kan nå LAN’et, er et adresseringsproblem. Kontroller de fire IPSec-felter eller WireGuard-peeren, før du importerer igen.
Tunnelen melder forbundet, ikonet er grønt, og intet på hjemmets LAN svarer. Det er den mest almindelige klage over FRITZ!Box-fjernadgang, og det er næsten aldrig tunnelen selv. Adresseplanen, subnetidentiteten eller klientens rutetabel er forkert. Hvilken af dem du ender med at fejlfinde, afhænger af, om du valgte WireGuard eller den ældre IPSec Fernzugang, så begynd med at vide, hvilken du faktisk konfigurerede.
Tunnelen kommer op, og LAN’et forbliver tavst
En tunnel, der etableres, beviser, at nøglerne og endepunktet er rigtige. Det beviser ikke, at klienten har fået en adresse, som boksen kan route til, eller at klienten ved, hvilke præfikser der hører på tunnelen. Det er to separate succeser, og kun den anden lader dig nå en printer.
Kontroller klientens adresse først, derefter dens rutetabel.
Hvis den tildelte adresse ligger uden for LAN-subnettet, har boksen intet at route tilbage til. Hvis den ligger inden for DHCP-området, kan boksen give den samme adresse til en lokal enhed. Begge dele giver en tunnel, der forbinder, og et LAN, der ignorerer dig.
Hvad hver mulighed egentlig konfigurerer
IPSec-muligheden genererer en konfigurationsfil til én bruger med den foruddelte nøgle og adresseringen. Du importerer den i en klient, der taler samme profil, hvilket på Windows normalt betyder producentens værktøj og ikke den indbyggede klient. WireGuard-muligheden genererer en peer til én enhed: et nøglepar, en adresse inde i tunnelen og et endepunkt.
Den forskel afgør din vedligeholdelsesmodel. Hver WireGuard-enhed er en separat peer med sin egen nøgle, så tilbagekaldelse af en mistet telefon betyder at slette én peer, mens de andre fortsætter med at virke. IPSec tilbagekalder ved at ændre den delte hemmelighed eller brugerens konfiguration, hvilket er grovere og rammer enhver enhed, der bruger den.
Ingen af mulighederne er forældede. IPSec-vejen forbliver den understøttede, hvor den fjerne ende ikke kan køre WireGuard.
De IPSec-felter, der giver en død tunnel
Fire værdier skal stemme med dit LAN, og tre af dem fejler på måder, der ligner en brudt tunnel.
| 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 |
Netværksadressen er den, der fanger folk. Et subnet identificeres ved sin første adresse, som normalt ender på nul, og at indtaste en værtsadresse der giver en konfiguration, der ser helt plausibel ud og aldrig forbinder. DHCP-området betyder noget af en anden grund: tunnelklienter tildeles typisk oven over det, så et område, der spiser hele subnettet, efterlader intet at uddele.
Overlappende subnets er den anden klassiker. Hvis det fjern-LAN, du tilslutter dig, bruger samme præfiks som det LAN, du sidder på, kan routing ikke skelne dem, og omnummerering af den ene side er den eneste rigtige løsning. Ingen mængde klientkonfiguration løser det.
Hvorfor WireGuard fejler anderledes
WireGuard har ingen forudelt nøgle at skrive forkert, så fejlene klumper sig i stedet omkring peer-definitionen. En liste over tilladte IP’er, der udelader LAN-præfikset, giver en tunnel, der ikke bærer noget, fordi klienten aldrig sender LAN-rettet trafik ind i den. En forældet offentlig nøgle på en af siderne giver et håndtryk, der aldrig fuldføres. Et manglende endepunkt eller en forkert port giver tavshed i stedet for en fejl.
Sammenlign begge sider felt for felt i stedet for at importere filen igen og håbe.
Den ene fælles fejl er subnet-kollisionen. WireGuard bygger gerne en tunnel til et netværk, der overlapper dit lokale, og så afgør rutetabellen, hvilket af de to identiske præfikser der vinder.
Bevis det udefra, og hold så en vej tilbage ind
Test fra en mobilforbindelse, aldrig indefra LAN’et, for indefra tester du en vej, der slet ikke involverer tunnelen. Noter, hvilken port hver mulighed bruger, før du aktiverer den, og videresend den port til boksen.
Gem den genererede fil et sted, du kan nå uden tunnelen, og noter boksens eksterne navn, mens du er i gang.
En konfiguration, der aldrig er testet udefra, er en plan og ikke en fungerende fjernadgangsvej. Test én LAN-vært på adresse i stedet for på navn, så en DNS-fejl ikke forveksles med en routingfejl.