A VPN da FRITZ!Box conecta pero nada responde: WireGuard ou IPSec
Un túnel FRITZ!Box conectado que non chega á LAN é un problema de direccionamento. Revise os catro campos IPSec ou o peer de WireGuard antes de volver importar.
O túnel di que está conectado, a icona está verde e nada da LAN da casa responde. É a queixa máis habitual do acceso remoto da FRITZ!Box e case nunca é o propio túnel. O plan de enderezos, a identidade da subrede ou a táboa de rutas do cliente están mal. Cal deles acabe depurando depende de se escolleu WireGuard ou o antigo IPSec Fernzugang, así que comece sabendo cal configurou de verdade.
O túnel érguese e a LAN queda en silencio
Un túnel que se establece demostra que as claves e o punto final son correctos. Non demostra que o cliente recibise un enderezo ao que a caixa poida encamiñar, nin que o cliente saiba que prefixos pertencen ao túnel. Son dous éxitos distintos, e só o segundo lle permite chegar a unha impresora.
Comprobe primeiro o enderezo do cliente e despois a súa táboa de rutas.
Se o enderezo asignado queda fóra da subrede da LAN, a caixa non ten a onde encamiñar de volta. Se queda dentro do rango DHCP, a caixa pode entregar o mesmo enderezo a un dispositivo local. Ámbalas dúas cousas producen un túnel que conecta e unha LAN que o ignora.
Que configura realmente cada opción
A opción IPSec xera un ficheiro de configuración para un usuario, coa clave precompartida e o direccionamento. Impórtao nun cliente que fale o mesmo perfil, o que en Windows adoita significar a ferramenta do fabricante e non o cliente integrado. A opción WireGuard xera un peer para un dispositivo: un par de claves, un enderezo dentro do túnel e un punto final.
Esa diferenza decide o seu modelo de mantemento. Cada dispositivo WireGuard é un peer aparte coa súa propia clave, así que revogar un móbil perdido significa borrar un peer mentres os demais seguen funcionando. IPSec revoga cambiando o segredo compartido ou a configuración do usuario, algo máis groso que afecta a todos os dispositivos que o usan.
Ningunha das dúas opcións está obsoleta. A ruta IPSec segue sendo a admitida onde o extremo remoto non pode executar WireGuard.
Os campos de IPSec que producen un túnel morto
Catro valores teñen que concordar coa súa LAN, e tres deles fallan dun xeito que parece un túnel roto.
| 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 |
O enderezo de rede é o que atrapa a xente. Unha subrede identifícase polo seu primeiro enderezo, que normalmente remata en cero, e introducir alí un enderezo de host produce unha configuración que parece totalmente plausible e nunca conecta. O rango DHCP importa por outro motivo: os clientes do túnel adoitan asignarse por riba del, así que un rango que consome toda a subrede non deixa nada que repartir.
As subredes solapadas son o outro caso clásico. Se a LAN remota á que se une usa o mesmo prefixo que a LAN na que está sentado, o encamiñamento non pode distinguilas, e renumerar un dos dous lados é a única solución real. Ningunha cantidade de configuración do cliente o resolve.
Por que WireGuard falla doutro xeito
WireGuard non ten clave precompartida que escribir mal, así que os seus fallos agrúpanse arredor da definición do peer. Unha lista de IP permitidas que omite o prefixo da LAN produce un túnel que non transporta nada, porque o cliente nunca lle envía tráfico destinado á LAN. Unha clave pública antiga en calquera dos dous lados produce un saúdo que nunca se completa. Un punto final ausente ou un porto equivocado producen silencio en lugar dun erro.
Compare os dous lados campo por campo en vez de volver importar o ficheiro e confiar.
O único fallo compartido é a colisión de subredes. WireGuard construirá encantado un túnel cara a unha rede que se solape coa súa, e logo a táboa de rutas decide cal dos dous prefixos idénticos gaña.
Demóstreo desde fóra e despois garde unha vía de volta
Probe desde unha conexión móbil, nunca desde dentro da LAN, porque desde dentro está probando un camiño que non implica o túnel en absoluto. Anote que porto usa cada opción antes de activala e redirixa ese porto á caixa.
Garde o ficheiro xerado nun sitio ao que poida chegar sen o túnel, e de paso anote o nome externo da caixa.
Unha configuración que nunca se probou desde fóra é un plan, non unha vía de acceso remoto que funcione. Probe un equipo da LAN por enderezo e non por nome, para que un fallo de DNS non se confunda cun fallo de encamiñamento.