Скрипта за спуштање или 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, не као опцију перформанси.
Одржите путању поновног повезивања живом, па тестирајте четири стања
Строг блок може спречити и поновно повезивање клијента, јер клијенту и даље треба рута до сервера кроз физичку капију док је све остало забрањено. Инсталирајте host руту за ту једну адресу пре него што се тунел подигне и прво разрешите име, јер DNS може бити блокиран до тренутка када вам затреба.
ip route add 198.51.100.20/32 via 192.168.0.1 dev wlan0
Затим проверите стања, а не ознаку. Намерно прођите кроз четири тренутка: хладан старт без тунела, здраву сесију, прекид који нико није тражио и сесију после опоравка. У сваком тренутку прочитајте подразумевану руту и упутите један захтев чија је излазна адреса видљива. Апликација која одустане док је тунел спуштен не говори ништа о поштанском клијенту или ажурирању, па поновите последњу проверу са једном позадинском апликацијом. Запишите правило, називе интерфејса и кораке опоравка, јер kill switch који нико не може проверити је гласина.