Скрипт за спиране или правило на защитна стена: кое спира изтичането?

Два дизайна обещават едно и също: когато тунелът падне, нищо не излиза навън в открит вид. Единият пуска скрипт при спиране и реже интерфейси. Другият оставя правило на защитна стена в сила и не иска нищо от VPN клиента. Те се различават по това кой има право да действа, какво се случва по време на пролуката и как машината после се връща онлайн. Сравняването им по тези три точки е по-полезно от спор кое е по-строго.

Същата работа чрез два механизма

Клиентът може да пуска куки при вдигане на тунела и при спирането му, ако профилът разрешава изпълнение на скриптове. Тази кука работи в жизнения цикъл на клиента, в момента, когато връзката се затваря. Правилото на защитна стена, за разлика от това, се притежава от системата и не го интересува дали клиентът работи, е паднал или е бил убит.

Тази таблица е целият аргумент. Скрипт, който работи само при нормално затваряне, покрива случая, за който се тревожехте най-малко; важният случай е сривът или изчезването на мрежата, а нито един от двата не дава чисто спиране.

Какво може и какво не може куката за спиране

Документираният модел обхожда мрежовите интерфейси и сваля всичко освен loopback. Със свалено физическо устройство нищо не може да излезе извън тунела, което е точно целта.

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

Той сваля също локалната мрежа, всяка услуга, която машината хоства, и пътя, който бихте използвали да поправите проблема. На лаптоп безжичното устройство понякога се нуждае от ръчно превключване после, така че кратко прекъсване се превръща в сесия за ремонт. По-лошо, на куката може да не е разрешено да прави нищо от това: когато клиентът се откаже от права, скриптът за спиране работи с непривилегирован акаунт и всяка промяна на интерфейс се проваля с грешка за права, записана в момента, в който никой не чете журнала.

Проверете как се стартира клиентът, преди да се доверите на куката. Скрипт, който работи при ръчно пускане като root, не доказва нищо за услугата, която стартира при зареждане.

Какво прави правилото на защитна стена различно

Правило, което разрешава само трафик на тунела, продължава да работи, когато процесът на клиента е изчезнал, защото ядрото не зависи от този процес. Правилото е и по-тясно: блокира точно потоците, на които отговаря, и оставя loopback, локалната подмрежа и пътя за възстановяване на мира, затова не оставя машината без изход.

Разменната цена е, че правилото трябва да бъде написано и поддържано от този, който притежава защитната стена на хоста, и то трябва да назове тунелното устройство, което клиентът действително създава. Това означава, че правилото и профилът трябва да се поддържат заедно; преименуван интерфейс оставя защитна стена, която блокира всичко и не обяснява нищо.

Нито един механизъм не прави другия излишен. Правило на защитна стена, което никога не се презарежда след редакция, е толкова измислено, колкото скрипт, който никога не се изпълнява.

persist-tun решава дали има пролука

Когато тунелното устройство оцелее след прекъсване, маршрутите, които сочат към него, също оцеляват. Тогава трафикът се изхвърля, а не се пренасочва, така че маршрутът по подразбиране не пада обратно към физическия шлюз. Това е поведението, което прави изтичането малко вероятно още преди намесата на каквото и да е правило.

Без тази настройка устройството се премахва заедно с маршрутите и маршрутът по подразбиране може отново да сочи към физическия шлюз. Дали ще го направи зависи от платформата и клиента, поради което състоянието трябва да се наблюдава, а не да се предполага. Приемайте настройката като част от kill switch, не като опция за производителност.

Пазете пътя за повторно свързване жив, после проверете четири състояния

Строга блокада може също да попречи на клиента да се свърже отново, защото клиентът все още се нуждае от маршрут до сървъра през физическия шлюз, докато всичко останало е забранено. Инсталирайте хост маршрут за този един адрес преди тунелът да се вдигне и първо разрешете името, защото DNS може да е блокиран до момента, в който ви потрябва.

ip route add 198.51.100.20/32 via 192.168.0.1 dev wlan0

После проверявайте състоянията, а не етикета. Упражнете четири момента нарочно: студен старт без тунел, здравословна сесия, отпадане, което никой не е поискал, и сесията след възстановяването. Във всеки момент прочетете маршрута по подразбиране и направете една заявка, чийто изходен адрес се вижда. Приложение, което се отказва, докато тунелът е свален, не казва нищо за пощенски клиент или програма за обновяване, затова повторете последната проверка с едно фоново приложение. Запишете правилото, имената на интерфейсите и стъпките за възстановяване, защото kill switch, който никой не може да провери, е слух.