NordVPN op Linux blokkeert het LAN: allowlist en DNS

Alles ziet er normaal uit tot je iets op je eigen bureau probeert te bereiken. De tunnel staat, pagina's laden en de netwerkschijf loopt in een time-out. Verbreek de verbinding en de schijf is terug voordat je de zin afmaakt, wat je meer vertelt dan welk log dan ook: de client weigert bewust verkeer dat niet in de tunnel komt, en je lokale netwerk staat aan de verkeerde kant van die grens.

De killswitch doet zijn werk

Een killswitch bestaat om te voorkomen dat verkeer ontsnapt wanneer de tunnel niet beschikbaar is. Privéadresbereiken gelden als verkeer dat niet in de tunnel komt, dus een strikte implementatie blokkeert ze samen met al het andere. Dat is geen bug in de zin die mensen bedoelen wanneer ze het rapport indienen.

Lees eerst de eigen visie van de client. Eén opdracht drukt de huidige instellingen af, en een tweede toont de firewall-objecten die de client heeft aangemaakt. Je zoekt een drop of reject die vóór elke tunneluitzondering verschijnt, want die volgorde maakt het lokale netwerk onbereikbaar.

nordvpn settings
sudo nft list ruleset
sudo iptables -S

Voer daarna één test uit die het probleem in tweeën splitst. Bereik het apparaat via het adres en daarna via de naam. Adres werkt en naam faalt betekent dat de firewall onschuldig is en de resolver niet. Beide falen betekent dat de firewall het pakket weigert, en de rest van dit artikel geldt.

Allowlist: kies het type vermelding op basis van het symptoom

De client biedt een allowlist met drie soorten vermeldingen, en het juiste type kiezen is het grootste deel van het werk. Een subnet dekt hosts. Een poort dekt één dienst ongeacht de bestemming. Een multicastgroep dekt ontdekkingsverkeer, en dat is een andere vorm van verkeer dan alles wat aan één host is gericht.

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

Ontdekkingsfouten verrassen mensen omdat een printer of mediaserver gevonden kan worden via een groepsgerichte query in plaats van een opzoeking van het eigen adres. Het subnet van de host toevoegen dekt die groep niet automatisch, dus het apparaat blijft onzichtbaar terwijl de webpagina prima laadt wanneer je het adres typt.

Houd de uitzondering zo smal als het symptoom toelaat. Een brede prefix die één keer is getypt, raakt jarenlang vergeten, en niemand kan later uitleggen welke machines er binnen moesten. Verwijder vermeldingen wanneer het project dat ze nodig had eindigt, en controleer wat er na een update overblijft.

Recente builds bieden ook één instelling voor LAN-ontdekking. Die is handig, en ze werkt samen met de allowlist in plaats van erbovenop te stapelen: inschakelen kan bestaande vermeldingen voor privésubnetten wissen, en een handmatige regel voor een privésubnet kan geweigerd worden zolang die aan blijft staan.

Hostnamen vragen een aparte beslissing

Een subnet toestaan herstelt de verbinding via het adres en laat de naamgeving ongemoeid. Lokale hostnamen worden nog steeds naar de resolver gestuurd die de client instelde toen de tunnel opkwam, dus een naam die eerder wel oploste, geeft nu niets terug.

De client naar de resolver van de router wijzen lost dat in één stap op en verandert stil wat je hebt gekocht. Elk opzoeken, niet alleen lokale, gaat dan via de router, dus de tunnel beschermt niet meer het deel van je browsen dat bedoelingen verraadt.

De smallere route houdt de tunnelresolver en voegt de paar namen toe die ertoe doen, als zoekdomein of als afzonderlijke vermeldingen. Het kost meer aandacht en behoudt de eigenschap waarvoor je betaalde.

Controleer het resultaat met een aanroep van de systeemresolver in plaats van een browser. Browsers voeren steeds vaker hun eigen versleutelde resolutie uit en antwoorden graag via een pad dat je shell nooit gebruikt, dus de adresbalk kan er gezond uitzien terwijl de systeemresolver nog steeds stuk is.

Het installatieprobleem dat eerst komt

Een flink deel van deze rapporten bereikt de firewall nooit, omdat de opdracht er helemaal niet is. Het bootstrap-pakket van de leverancier registreert een repository en een ondertekeningssleutel. Het installeert de client niet, dus een ontbrekende opdracht direct daarna is de verwachte uitkomst en geen storing.

Ververs de pakketlijsten en installeer op naam. Als de pakketbeheerder klaagt over een ontbrekende openbare sleutel, is de sleutel niet aangekomen waar hij hem zoekt, en de oplossing is hem daar te plaatsen voordat je opnieuw ververs.

Als de hostnaam van de repository naar een privéadres oplost, stop en lees dat resultaat twee keer. Misschien draai je al een tunnel waarvan de resolver voor openbare namen antwoordt, en opnieuw installeren levert eindeloos hetzelfde bericht op.

Schrijf het op voordat je het deksel sluit

Stel vast dat de tunnel het enige is dat is veranderd, en sta dan het kleinste toe dat het symptoom herstelt. Houd naamgeving als een eigen beslissing met een eigen notitie.

Noteer welke uitzondering voor welk apparaat bestaat en wie erom vroeg. Een lokaal netwerk dat alleen werkt omdat iemand een brede prefix typte, is een beslissing die de reden ervoor al heeft overleefd.

Test opnieuw nadat de client is bijgewerkt. De firewallindeling verandert tussen releases, en de allowlist van vorige maand is geen feit over deze maand.