Down script o firewall rule: alin ang pumipigil sa pagtagas?

Dalawang disenyo ang nangangako ng parehong bagay: kapag bumagsak ang tunel, walang lumalabas nang hayagan. Ang isa ay nagpapatakbo ng script sa pagbaba at pumuputol ng mga interface. Ang isa ay nag-iiwan ng firewall rule na may bisa at walang hinihingi sa VPN client. Nagkakaiba sila sa kung sino ang may pribilehiyong kumilos, sa nangyayari sa puwang at sa kung paano bumabalik sa online ang makina pagkatapos. Ang paghahambing sa kanila sa tatlong puntong iyon ay mas kapaki-pakinabang kaysa magtalo kung alin ang mas mahigpit.

Parehong trabaho sa dalawang paraan

Maaaring magpatakbo ng mga hook ang client kapag umaangat ang tunel at kapag ibinababa ito, kung pinapayagan ng profile ang pagpapatakbo ng script. Ang hook na iyon ay tumatakbo sa loob ng siklo ng buhay ng client, sa sandaling nagsasara ang koneksyon. Ang firewall rule naman ay pag-aari ng system at walang pakialam kung tumatakbo ang client, nag-crash o pinatay.

Ang talahanayang iyon ang buong argumento. Ang script na tumatakbo lamang sa maayos na pagsasara ay sumasaklaw sa kaso na pinakamababa ang inaalala mo; ang mahalagang kaso ay ang pag-crash o ang pagkawala ng network, at wala sa dalawa ang nagbibigay ng malinis na pagbaba.

Ano ang kaya at hindi kaya ng hook sa pagbaba

Ang dokumentadong padron ay dumadaan sa mga interface ng network at ibinababa ang lahat maliban sa loopback. Kapag nakababa ang pisikal na aparato, walang makakatakas sa labas ng tunel, at iyon mismo ang layunin.

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

Ibinababa rin nito ang lokal na network, anumang serbisyong hino-host ng makina, at ang landas na gagamitin mo upang ayusin ang problema. Sa laptop, kailangan minsan ng manu-manong pag-switch ng wireless device pagkatapos, kaya nagiging sesyon ng pagkukumpuni ang maikling pagkaantala. Mas masahol pa, maaaring hindi pinapayagan ang hook na gawin ang alinman sa mga iyon: kapag bumitiw ang client sa mga pribilehiyo, tumatakbo ang script sa pagbaba sa account na walang pribilehiyo, at bawat pagbabago ng interface ay nabibigo nang may error sa pahintulot na isinusulat sa sandaling walang nagbabasa ng log.

Tingnan kung paano sinisimulan ang client bago magtiwala sa hook. Ang script na gumagana kapag pinatakbo mo nang manu-mano bilang root ay walang pinatutunayan tungkol sa serbisyong nagsisimula sa boot.

Ano ang iba pang ginagawa ng firewall rule

Ang rule na nagpapahintulot lamang sa trapiko ng tunel ay patuloy na gumagana kapag wala na ang proseso ng client, dahil hindi umaasa ang kernel sa prosesong iyon. Mas makitid din ang rule: hinaharangan nito ang eksaktong mga daloy na tinutugma nito at hinahayaan ang loopback, lokal na subnet at landas ng pagbawi, kaya hindi nito iniiwan ang makina sa kawalan ng daan.

Ang kabayaran ay kailangang isulat at panatilihin ang rule ng nagmamay-ari ng firewall ng host, at kailangan nitong pangalanan ang aparato ng tunel na aktwal na nililikha ng client. Ibig sabihin, kailangang panatilihing magkasama ang rule at profile; ang interface na pinalitan ng pangalan ay nag-iiwan ng firewall na humaharang sa lahat at walang ipinapaliwanag.

Hindi ginagawang kalabisan ng alinmang paraan ang isa. Ang firewall rule na hindi kailanman muling ikinakarga pagkatapos ng pag-edit ay kasing gawa-gawa ng script na hindi kailanman tumatakbo.

persist-tun ang nagpapasya kung may puwang

Kapag nakaligtas ang aparato ng tunel sa pagkadiskonekta, nakaliligtas din ang mga ruta na papasok dito. Itinatapon na noon ang trapiko sa halip na i-redirect, kaya hindi bumabalik ang default na ruta sa pisikal na gateway. Ito ang pag-uugaling nagpapababa ng tsansang magtagas bago pa man may kasangkot na firewall rule.

Kung wala ang setting na iyon, tinatanggal ang aparato kasama ang mga ruta, at maaaring muling ituro ng default na ruta ang pisikal na gateway. Kung gagawin nito iyon ay depende sa platform at client, at iyon mismo ang dahilan kung bakit dapat obserbahan ang estado at hindi ipalagay. Ituring ang setting na bahagi ng kill switch, hindi opsyon sa pagganap.

Panatilihing buhay ang landas ng muling pagkonekta, pagkatapos subukan ang apat na estado

Ang mahigpit na pagharang ay maaari ring pumigil sa client na muling kumonekta, dahil kailangan pa rin ng client ng rutang patungo sa server sa pamamagitan ng pisikal na gateway habang tinatanggihan ang lahat ng iba. Mag-install ng host route para sa nag-iisang address na iyon bago umangat ang tunel, at lutasin muna ang pangalan, dahil maaaring naka-block ang DNS sa oras na kailanganin mo ito.

ip route add 198.51.100.20/32 via 192.168.0.1 dev wlan0

Pagkatapos, i-verify ang mga estado at hindi ang label. Sadyang danasin ang apat na sandali: malamig na pagsisimula na walang tunel, malusog na sesyon, pagbagsak na walang humingi, at ang sesyon pagkatapos makabawi. Sa bawat sandali basahin ang default na ruta at gumawa ng isang kahilingan na nakikita ang address ng labasan. Ang application na sumusuko habang nakababa ang tunel ay walang sinasabi tungkol sa mail client o updater, kaya ulitin ang huling pagsusuri sa isang background na application. Isulat ang rule, ang mga pangalan ng interface at ang mga hakbang sa pagbawi, dahil ang kill switch na walang makapag-verify ay tsismis lamang.