En brandvägg i en Linux-distribution kan blockera din VPN-trafik

Tunneln kommer upp, loggen säger ansluten, och en applikation når fortfarande ingenting. På en Linux-klient betyder det oftast att distributionens brandvägg filtrerar en väg som VPN-klienten aldrig hanterade. Två hanterare kan vara aktiva samtidigt, var och en med sina egna föreställningar om gränssnittet, zonen och trafikens riktning. Att identifiera ägaren innan man ändrar något går snabbare än att prova regler tills något fungerar.

Hitta hanteraren och backend

Börja med det som faktiskt är laddat, inte det som är installerat. En distribution kan leverera firewalld, ufw och en vanlig nftables-tjänst, och bara en av dem äger den körande regeluppsättningen. Paketen samexisterar fredligt, och en regel som matas in via fel frontend når aldrig kärnan. Läs den aktiva tjänsten och läs sedan regeluppsättningen den producerade.

Backend spelar lika stor roll som frontend. En firewalld-installation kan driva nftables eller den gamla iptables-backenden beroende på version och konfiguration, och de två ger olika inspektionsutdata. Skriv distributionen, versionen och backenden i ärendet innan du jämför ditt system med någon guide.

Matcha riktningen och gränssnittet

En utgående klientförfrågan, en inkommande lyssnare och ett vidarebefordrat paket passerar olika krokar, och en regel för en täcker inte de andra. En zon som tillåter det lokala LAN:et omfattar ofta inte tunnelgränssnittet eller VPN-adresspoolen. Ett tunnelgränssnitt landar vanligtvis i standardzonen, som ofta är strängare än zonen den fysiska adaptern sitter i. Den missanpassningen förklarar varför surfning fungerar på LAN:et och slutar i samma ögonblick som tunneln kommer upp.

Fråga vilken riktning som misslyckades innan du väljer en regel. En applikation som inte kan ansluta utåt behöver utvägen, medan en inkommande tjänst behöver invägen på tunnelgränssnittet. Att lägga till en regel i fel kedja ger en ändring som ser tillämpad ut och inte gör någonting alls.

Håll reglernas ägare överens

En VPN-klients krok, en container-runtime och distributionens tjänst kan alla ändra nätverket, och de samordnar sig inte med varandra. Handinmatade regler försvinner vid nästa omladdning, och regler som infogas i en hanterares kedja kan utvärderas i en ordning du inte avsåg. Använd hanterarens beständiga konfiguration och inspektera den resulterande regeluppsättningen i stället för filen du skrev. Att stänga av hela brandväggen för att en tjänst är oåtkomlig byter ett litet problem mot ett stort.

Smala räknare är det billiga sättet att hitta det avvisade flödet. En loggregel begränsad till en destination och en port visar om droppet sker lokalt utan att fånga någon annans trafik. Ta bort loggregeln när utredningen är klar, eftersom den är diagnostik och inte policy, och firewallds zondokumentation förklarar hur gränssnitt och tjänster kombineras.

Kontrollera rättningen utan att förlora låsningen

Inspektera det tillämpade tillståndet med hanteraren som äger det, med kommandon som matchar den backend du antecknade. Listan nedan förutsätter att firewalld ansvarar; byt ut den mot motsvarigheten för nftables eller ufw i stället för att köra alla. Att blanda verktyg i en session är hur en maskin hamnar med två motstridiga regeluppsättningar.

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

Det första kommandot namnger zonerna och de gränssnitt som tilldelats dem, vilket visar var tunneln faktiskt landade. Det andra skriver ut en zons regler och tjänster, så att du kan se om VPN-gränssnittet täcks överhuvudtaget. nftables-listan är grundsanningen för den backend som används, och en regel som bara finns i en konfigurationsfil visas inte där. Jämför de tre utdata med regeln du lade till, och missanpassningen namnger sig oftast själv.

Upprepa sedan den ursprungliga förfrågan och det felbeteende du kräver. En nyfungerande webbplats räcker inte om samma ändring tog bort klientens låsning, så testa även en oskyddad väg. Anteckna hanteraren, backenden, gränssnittet och regelns syfte, eftersom en paketuppdatering som väcker en andra hanterare annars bygger upp hela röran igen.