NordVPN pe Linux blochează LAN-ul: listă de permisiuni și DNS

Totul pare normal până când încerci să ajungi la ceva de pe propriul birou. Tunelul este activ, paginile se încarcă, iar unitatea de rețea expiră. Deconectează-te și unitatea revine înainte să termini propoziția, ceea ce îți spune mai mult decât orice jurnal: clientul refuză deliberat traficul care nu intră în tunel, iar rețeaua ta locală este de partea greșită a acelei linii.

Întrerupătorul de siguranță își face treaba

Un întrerupător de siguranță există pentru a împiedica traficul să scape atunci când tunelul nu este disponibil. Intervalele private de adrese sunt considerate trafic care nu intră în tunel, așa că o implementare strictă le blochează împreună cu tot restul. Nu este un bug în sensul la care se referă oamenii când depun raportul.

Citește mai întâi viziunea clientului însuși. O comandă tipărește setările curente, iar a doua arată obiectele de firewall pe care clientul le-a creat. Cauți un drop sau un reject care apare înaintea oricărei excepții de tunel, pentru că această ordine este cea care face rețeaua locală inaccesibilă.

nordvpn settings
sudo nft list ruleset
sudo iptables -S

Apoi rulează un singur test care împarte problema în două. Ajunge la dispozitiv după adresă, apoi după nume. Adresa funcționează și numele eșuează înseamnă că firewall-ul este nevinovat, iar rezolvatorul nu. Ambele eșuează înseamnă că firewall-ul refuză pachetul, iar restul acestui articol se aplică.

Lista de permisiuni: alege tipul intrării după simptom

Clientul oferă o listă de permisiuni cu trei tipuri de intrări, iar alegerea tipului potrivit este cea mai mare parte a muncii. O subrețea acoperă gazde. Un port acoperă un serviciu indiferent de destinație. Un grup multicast acoperă traficul de descoperire, care este o formă diferită de trafic față de orice adresat unei singure gazde.

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

Eșecurile de descoperire surprind oamenii pentru că o imprimantă sau un server media poate fi găsit printr-o interogare adresată grupului în locul unei căutări a propriei adrese. Adăugarea subrețelei gazdei nu acoperă automat acel grup, așa că dispozitivul rămâne invizibil în timp ce pagina sa web se încarcă bine când tastați adresa.

Păstrează excepția atât de îngustă cât permite simptomul. Un prefix larg tastat o dată este uitat ani de zile, iar nimeni nu poate explica mai târziu ce mașini ar fi trebuit să admită. Șterge intrările când proiectul care avea nevoie de ele se termină și verifică ce rămâne după o actualizare.

Versiunile recente expun și o singură setare de descoperire LAN. Este comodă și interacționează cu lista de permisiuni în loc să se suprapună peste ea: activarea ei poate șterge intrări existente pentru subrețele private, iar o regulă manuală pentru o subrețea privată poate fi refuzată cât timp rămâne activată.

Numele de gazdă necesită o decizie separată

Permiterea unei subrețele restabilește conectivitatea după adresă și lasă denumirea neatinsă. Numele de gazdă locale sunt încă trimise către rezolvatorul pe care clientul l-a configurat când a urcat tunelul, așa că un nume care se rezolva înainte acum nu mai returnează nimic.

Direcționarea clientului către rezolvatorul routerului rezolvă asta într-un singur pas și schimbă în tăcere ce ai cumpărat. Atunci fiecare interogare, nu doar cele locale, iese prin router, așa că tunelul nu mai protejează partea navigării tale care dezvăluie intențiile.

Calea mai îngustă păstrează rezolvatorul tunelului și adaugă puținele nume care contează, fie ca domeniu de căutare, fie ca intrări individuale. Costă mai multă atenție și păstrează proprietatea pentru care ai plătit.

Verifică rezultatul cu un apel la rezolvatorul sistemului în loc de un browser. Browserele rulează tot mai des propria rezolvare criptată și răspund bucuroase pe o cale pe care shell-ul tău nu o folosește niciodată, așa că bara de adrese poate părea sănătoasă în timp ce rezolvatorul sistemului este încă stricat.

Problema de instalare care vine prima

O parte considerabilă din aceste rapoarte nu ajunge niciodată la firewall, pentru că comanda pur și simplu nu există. Pachetul de bootstrap al furnizorului înregistrează un depozit și o cheie de semnare. Nu instalează clientul, așa că o comandă lipsă imediat după aceea este rezultatul așteptat, nu un eșec.

Reîmprospătează listele de pachete și instalează după nume. Dacă managerul de pachete se plânge de o cheie publică lipsă, cheia nu a ajuns unde o caută, iar remediul este să o plasezi acolo înainte de a reîmprospăta din nou.

Dacă numele de gazdă al depozitului se rezolvă într-o adresă privată, oprește-te și citește acel rezultat de două ori. S-ar putea să rulezi deja un tunel al cărui rezolvator răspunde pentru nume publice, iar reîncercarea instalării va produce același mesaj la nesfârșit.

Notează asta înainte de a închide capacul

Stabilește că tunelul este singurul lucru care s-a schimbat, apoi permite cel mai mic lucru care readuce simptomul. Păstrează denumirea ca decizie separată, cu propria notă.

Înregistrează ce excepție există pentru ce dispozitiv și cine a cerut-o. O rețea locală care funcționează doar pentru că cineva a tastat un prefix larg este o decizie care a supraviețuit deja motivului ei.

Retestează după ce clientul se actualizează. Aspectul firewall-ului se schimbă între versiuni, iar lista de permisiuni de luna trecută nu este un fapt despre această lună.