Два дизајна обећавају исто: када тунел падне, ништа не излази напоље у отвореном облику. Један покреће скрипту при спуштању и сече интерфејсе. Други оставља firewall правило на снази и не тражи ништа од VPN клијента. Разликују се по томе ко има привилегију да делује, шта се дешава током празнине и како се машина после враћа на мрежу. Упоређивати их по те три тачке корисније је него расправљати које је строже.

Исти посао кроз два механизма

Клијент може покретати куке када се тунел подигне и када се спушта, ако профил дозвољава извршавање скрипти. Та кука ради унутар животног циклуса клијента, у тренутку када се веза затвара. Firewall правило, насупрот томе, припада систему и не занима га ради ли клијент, срушио се или је убијен.

PropertyTeardown scriptFirewall unit
Runs when the client is killedNoYes
Needs privilege at teardown timeUsually yesConfigured once, at boot
Acts on the whole machineOften, including recovery pathsOnly 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, не као опцију перформанси.

Одржите путању поновног повезивања живом, па тестирајте четири стања

Строг блок може спречити и поновно повезивање клијента, јер клијенту и даље треба рута до сервера кроз физичку капију док је све остало забрањено. Инсталирајте host руту за ту једну адресу пре него што се тунел подигне и прво разрешите име, јер DNS може бити блокиран до тренутка када вам затреба.

ip route add 198.51.100.20/32 via 192.168.0.1 dev wlan0

Затим проверите стања, а не ознаку. Намерно прођите кроз четири тренутка: хладан старт без тунела, здраву сесију, прекид који нико није тражио и сесију после опоравка. У сваком тренутку прочитајте подразумевану руту и упутите један захтев чија је излазна адреса видљива. Апликација која одустане док је тунел спуштен не говори ништа о поштанском клијенту или ажурирању, па поновите последњу проверу са једном позадинском апликацијом. Запишите правило, називе интерфејса и кораке опоравка, јер kill switch који нико не може проверити је гласина.

Повезани чланци