Linuxi distributsiooni tulemüür võib teie VPN-liikluse blokeerida

Tunnel tõuseb, logi ütleb ühendatud, ja üks rakendus ei jõua ikkagi kuhugi. Linuxi kliendis tähendab see tavaliselt, et distributsiooni tulemüür filtreerib teed, mida VPN-klient ei ole kunagi haldanud. Kaks haldurit võivad olla korraga aktiivsed, kummalgi oma arusaam liidesest, tsoonist ja liikluse suunast. Omaniku tuvastamine enne mis tahes muudatust on kiirem kui reeglite proovimine, kuni midagi tööle hakkab.

Leidke haldur ja taustaprogramm

Alustage sellest, mis on tegelikult laaditud, mitte sellest, mis on paigaldatud. Distributsioon võib pakkuda firewalld, ufw ja tavalist nftables-teenust ning ainult üks neist omab jooksvat reeglistikku. Paketid eksisteerivad rahulikult kõrvuti ja vale esiliidese kaudu sisestatud reegel ei jõua kunagi tuumani. Lugege aktiivset teenust ja seejärel reeglistikku, mille see tekitas.

Taustaprogramm on sama oluline kui esiliides. firewalld paigaldus võib versioonist ja konfiguratsioonist sõltuvalt juhtida nftablesi või vana iptablesi taustaprogrammi ning need kaks annavad erineva kontrollväljundi. Kirjutage distributsioon, versioon ja taustaprogramm piletisse enne, kui võrdlete oma süsteemi mis tahes juhendiga.

Sobitage suund ja liides

Väljuv kliendipäring, sissetulev kuulaja ja edastatud pakett läbivad erinevaid konksusid ning ühe jaoks mõeldud reegel ei kata teisi. Tsoon, mis lubab kohalikku LAN-i, ei sisalda sageli tunneliliidest ega VPN-i aadressvahemikku. Tunneliliides maandub tavaliselt vaiketsoonis, mis on sageli rangem kui füüsilise adapteri tsoon. See lahknevus selgitab, miks sirvimine LAN-is töötab ja peatub hetkel, mil tunnel tõuseb.

Küsige, milline suund ebaõnnestus, enne kui reegli valite. Rakendus, mis ei saa väljapoole ühenduda, vajab väljundteed, samas kui sissetulev teenus vajab tunneliliidesel sisendteed. Reegli lisamine valesse ahelasse tekitab muudatuse, mis näib rakendatud ja ei tee üldse midagi.

Hoidke reeglite omanikud üksmeeles

VPN-kliendi konks, konteinerite käituskeskkond ja distributsiooni teenus võivad kõik võrku muuta, ja nad ei koordineeri omavahel. Käsitsi sisestatud reeglid kaovad järgmisel uuestilaadimisel ja halduri ahelasse lisatud reegleid võidakse hinnata järjekorras, mida te ei kavatsenud. Kasutage halduri püsivat konfiguratsiooni ja kontrollige tulemuseks olevat reeglistikku, mitte faili, mille kirjutasite. Kogu tulemüüri väljalülitamine sellepärast, et üks teenus on kättesaamatu, vahetab väikese probleemi suure vastu.

Kitsad loendurid on odav viis tagasilükatud voolu leidmiseks. Ühe sihtkoha ja ühe pordiga piiratud logireegel näitab, kas langetamine toimub kohapeal, ilma et see kaptaks kellegi teise liiklust. Eemaldage logireegel uurimise lõppedes, sest see on diagnostika, mitte poliitika, ja firewalldi tsoonide dokumentatsioon selgitab, kuidas liidesed ja teenused kombineeruvad.

Kontrollige parandust ilma lukustust kaotamata

Kontrollige rakendatud olekut seda omava halduriga, kasutades käske, mis vastavad kirja pandud taustaprogrammile. Allolev loend eeldab, et firewalld vastutab; asendage see nftablesi või ufw vastega, mitte ärge käivitage kõiki. Tööriistade segamine ühes seansis on viis, kuidas masin jõuab kahe vastuolulise reeglistikuni.

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

Esimene käsk nimetab tsoonid ja neile määratud liidesed, mis näitab, kuhu tunnel tegelikult maandus. Teine väljastab tsooni reeglid ja teenused, nii et näete, kas VPN-liides on üldse kaetud. nftablesi loend on kasutatava taustaprogrammi põhitõde ja reegel, mis eksisteerib ainult konfiguratsioonifailis, ei ilmu sinna. Võrrelge kolme väljundit lisatud reegliga ja lahknevus nimetab end tavaliselt ise.

Seejärel korrake algset päringut ja nõutavat rikkekäitumist. Värskelt töötav sait ei ole piisav, kui sama muudatus eemaldas kliendi lukustuse, seega testige ka kaitsmata teed. Kirjutage üles haldur, taustaprogramm, liides ja reegli eesmärk, sest teise halduri taaselustav paketiuuendus ehitab muidu kogu segaduse uuesti üles.