Il VPN della FRITZ!Box si connette ma nulla risponde: WireGuard o IPSec
Un tunnel FRITZ!Box connesso che non raggiunge la LAN è un problema di indirizzamento. Controllate i quattro campi IPSec o il peer WireGuard prima di reimportare.
Il tunnel segnala connesso, l’icona è verde e nulla sulla LAN di casa risponde. È la lamentela più comune sull’accesso remoto della FRITZ!Box e quasi mai è il tunnel stesso. Lo schema degli indirizzi, l’identità della sottorete o la tabella di routing del client sono sbagliati. Quale di questi finirete per depurare dipende dalla scelta tra WireGuard e il più vecchio IPSec Fernzugang, quindi iniziate sapendo cosa avete configurato davvero.
Il tunnel sale e la LAN resta muta
Un tunnel che si stabilisce dimostra che le chiavi e l’endpoint sono corretti. Non dimostra che il client abbia ricevuto un indirizzo verso cui il box può instradare, né che il client sappia quali prefissi appartengono al tunnel. Sono due successi distinti, e solo il secondo vi permette di raggiungere una stampante.
Controllate prima l’indirizzo del client, poi la sua tabella di routing.
Se l’indirizzo assegnato sta fuori dalla sottorete della LAN, il box non ha nulla verso cui instradare al ritorno. Se sta dentro l’intervallo DHCP, il box può assegnare lo stesso indirizzo a un dispositivo locale. Entrambe le cose producono un tunnel che si connette e una LAN che vi ignora.
Che cosa configura davvero ogni opzione
L’opzione IPSec genera un file di configurazione per un utente, contenente la chiave precondivisa e l’indirizzamento. Lo importate in un client che parla lo stesso profilo, cosa che su Windows di solito significa lo strumento del fornitore e non il client integrato. L’opzione WireGuard genera un peer per un dispositivo: una coppia di chiavi, un indirizzo dentro il tunnel e un endpoint.
Questa differenza decide il vostro modello di manutenzione. Ogni dispositivo WireGuard è un peer separato con la propria chiave, quindi revocare un telefono perso significa cancellare un peer mentre gli altri continuano a funzionare. IPSec revoca cambiando il segreto condiviso o la configurazione dell’utente, il che è più grossolano e colpisce ogni dispositivo che lo usa.
Nessuna delle due opzioni è obsoleta. Il percorso IPSec resta quello supportato ovunque l’estremità remota non possa eseguire WireGuard.
I campi IPSec che producono un tunnel morto
Quattro valori devono concordare con la vostra LAN, e tre di essi falliscono in modi che sembrano un tunnel rotto.
| 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 |
L’indirizzo di rete è quello che frega le persone. Una sottorete è identificata dal suo primo indirizzo, che di solito termina con zero, e inserirvi un indirizzo host produce una configurazione che sembra del tutto plausibile e non si connette mai. L’intervallo DHCP conta per un altro motivo: i client del tunnel vengono di norma assegnati sopra di esso, quindi un intervallo che consuma tutta la sottorete non lascia nulla da distribuire.
Le sottoreti sovrapposte sono l’altro caso classico. Se la LAN remota a cui vi unite usa lo stesso prefisso della LAN su cui siete seduti, il routing non riesce a distinguerle, e rinumerare uno dei due lati è l’unica correzione reale. Nessuna quantità di configurazione del client lo risolve.
Perché WireGuard fallisce in modo diverso
WireGuard non ha una chiave precondivisa da digitare male, quindi i suoi guasti si concentrano attorno alla definizione del peer. Un elenco di IP consentiti che omette il prefisso della LAN produce un tunnel che non trasporta nulla, perché il client non vi invia mai traffico diretto alla LAN. Una chiave pubblica vecchia su uno dei due lati produce una stretta di mano che non si completa mai. Un endpoint mancante o una porta sbagliata producono silenzio invece di un errore.
Confrontate i due lati campo per campo invece di reimportare il file e sperare.
L’unico guasto condiviso è la collisione di sottoreti. WireGuard costruirà volentieri un tunnel verso una rete che si sovrappone alla vostra, e poi la tabella di routing decide quale dei due prefissi identici vince.
Dimostratelo dall’esterno, poi tenetevi una via di ritorno
Provate da una connessione mobile, mai da dentro la LAN, perché da dentro state provando un percorso che non coinvolge affatto il tunnel. Annotate quale porta usa ogni opzione prima di attivarla, e inoltrate quella porta al box.
Conservate il file generato in un posto raggiungibile senza il tunnel, e intanto annotate il nome esterno del box.
Una configurazione mai provata dall’esterno è un piano, non un percorso di accesso remoto funzionante. Provate un host della LAN per indirizzo anziché per nome, così un guasto DNS non venga scambiato per un guasto di routing.