Скрипт вимкнення чи правило брандмауера: що зупиняє витік?

Опускати інтерфейси під час розриву — грубо, і часто це виконується без прав. Порівняйте з правилом брандмауера, яке переживає обрив і закриває щілину.

Дві схеми обіцяють те саме: коли тунель падає, ніщо не виходить назовні у відкритому вигляді. Одна запускає під час згортання скрипт і ріже інтерфейси. Інша лишає правило брандмауера чинним і нічого не вимагає від клієнта VPN. Вони різняться тим, хто має право діяти, що відбувається в щілині і як машина потім повертається в мережу. Порівнювати їх за цими трьома пунктами корисніше, ніж сперечатися, яка схема суворіша.

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

Клієнт може запускати гаки під час підняття тунелю і під час його згортання, якщо профіль дозволяє виконання скриптів. Цей гак працює всередині життєвого циклу клієнта, у момент, коли з’єднання закривається. Правило брандмауера, навпаки, належить системі й не цікавиться, чи клієнт працює, чи впав, чи був убитий.

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, нічого не доводить про службу, що стартує під час завантаження.

Що правило брандмауера робить інакше

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

Ціна в тому, що правило має написати й підтримувати той, хто володіє брандмауером хоста, і воно має назвати пристрій тунелю, який клієнт справді створює. Це означає, що правило і профіль треба підтримувати разом; перейменований інтерфейс лишає брандмауер, який блокує все і нічого не пояснює.

Жоден механізм не робить інший зайвим. Правило брандмауера, яке після правки ніколи не перечитується, таке ж вигадане, як скрипт, який ніколи не запускається.

persist-tun вирішує, чи є щілина

Коли пристрій тунелю переживає розрив, переживають і маршрути, що ведуть у нього. Тоді трафік відкидається, а не перенаправляється, тож маршрут за замовчуванням не повертається на фізичний шлюз. Саме ця поведінка робить витік малоймовірним ще до участі будь-якого правила брандмауера.

Без цього налаштування пристрій видаляється разом із маршрутами, і маршрут за замовчуванням може знову вказувати на фізичний шлюз. Чи зробить він це, залежить від платформи й клієнта, і саме тому стан треба спостерігати, а не припускати. Вважайте налаштування частиною kill switch, а не параметром продуктивності.

Тримайте шлях перепідключення живим, потім перевірте чотири стани

Суворе блокування може завадити й перепідключенню, адже клієнтові все ще потрібен маршрут до сервера через фізичний шлюз, поки все інше заборонено. Установіть маршрут хоста для цієї однієї адреси до підняття тунелю і спершу розв’яжіть ім’я, бо DNS може бути заблокований на той момент, коли він знадобиться.

ip route add 198.51.100.20/32 via 192.168.0.1 dev wlan0

Далі перевіряйте стани, а не ярлик. Пройдіть чотири моменти навмисно: холодний старт без тунелю, здорова сесія, обрив, якого ніхто не просив, і сесія після відновлення. У кожен момент прочитайте маршрут за замовчуванням і зробіть один запит, чия адреса виходу видима. Застосунок, що здається, поки тунель опущено, нічого не каже про поштовий клієнт чи оновлювач, тому повторіть останню перевірку з одним фоновим застосунком. Запишіть правило, назви інтерфейсів і кроки відновлення, бо kill switch, який ніхто не може перевірити, — це лише чутка.

Схожі статті