Skripti i uljes apo rregulli i firewall-it: cili e ndal rrjedhjen?

Dy modele premtojnë të njëjtën gjë: kur tuneli bie, asgjë nuk del jashtë në të hapur. Njëri ekzekuton një skript në ulje dhe pret ndërfaqet. Tjetri lë një rregull firewall-i në fuqi dhe nuk i kërkon asgjë klientit VPN. Ata ndryshojnë në atë se kush ka privilegjin të veprojë, çfarë ndodh gjatë hendekut dhe si makina kthehet në linjë pas kësaj. Krahasimi i tyre në këto tri pika është më i dobishëm sesa debati se cili është më i rreptë.

I njëjti punë me dy mekanizma

Klienti mund të ekzekutojë grepa kur tuneli ngrihet dhe kur çmontohet, me kusht që profili të lejojë ekzekutimin e skripteve. Ai grep ekzekutohet brenda ciklit të jetës së klientit, në momentin kur lidhja mbyllet. Rregulli i firewall-it, nga ana tjetër, i përket sistemit dhe nuk i intereson nëse klienti po punon, është rrëzuar apo është vrarë.

Ai tabelë është i gjithë argumenti. Një skript që ekzekutohet vetëm në një mbyllje të rregullt mbulon rastin që ju shqetësonte më pak; rasti që ka rëndësi është rrëzimi ose rrjeti që zhduket, dhe asnjëri nuk jep një çmontim të pastër.

Çfarë mund dhe çfarë nuk mund të bëjë grepi i çmontimit

Modeli i dokumentuar kalon nëpër ndërfaqet e rrjetit dhe ul gjithçka përveç loopback. Kur pajisja fizike është ulur, asgjë nuk mund të shpëtojë jashtë tunelit, dhe ky është pikërisht qëllimi.

#!/bin/sh
for dev in /sys/class/net/*; do
  name=$(basename "$dev")
  [ "$name" = lo ] || ip link set dev "$name" down
done

Ai ul gjithashtu rrjetin lokal, çdo shërbim që makina pret dhe rrugën që do të përdornit për të rregulluar problemin. Në një laptop pajisja pa tel ndonjëherë kërkon një ndërrim manual pas kësaj, kështu që një ndërprerje e shkurtër bëhet seancë riparimi. Më keq, grepit mund t'i mos lejohet të bëjë asgjë nga këto: kur klienti heq dorë nga privilegjet, skripti i uljes ekzekutohet nën llogarinë pa privilegje dhe çdo ndryshim i ndërfaqes dështon me një gabim leje të shkruar në momentin kur askush nuk e lexon regjistrin.

Kontrolloni se si niset klienti përpara se t'i besoni grepit. Një skript që punon kur e ekzekutoni me dorë si root nuk provon asgjë për shërbimin që niset në nisje.

Çfarë bën ndryshe rregulli i firewall-it

Një rregull që lejon vetëm trafikun e tunelit vazhdon të punojë kur procesi i klientit është zhdukur, sepse kerneli nuk varet nga ai proces. Rregulli është gjithashtu më i ngushtë: bllokon pikërisht rrjedhat që përputhen dhe i lë në paqe loopback, nënrrjetin lokal dhe rrugën e rikuperimit, prandaj nuk e lë makinën pa rrugëdalje.

Çmimi është që rregulli duhet të shkruhet dhe të mirëmbahet nga ai që zotëron firewall-in e hostit, dhe duhet të emërojë pajisjen e tunelit që klienti krijon vërtet. Kjo do të thotë që rregulli dhe profili duhet të mirëmbahen bashkë; një ndërfaqe e riemërtuar lë një firewall që bllokon gjithçka dhe nuk shpjegon asgjë.

Asnjë mekanizëm nuk e bën tjetrin të tepërt. Një rregull firewall-i që nuk ringarkohet kurrë pas një redaktimi është po aq fiktiv sa një skript që nuk ekzekutohet kurrë.

persist-tun vendos nëse ekziston një hendek

Kur pajisja e tunelit i mbijeton një shkëputjeje, i mbijetojnë edhe rrugët që tregojnë drejt saj. Trafiku atëherë hidhet poshtë në vend që të ridrejtohet, kështu që rruga e parazgjedhur nuk kthehet te porta fizike. Është pikërisht kjo sjellje që e bën një rrjedhje të pabesueshme edhe përpara se të hyjë në lojë ndonjë rregull firewall-i.

Pa atë cilësim pajisja hiqet bashkë me rrugët, dhe rruga e parazgjedhur mund të tregojë përsëri drejt portës fizike. Nëse e bën këtë varet nga platforma dhe klienti, dhe pikërisht për këtë gjendja duhet vëzhguar e jo supozuar. Trajtojeni cilësimin si pjesë e kill switch, jo si opsion performance.

Mbajeni gjallë rrugën e rilidhjes, pastaj provoni katër gjendje

Një bllokim i rreptë mund ta pengojë klientin edhe të rilidhet, sepse klienti ka ende nevojë për një rrugë drejt serverit përmes portës fizike ndërsa gjithçka tjetër refuzohet. Instaloni një rrugë hosti për atë adresë të vetme përpara se tuneli të ngrihet, dhe zgjidhni emrin së pari, sepse DNS mund të jetë i bllokuar deri në momentin që ju nevojitet.

ip route add 198.51.100.20/32 via 192.168.0.1 dev wlan0

Pastaj verifikoni gjendjet dhe jo etiketën. Provoni me qëllim katër momente: një nisje të ftohtë pa tunel, një seancë të shëndoshë, një rënie që askush nuk e kërkoi dhe seancën pasi rikuperohet. Në çdo moment lexoni rrugën e parazgjedhur dhe bëni një kërkesë, adresa e daljes së së cilës është e dukshme. Një aplikacion që dorëzohet ndërsa tuneli është ulur nuk thotë asgjë për një klient poste ose një përditësues, prandaj përsëriteni kontrollin e fundit me një aplikacion në sfond. Shkruani rregullin, emrat e ndërfaqeve dhe hapat e rikuperimit, sepse një kill switch që askush nuk mund ta verifikojë është thjesht fjalë goje.