Predstavte si mediálny box na domácej linke, ktorý má internet dosahovať len tunelom. Keď tunel padne, aplikácia by sa mala zastaviť, namiesto toho, aby potichu pokračovala cez fyzické rozhranie. Dosiahnuť také správanie je problém firewallu, nie smerovania, a ten rozdiel je dôležitý, pretože trasu možno nahradiť reštartom démona, kým filter zostáva tam, kam ste ho umiestnili. Nasleduje, ako cesta paketu skutočne rozhoduje, a potom ako ohraničiť výnimky, ktoré držia tunel pri opätovnom pripájaní.

Lokálny výstup je iný hák než preposielanie

Paket opúšťajúci aplikáciu na stroji prechádza výstupným hákom; paket, ktorý stroj smeruje pre iný hostiteľ, prechádza preposielaním. Politika, ktorá spomína len forward, obmedzuje druhé a necháva prvé úplne otvorené, a preto toľko zámkov výstupu vyzerá správne a nerobí nič. Párovanie rozhrania patrí do toho istého pravidla: oifname "tun0" accept prepúšťa prevádzku, ktorá už bola tunelom smerovaná. Smerovanie a filtrovanie tiež zostávajú oddelené rozhodnutia, takže trasa k poskytovateľovi môže existovať, kým filter paket odmieta. Na tomto oddelení staviate.

Brána, ktorá preposiela prevádzku iných zariadení, potrebuje oba háky. Zamknutie len výstupu chráni samotný stroj a každému klientovi nižšie necháva voľnosť unikať.

Zoznam výnimiek píšte od koncového bodu von

Začnite pri koncovom bode tunela: jedna cieľová adresa alebo malá schválená množina, transportný protokol a cieľový port, napríklad udp dport 1194 ip daddr 203.0.113.7 accept. Ak klient prekladá názov hostiteľa, počiatočná výmena DNS potrebuje vlastné pravidlo obmedzené na resolver a na port 53, nie plošné povolenie adresy toho resolvera. Každá výnimka by mala pomenovať dôvod, prečo existuje. Povolenie všetkej UDP prevádzky na port VPN pokrýva oveľa viac než jedinú autentizovanú službu, ktorú ste mali na mysli.

Práve pri počiatočnom preklade zámky zvyčajne hnijú. Množina adries obnovovaná časovačom potrebuje definované správanie, keď obnovenie zlyhá, a tým správaním nesmie byť otvorenie linky, kým sa to nepodarí. Obnovujte tunelom, kým tunel stojí, a inak sa vráťte k poslednému známemu funkčnému koncovému bodu.

Lokálna správa potrebuje rovnaké zaobchádzanie. Správna podsiete nie je dôveryhodná len preto, že jej adresy sú privátne, a pravidlo, ktoré jej verí, pozýva druhú cestu okolo zámku.

Párovanie rozhrania nie je dôkaz zdravého tunela

Pravidlá, ktoré prijímajú všetko vychádzajúce z tun0, predpokladajú, že paket na tomto rozhraní prišiel z tunela. Názvy rozhraní sa znovu vytvárajú a názov nie je kryptografická identita. Protistrana tiež môže zmiznúť, kým rozhranie zostáva hore, a pravidlo sa tým mení na veľmi presvedčivú nečinnosť.

Sledovanie spojení pridáva príbuznú pascu. Široké pravidlo pre nadviazané spojenia prehráva oprávnenie, ktoré tok získal skôr, takže relácia začatá pred pádom tunela funguje ďalej. Obmedzte stavové prijímanie na rozhrania a adresy, ktoré skutočne myslíte, inak ste postavili zámok, ktorý sa sám otvára. Vstupné a výstupné pravidlá tiež odpovedajú na rôzne otázky a spevnenie jedného pri ignorovaní druhého necháva stroj dostupný v smere, o ktorom ste neuvažovali.

Čo prežije pád démona

Filter nainštalovaný skriptom, ktorý beží po vzostupe tunela, zmizne spolu s tunelom, presne v okamihu, keď bol potrebný. Načítajte zámok pri štarte a nechajte démona spravovať len jeho výnimky.

Zmazanie predvolenej trasy tiež nie je náhradou. Trasa je stav, ktorý démon vlastní a prepisuje, a jej odstránenie môže vziať cestu potrebnú na opätovné pripojenie. IPv6 potrebuje vlastný plán, pretože objavovanie susedov a oznámenia smerovača sú linkové služby, ktoré musia fungovať ďalej, kým je bežná prevádzka zablokovaná. DHCP patrí do rovnakej kategórie. Zapíšte tieto veci ako výnimky s účelom, namiesto toho, aby ste ich neskôr objavovali ako výpadky.

Cesta obnovy pred nasadením

Testujte zámok tak, ako zlyhá: štart bez tunela, zabitie démona, zmena koncového bodu a opätovné pripojenie. Každý prípad by mal zastaviť aplikácie a nechať záchranný kanál funkčný. Robte to z konzoly, pretože vzdialený shell je relácia, ktorú vaše vlastné pravidlo najpravdepodobnejšie zamkne.

Potom skontrolujte, kam sa bežná aplikácia ešte dostane, s neškodným cieľom a požiadavkou, ktorú môžete overiť. Výsledok, ktorý chcete, je odmietnutie na linke a úspech tunelom, nie dvojznačné čakanie, ktoré môže znamenať oboje. Držte sadu pravidiel pod rovnakým vlastníkom ako zvyšok firewallu, namiesto nahrádzania celej tabuľky zo shell skriptu. Politika, v ktorej každé povolenie dokáže zdôvodniť samo seba, má väčšiu cenu než dlhá sada pravidiel, ktorú nikto nevie vysvetliť.

Súvisiace články