Жабу скрипті немесе firewall ережесі: ағып кетуді қайсысы тоқтатады?
Ажырау кезінде интерфейстерді түсіру дөрекі әдіс және көбінесе құқықсыз іске қосылады. Оны үзілістен кейін де күшінде қалатын және саңылауды жабатын firewall ережесімен салыстырыңыз.
Екі жоба бір нәрсені уәде етеді: туннель құлағанда, ештеңе ашық түрде сыртқа шықпайды. Біреуі жабу кезінде скрипт іске қосып, интерфейстерді кеседі. Екіншісі firewall ережесін күшінде қалдырады және VPN клиентінен ештеңе сұрамайды. Олар әрекет ету құқығы кімде екенімен, саңылау кезінде не болатынымен және машинаның кейін қалай қайта желіге қосылатынымен ерекшеленеді. Оларды осы үш тұрғыдан салыстыру қайсысы қатаңырақ деп дауласқаннан пайдалырақ.
Бір жұмыс, екі механизм
Клиент туннель көтерілгенде және жабылғанда ілмектерді іске қоса алады, егер профиль скрипт орындауға рұқсат берсе. Бұл ілмек клиенттің өмірлік циклінің ішінде, байланыс жабылып жатқан сәтте жұмыс істейді. Ал firewall ережесі жүйеге тиесілі және клиент жұмыс істеп тұр ма, құлады ма, өлтірілді ме — оған бәрібір.
| 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 |
Осы кесте — бүкіл дәлел. Тек ретті жабылу кезінде жұмыс істейтін скрипт сізді ең аз толғандырған жағдайды қамтиды; маңызды жағдай — құлау немесе желінің жоғалуы, және екеуі де таза жабу бермейді.
Жабу ілмегі не істей алады және не істей алмайды
Құжатталған үлгі желілік интерфейстерді аралап шығып, loopback-тан басқасының бәрін түсіреді. Физикалық құрылғы түсірілгенде туннельден тыс жерге ештеңе қаша алмайды, дәл осы көзделген.
#!/bin/sh
for dev in /sys/class/net/*; do
name=$(basename "$dev")
[ "$name" = lo ] || ip link set dev "$name" down
doneОл жергілікті желіні, машина ұсынатын кез келген қызметті және мәселені түзету үшін қолданатын жолды да түсіреді. Ноутбукта сымсыз құрылғы кейде кейін қолмен ауыстыруды қажет етеді, сондықтан қысқа үзіліс жөндеу сессиясына айналады. Одан бетер, ілмекке мұның ешқайсысын істеуге рұқсат болмауы мүмкін: клиент құқықтарынан бас тартқанда, жабу скрипті артықшылығы жоқ тіркелгімен жұмыс істейді және интерфейстің әрбір өзгерісі ешкім журналды оқымайтын сәтте жазылған рұқсат қатесімен сәтсіз аяқталады.
Ілмекке сенбес бұрын клиенттің қалай іске қосылатынын тексеріңіз. root ретінде қолмен іске қосқанда жұмыс істейтін скрипт жүктелу кезінде басталатын қызмет туралы ештеңе дәлелдемейді.
Firewall ережесі нені басқаша жасайды
Тек туннель трафигіне рұқсат беретін ереже клиент процесі жоғалғанда да жұмысын жалғастырады, өйткені ядро сол процеске тәуелді емес. Ереже тарлау да: ол сәйкес келетін ағындарды дәл бөгеп, loopback-ты, жергілікті ішкі желіні және қалпына келтіру жолын тыныш қалдырады, сондықтан машинаны қаңғытып тастамайды.
Бағасы — ережені хосттың firewall-ына ие адам жазып, ұстап тұруы керек, және ол клиент шын мәнінде жасайтын туннель құрылғысын атауы керек. Бұл ереже мен профильді бірге ұстау керек деген сөз; аты өзгертілген интерфейс бәрін бөгеп, ештеңе түсіндірмейтін firewall қалдырады.
Екі механизмнің ешқайсысы екіншісін артық етпейді. Өңдеуден кейін ешқашан қайта жүктелмейтін firewall ережесі ешқашан іске қосылмайтын скрипт сияқты ойдан шығарылған.
persist-tun саңылау бар-жоғын шешеді
Туннель құрылғысы ажыраудан аман өтсе, оған бағытталған маршруттар да аман қалады. Сонда трафик қайта бағытталудың орнына тасталып кетеді, сондықтан әдепкі маршрут физикалық шлюзге қайта оралмайды. Дәл осы мінез-құлық кез келген firewall ережесі араласпай тұрып-ақ ағып кетуді ықтималсыз етеді.
Бұл параметрсіз құрылғы маршруттармен бірге жойылады және әдепкі маршрут қайтадан физикалық шлюзге көрсетуі мүмкін. Олай бола ма — платформа мен клиентке байланысты, сондықтан күйді болжамай, бақылау керек. Параметрді kill switch-тің бөлігі деп қараңыз, өнімділік опциясы деп емес.
Қайта қосылу жолын тірі ұстаңыз, содан кейін төрт күйді тексеріңіз
Қатаң бөгеу клиенттің қайта қосылуына да кедергі келтіруі мүмкін, өйткені клиентке әлі де физикалық шлюз арқылы серверге маршрут қажет, ал қалғанының бәріне тыйым салынған. Туннель көтерілмес бұрын сол бір мекенжайға хост маршрутын орнатыңыз және алдымен атауды шешіңіз, өйткені қажет болғанда DNS бөгелген болуы мүмкін.
ip route add 198.51.100.20/32 via 192.168.0.1 dev wlan0Содан кейін белгіні емес, күйлерді тексеріңіз. Төрт сәтті әдейі бастан өткеріңіз: туннельсіз суық іске қосу, сау сессия, ешкім сұрамаған үзіліс және қалпына келгеннен кейінгі сессия. Әр сәтте әдепкі маршрутты оқып, шығу мекенжайы көрінетін бір сұрау жіберіңіз. Туннель түсірілген кезде бас тартатын қолданба пошта клиенті немесе жаңартқыш туралы ештеңе айтпайды, сондықтан соңғы тексеруді бір фондық қолданбамен қайталаңыз. Ережені, интерфейс атауларын және қалпына келтіру қадамдарын жазып қойыңыз, өйткені ешкім тексере алмайтын kill switch — қауесет қана.