NordVPN su Linux blocca la LAN: lista di autorizzazione e DNS

Tutto sembra normale finché non provi a raggiungere qualcosa sulla tua scrivania. Il tunnel è attivo, le pagine si caricano e l’unità di rete va in timeout. Disconnetti e l’unità è di nuovo lì prima che tu finisca la frase, il che ti dice più di qualsiasi registro: il client rifiuta deliberatamente il traffico che non entra nel tunnel, e la tua rete locale è dalla parte sbagliata di quella linea.

L’interruttore di sicurezza fa il suo lavoro

Un interruttore di sicurezza esiste per impedire al traffico di uscire quando il tunnel non è disponibile. Gli intervalli di indirizzi privati contano come traffico che non entra nel tunnel, quindi un’implementazione rigorosa li blocca insieme a tutto il resto. Non è un bug nel senso che le persone intendono quando presentano il rapporto.

Leggi prima la visuale del client stesso. Un comando stampa le impostazioni attuali e un secondo mostra gli oggetti del firewall creati dal client. Stai cercando un drop o un reject che compaia prima di qualsiasi eccezione del tunnel, perché è quell’ordine a rendere irraggiungibile la rete locale.

nordvpn settings
sudo nft list ruleset
sudo iptables -S

Poi esegui un test che divide il problema a metà. Raggiungi il dispositivo per indirizzo e poi per nome. L’indirizzo funziona e il nome fallisce significa che il firewall è innocente e il resolver no. Entrambi falliscono significa che il firewall rifiuta il pacchetto, e il resto di questo articolo vale.

Lista di autorizzazione: scegli il tipo di voce in base al sintomo

Il client offre una lista di autorizzazione con tre tipi di voce, e scegliere il tipo giusto è la maggior parte del lavoro. Una sottorete copre gli host. Una porta copre un servizio indipendentemente dalla destinazione. Un gruppo multicast copre il traffico di scoperta, che è una forma di traffico diversa da qualsiasi cosa indirizzata a un singolo host.

nordvpn allowlist add subnet 192.168.1.0/24
nordvpn allowlist add port 22
nordvpn allowlist add subnet 239.255.255.250/32
sudo nft list ruleset | grep -i allow

I guasti di scoperta sorprendono perché una stampante o un server multimediale può essere trovato con una query indirizzata al gruppo invece che con una ricerca del suo indirizzo. Aggiungere la sottorete dell’host non copre automaticamente quel gruppo, quindi il dispositivo resta invisibile mentre la sua pagina web si carica bene quando digiti l’indirizzo.

Mantieni l’eccezione stretta quanto il sintomo consente. Un prefisso ampio digitato una volta viene dimenticato per anni, e nessuno può spiegare in seguito quali macchine doveva ammettere. Elimina le voci quando il progetto che le richiedeva finisce e controlla cosa resta dopo un aggiornamento.

Le build recenti espongono anche un’unica impostazione di scoperta LAN. È comoda, e interagisce con la lista di autorizzazione invece di impilarsi su di essa: attivarla può cancellare le voci esistenti di sottoreti private, e una regola manuale di sottorete privata può essere rifiutata finché resta attiva.

I nomi host richiedono una decisione separata

Autorizzare una sottorete ripristina la connettività per indirizzo e lascia intatta la denominazione. I nomi host locali vengono ancora inviati al resolver che il client ha configurato quando il tunnel è salito, quindi un nome che prima si risolveva ora non restituisce nulla.

Puntare il client al resolver del router risolve in un passo e cambia silenziosamente ciò che hai comprato. Ogni interrogazione, non solo quelle locali, esce allora dal router, quindi il tunnel non protegge più la parte della tua navigazione che rivela le intenzioni.

La via più stretta conserva il resolver del tunnel e aggiunge i pochi nomi che contano, come dominio di ricerca o come voci individuali. Costa più attenzione e preserva la proprietà per cui hai pagato.

Controlla il risultato con una chiamata al resolver di sistema invece che con un browser. I browser eseguono sempre più spesso la propria risoluzione cifrata e rispondono volentieri da un percorso che la tua shell non usa mai, quindi la barra degli indirizzi può sembrare sana mentre il resolver di sistema è ancora rotto.

Il problema di installazione che arriva per primo

Una buona parte di questi rapporti non arriva mai al firewall, perché il comando non c’è affatto. Il pacchetto di avvio del fornitore registra un repository e una chiave di firma. Non installa il client, quindi un comando mancante subito dopo è il risultato atteso e non un guasto.

Aggiorna gli elenchi dei pacchetti e installa per nome. Se il gestore di pacchetti si lamenta di una chiave pubblica mancante, la chiave non è arrivata dove la cerca, e la correzione è metterla lì prima di aggiornare di nuovo.

Se il nome host del repository si risolve in un indirizzo privato, fermati e leggi quel risultato due volte. Potresti già eseguire un tunnel il cui resolver risponde per nomi pubblici, e riprovare l’installazione produrrà lo stesso messaggio all’infinito.

Scrivilo prima di chiudere il coperchio

Stabilisci che il tunnel è l’unica cosa cambiata, poi autorizza la cosa più piccola che ripristina il sintomo. Mantieni la denominazione come una decisione a sé con la sua nota.

Registra quale eccezione esiste per quale dispositivo e chi l’ha chiesta. Una rete locale che funziona solo perché qualcuno ha digitato un prefisso ampio è una decisione che ha già sopravvissuto alla sua ragione.

Riprova dopo l’aggiornamento del client. La disposizione del firewall cambia tra le versioni, e la lista di autorizzazione del mese scorso non è un fatto su questo mese.