Скрипта за гасење или firewall правило: што ја запира излеаната?

Два дизајна ветуваат исто: кога тунелот ќе падне, ништо не излегува надвор во отворен вид. Едното пушта скрипта при гасење и ги сече интерфејсите. Другото остава firewall правило на сила и не бара ништо од VPN клиентот. Тие се разликуваат по тоа кој има привилегија да дејствува, што се случува за време на празнината и како машината потоа се враќа на мрежата. Нивното споредување на тие три точки е покорисно од расправа за тоа кое е построго.

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

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

Таа табела е целиот аргумент. Скрипта што работи само при уредно затворање го покрива случајот за кој најмалку се грижевте; важниот случај е падот или мрежата што исчезнува, и ниту еден од нив не дава чисто гасење.

Што може и што не може куката за гасење

Документираната шема ги поминува мрежните интерфејси и го спушта сѐ освен 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 што никој не може да го провери е само гласина.