Išjungimo scenarijus ar ugniasienės taisyklė: kas sustabdo nuotėkį?
Sąsajų išjungimas atsijungimo metu yra grubus ir dažnai vykdomas be teisių. Palyginkite jį su ugniasienės taisykle, kuri išlieka po nutrūkimo ir uždaro spragą.
Du sprendimai žada tą patį: kai tunelis krenta, niekas neišeina atviru pavidalu. Vienas paleidžia scenarijų išjungimo metu ir nupjauna sąsajas. Kitas palieka ugniasienės taisyklę galioti ir nieko neprašo iš VPN kliento. Jie skiriasi tuo, kas turi teisę veikti, kas vyksta spragos metu ir kaip įrenginys vėliau grįžta į tinklą. Palyginti juos šiais trimis aspektais naudingiau nei ginčytis, kuri yra griežtesnė.
Tas pats darbas dviem mechanizmais
Klientas gali vykdyti kabliukus, kai tunelis pakyla ir kai jis išjungiamas, jei profilis leidžia vykdyti scenarijus. Tas kabliukas veikia kliento gyvavimo ciklo viduje, tuo metu, kai ryšys užsidaro. Ugniasienės taisyklė, priešingai, priklauso sistemai ir nesirūpina, ar klientas veikia, ar sugedo, ar buvo nužudytas.
| Property | Teardown script | Firewall unit |
|---|---|---|
| Runs when the client is killed | No | Yes |
| Needs privilege at teardown time | Usually yes | Configured once, at boot |
| Acts on the whole machine | Often, including recovery paths | Only on the flows it matches |
Ši lentelė yra visas argumentas. Scenarijus, kuris veikia tik tvarkingai uždarant, apima atvejį, kuris jus jaudino mažiausiai; svarbus atvejis yra lūžis arba dingęs tinklas, ir nė vienas iš jų nesuteikia švaraus išjungimo.
Ką išjungimo kabliukas gali ir ko negali
Dokumentuotas šablonas pereina tinklo sąsajas ir išjungia viską, išskyrus loopback. Kai fizinis įrenginys išjungtas, niekas negali pabėgti už tunelio ribų, ir būtent tai yra tikslas.
#!/bin/sh
for dev in /sys/class/net/*; do
name=$(basename "$dev")
[ "$name" = lo ] || ip link set dev "$name" down
done
Jis taip pat išjungia vietinį tinklą, bet kokią paslaugą, kurią įrenginys talpina, ir kelią, kuriuo taisytumėte problemą. Nešiojamajame kompiuteryje belaidis įrenginys kartais vėliau turi būti perjungiamas rankiniu būdu, todėl trumpas sutrikimas virsta remonto sesija. Dar blogiau, kabliukui gali būti iš viso neleista to daryti: kai klientas atsisako teisių, išjungimo scenarijus vykdomas be privilegijų esančioje paskyroje, o kiekvienas sąsajos pakeitimas nepavyksta su teisių klaida, įrašyta tuo metu, kai niekas neskaito žurnalo.
Prieš pasitikėdami kabliuku patikrinkite, kaip klientas paleidžiamas. Scenarijus, kuris veikia paleistas rankiniu būdu kaip root, nieko neįrodo apie paslaugą, kuri paleidžiama įkraunant sistemą.
Ką ugniasienės taisyklė daro kitaip
Taisyklė, leidžianti tik tunelio srautą, veikia toliau, kai kliento proceso nebėra, nes branduolys nuo to proceso nepriklauso. Taisyklė taip pat siauresnė: ji blokuoja būtent tuos srautus, kuriuos atitinka, ir palieka ramybėje loopback, vietinį potinklį bei atkūrimo kelią, todėl įrenginys neatsiduria aklavietėje.
Kaina ta, kad taisyklę turi parašyti ir prižiūrėti tas, kam priklauso prieglobos ugniasienė, ir ji turi įvardyti tunelio įrenginį, kurį klientas iš tikrųjų sukuria. Tai reiškia, kad taisyklė ir profilis turi būti prižiūrimi kartu; pervadinta sąsaja palieka ugniasienę, kuri blokuoja viską ir nieko nepaaiškina.
Nė vienas mechanizmas nepadaro kito nereikalingo. Ugniasienės taisyklė, kuri po pakeitimo niekada neįkeliama iš naujo, yra tokia pat išgalvota kaip scenarijus, kuris niekada nevykdomas.
persist-tun nusprendžia, ar spraga yra
Kai tunelio įrenginys išgyvena atsijungimą, išgyvena ir į jį vedantys maršrutai. Srautas tada išmetamas, o ne peradresuojamas, todėl numatytasis maršrutas negrįžta prie fizinės šliuzo. Būtent šis elgesys daro nuotėkį mažai tikėtiną dar prieš įsikišant bet kokiai ugniasienės taisyklei.
Be šio nustatymo įrenginys pašalinamas kartu su maršrutais, o numatytasis maršrutas vėl gali rodyti į fizinį šliuzą. Ar taip nutiks, priklauso nuo platformos ir kliento, ir būtent todėl būseną reikia stebėti, o ne daryti prielaidas. Laikykite nustatymą kill switch dalimi, o ne našumo parinktimi.
Išlaikykite prisijungimo kelio gyvumą, tada išbandykite keturias būsenas
Griežtas blokavimas gali sutrukdyti klientui vėl prisijungti, nes klientui vis dar reikia maršruto į serverį per fizinį šliuzą, kol visa kita atmetama. Įdiekite prieglobos maršrutą tam vienam adresui prieš tuneliui pakylant ir pirmiausia išspręskite vardą, nes DNS gali būti užblokuotas tuo metu, kai jo prireiks.
ip route add 198.51.100.20/32 via 192.168.0.1 dev wlan0
Tada tikrinkite būsenas, o ne etiketę. Sąmoningai išgyvenkite keturis momentus: šaltą paleidimą be tunelio, sveiką sesiją, niekieno neprašytą nutrūkimą ir sesiją po atsistatymo. Kiekvienu momentu perskaitykite numatytąjį maršrutą ir atlikite vieną užklausą, kurios išėjimo adresas matomas. Programa, kuri pasiduoda, kol tunelis išjungtas, nieko nesako apie pašto klientą ar atnaujintuvą, todėl pakartokite paskutinį patikrinimą su viena fono programa. Užrašykite taisyklę, sąsajų pavadinimus ir atkūrimo veiksmus, nes kill switch, kurio niekas negali patikrinti, yra gandas.