Een firewall van een Linux-distributie kan je VPN-verkeer blokkeren

De tunnel komt op, het logboek zegt verbonden, en één toepassing bereikt nog steeds niets. Op een Linux-client betekent dat meestal dat de firewall van de distributie een pad filtert dat de VPN-client nooit heeft beheerd. Twee beheerders kunnen tegelijk actief zijn, elk met eigen ideeën over de interface, de zone en de richting van het verkeer. De eigenaar identificeren voordat je iets aanpast is sneller dan regels proberen tot iets werkt.

Vind de beheerder en de backend

Begin met wat werkelijk geladen is, niet met wat geïnstalleerd is. Een distributie kan firewalld, ufw en een gewone nftables-dienst meeleveren, en slechts één daarvan bezit de draaiende regelset. De pakketten leven vreedzaam naast elkaar, en een regel die via de verkeerde frontend is ingevoerd, bereikt de kernel nooit. Lees de actieve dienst en lees daarna de regelset die deze heeft geproduceerd.

De backend is even belangrijk als de frontend. Een firewalld-installatie kan nftables of de oude iptables-backend aansturen, afhankelijk van versie en configuratie, en beide geven andere inspectie-uitvoer. Schrijf de distributie, de versie en de backend in het ticket voordat je je systeem met welke gids dan ook vergelijkt.

Laat richting en interface overeenkomen

Een uitgaand clientverzoek, een inkomende luisteraar en een doorgestuurd pakket passeren verschillende haken, en een regel voor de ene dekt de andere niet. Een zone die het lokale LAN toestaat, bevat vaak niet de tunnelinterface of de VPN-adrespoel. Een tunnelinterface belandt meestal in de standaardzone, die vaak strenger is dan de zone waarin de fysieke adapter zit. Die mismatch verklaart waarom browsen op het LAN werkt en stopt op het moment dat de tunnel opkomt.

Vraag welke richting is mislukt voordat je een regel kiest. Een toepassing die niet naar buiten kan verbinden, heeft het uitvoerpad nodig, terwijl een inkomende dienst het invoerpad op de tunnelinterface nodig heeft. Een regel aan de verkeerde keten toevoegen levert een wijziging op die toegepast lijkt en helemaal niets doet.

Houd de regeleigenaren op één lijn

De haak van een VPN-client, een container-runtime en de dienst van de distributie kunnen allemaal het netwerk aanpassen, en ze stemmen niet met elkaar af. Handmatig ingevoerde regels verdwijnen bij de volgende herlaadbeurt, en regels die in de keten van een beheerder zijn ingevoegd, kunnen in een volgorde worden geëvalueerd die je niet bedoelde. Gebruik de blijvende configuratie van de beheerder en inspecteer de resulterende regelset in plaats van het bestand dat je hebt geschreven. De hele firewall uitschakelen omdat één dienst onbereikbaar is, ruilt een klein probleem in voor een groot.

Smalle tellers zijn de goedkope manier om de geweigerde stroom te vinden. Een logregel die tot één bestemming en één poort beperkt is, toont of de drop lokaal gebeurt zonder andermans verkeer vast te leggen. Verwijder de logregel wanneer het onderzoek eindigt, want het is diagnostiek en geen beleid, en de zonedocumentatie van firewalld legt uit hoe interfaces en diensten samengaan.

Controleer de oplossing zonder de lockdown te verliezen

Inspecteer de toegepaste toestand met de beheerder die haar bezit, met opdrachten die passen bij de backend die je hebt genoteerd. De onderstaande lijst gaat ervan uit dat firewalld de baas is; vervang door het equivalent voor nftables of ufw in plaats van ze allemaal te draaien. Gereedschap in één sessie mengen is hoe een machine met twee tegenstrijdige regelsets eindigt.

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=trusted --list-all
sudo nft list ruleset | head -40

De eerste opdracht noemt de zones en de interfaces die daaraan zijn toegewezen, wat toont waar de tunnel werkelijk is beland. De tweede drukt de regels en diensten van een zone af, zodat je kunt zien of de VPN-interface überhaupt gedekt is. De nftables-lijst is de grondwaarheid voor de gebruikte backend, en een regel die alleen in een configuratiebestand bestaat, verschijnt daar niet. Vergelijk de drie uitvoer met de regel die je hebt toegevoegd, en de mismatch noemt zichzelf meestal.

Herhaal daarna het oorspronkelijke verzoek en het faalgedrag dat je eist. Een nieuw werkende site is niet genoeg als dezelfde wijziging de lockdown van de client heeft verwijderd, dus test ook een onbeschermd pad. Noteer de beheerder, backend, interface en het doel van de regel, want een pakketupdate die een tweede beheerder nieuw leven inblaast, bouwt anders de hele rommel opnieuw op.