Interruttore di emergenza o accesso alla LAN? Due risposte per WireGuard

La stretta di mano si completa, la navigazione funziona, e la stampante, il NAS e gli host SSH locali svaniscono. Nel client Windows di solito non è affatto un guasto di routing: un peer i cui prefissi consentiti includono il valore predefinito letterale attiva Blocca il traffico non incanalato nel tunnel, e quell’opzione è implementata come regole del firewall che scartano i pacchetti in uscita da qualsiasi altra interfaccia. La tabella di routing elenca ancora la sottorete locale come collegamento diretto, ed è per questo che il sintomo sembra una bugia. Tre condizioni decidono cosa fare al riguardo, e solo una riguarda il routing.

Due guasti portano lo stesso sintomo

Il primo guasto è la modalità di chiusura sicura del client, e la sua firma è che tutto ciò che sta fuori dal tunnel si ferma mentre il tunnel stesso funziona perfettamente. Il secondo è un vero problema di raggiungibilità: una rotta mancante, una voce mancante sul server per una sottorete dietro il client, o due reti che condividono lo stesso intervallo di indirizzi. Entrambi producono una macchina che può navigare e non può stampare, e le loro correzioni sono opposte, quindi la diagnosi deve venire prima della configurazione.

L’osservazione decisiva è se la sottorete locale è ancora presente nella tabella di routing mentre il traffico verso di essa viene scartato.

Tre condizioni decidono la risposta

Primo, questa macchina ha bisogno della chiusura sicura? Se la risposta è sì, un tunnel che cade deve fermare il traffico invece di lasciarlo ricadere sull’interfaccia fisica, e questo requisito pesa più della comodità locale. Secondo, i dispositivi locali devono restare raggiungibili mentre il tunnel è attivo? La stampa, l’archiviazione in rete e le console di gestione locali sono i motivi abituali, e sono requisiti legittimi, non eccezioni di cui scusarsi. Terzo, il profilo esprime il valore predefinito come il letterale 0.0.0.0/0? È proprio quel dettaglio ad attivare le regole del client, ed è modificabile.

Rispondete a queste tre domande per iscritto prima di toccare un profilo, perché ogni risposta punta a una configurazione diversa.

Scegliete la chiusura sicura e rinunciate alla LAN

Se le fughe contano più della raggiungibilità locale, conservate il valore predefinito letterale e lasciate attivo Blocca il traffico non incanalato nel tunnel. È una posizione coerente: la macchina è trattata come un dispositivo che è o dentro il tunnel o offline, e i servizi locali si raggiungono da un altro dispositivo o attraverso il tunnel se il server li instrada. Il costo è reale e andrebbe indicato nelle note di distribuzione, invece di essere scoperto dalla persona che deve stampare.

Questa è la scelta giusta per le macchine che gestiscono un lavoro che non deve comparire su una rete di caffè quando il tunnel cade. È un cattivo valore predefinito per un portatile domestico che ha bisogno anche dello scanner.

Scegliete l’accesso alla LAN ed esprimete il valore predefinito diversamente

Se i dispositivi locali devono restare raggiungibili, esprimete la stessa copertura senza il prefisso predefinito letterale. Due semi-prefissi coprono ogni indirizzo IPv4, la coppia equivalente copre IPv6, e il client non inserisce più le regole di blocco perché la stringa che cerca è assente.

[Peer]
AllowedIPs = 0.0.0.0/1
AllowedIPs = 128.0.0.0/1
AllowedIPs = ::/1
AllowedIPs = 8000::/1
Endpoint = vpn.example.net:51820

Deselezionare quella casella fa sì che il client scriva le stesse due coppie nel profilo, quindi confrontare il file generato con il blocco qui sopra è un modo rapido per confermare il meccanismo invece di indovinarlo. Ne derivano due conseguenze. La copertura è identica, quindi nient’altro del tunnel cambia. La protezione non è identica: con le regole sparite, un tunnel che cade lascia la macchina sulla sua interfaccia fisica, ed è precisamente ciò che la chiusura sicura impediva.

Controllate comunque gli altri due sospetti

Una volta risolta la questione del firewall, confermate che la sottorete locale sia davvero instradata e che l’estremità remota sappia tutto ciò che sta dietro questo client. Un server che deve raggiungere una LAN dietro un client ha bisogno di quel prefisso nell’elenco consentito del client sull’hub; omettetelo e l’hub non può scegliere un peer per quegli indirizzi, e nessuna configurazione del client ne crea uno.

Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory
Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultOutboundAction
route print 0.0.0.0

La categoria di rete conta più di quanto la gente si aspetti: un adattatore di tunnel appena creato classificato come pubblico cambia quali regole vi si applicano, e il risultato può sembrare un blocco del firewall all’estremità remota. La stampa delle rotte mostra se esiste del tutto un valore predefinito, il che separa un problema di criterio da una rotta mancante.

Poi provate tre cose in una sola sessione: internet, un host locale per indirizzo e un host attraverso il tunnel. La stretta di mano dimostra solo che le chiavi concordano, quindi sono le tre prove a dimostrare il criterio. Se l’host locale rifiuta ancora con l’opzione disattivata, i sospetti rimasti sono la rotta, l’elenco consentito dell’estremità remota e la sottorete duplicata, in quest’ordine.