Оцелява ли аварийният прекъсвач на VPN след рестарт? Как да го проверите

Рестартът е най-разпространеният начин хората да тестват авариен прекъсвач и именно този тест най-често лъже. Отметката в клиента е предпочитание; важно е дали нещо налага блокиране между момента, в който мрежовият стек се вдига, и момента, в който тунелът действително е установен. В Windows това нещо обикновено е филтър в Windows Filtering Platform, в Linux — набор от правила, зареден от unit, в macOS — котва на pf, в Android — собствените флагове на системата за винаги включен режим и заключване. Тези уредби се държат много различно при рестарт и само тези на ниво платформа са налице, преди някой да може да влезе.

Рестартът задава три отделни въпроса

Разделете въпроса. Първо, съществува ли политиката на диска във форма, която нещо чете при зареждане? Второ, стартира ли този четец, преди какъвто и да е трафик да излезе? Трето, покрива ли политиката трафика, който ви интересува, тоест всеки процес, двете семейства адреси и DNS. „Да“ на първото и „не“ на второто дава точно тази повреда, която хората описват като авариен прекъсвач, който не оцелява след рестарт: трафикът излиза за няколко секунди при стартиране и никой не го забелязва, докато не тръгне да търси.

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

Намерете обекта, който възстановява блокирането

В Linux правилата на netfilter живеят в ядрото. Нищо не ги записва обратно при зареждане, освен ако не сте го уредили: iptables-save плюс netfilter-persistent, nftables.service зарежда /etc/nftables.conf, или systemd unit, който изпълнява вашия собствен скрипт. Проверете какво е включено, вместо какво си спомняте, че сте настройвали.

systemctl is-enabled nftables netfilter-persistent 2>/dev/null
sudo nft list ruleset
sudo iptables -S OUTPUT

Празен набор правила няколко секунди след зареждане е отговорът на въпроса от заглавието. В Windows попитайте услугата на клиента как стартира, после извадете състоянието на филтъра на платформата, докато тунелът е спуснат.

Get-Service | Where-Object { $_.Name -match 'vpn' } | Select-Object Name, Status, StartType
netsh wfp show state

Втората команда записва wfpstate.xml в текущата директория. Търсете филтри с действие за блокиране, които вече съществуват, преди клиентът да се свърже. Base Filtering Engine стартира рано при зареждане и възстановява филтри, добавени с постоянен флаг, затова някои аварийни прекъсвачи блокират трафика преди да съществува какъвто и да е прозорец на клиента, а други не. В macOS sudo pfctl -s info съобщава дали pf е включен, sudo pfctl -s rules показва какво е заредено, а VPN клиентите обикновено прикачват правилата си към котва, а не към основния набор. Правило, което назовава utun3 може да сочи към друг интерфейс след следващото зареждане, защото този номер се задава по време на работа.

Наблюдавайте пролуката между вдигането на мрежата и вдигането на тунела

Опасният интервал не е целият рестарт, а пролуката. Интерфейсът получава наем и маршрут по подразбиране в един момент, VPN услугата стартира в друг, а тунелът се удостоверява още по-късно, понякога само след като потребител влезе и стартира агент за идентификационни данни. Ако блокирането се приложи последно, всичко в пролуката излиза в открит вид.

На systemd хостове четете подредбата, вместо да я гадаете. Изпълнете systemctl cat върху unit-ите на VPN и защитната стена и потърсете After= или Before= спрямо network-pre.target и network-online.target. Unit на защитна стена, подреден след network-online.target губи от интерфейса; този, който е изискван от и подреден преди network-pre.target печели. В Windows еквивалентните въпроси са типът на стартиране на услугата и нейните зависимости, защото услуга, зададена на Manual, не може да блокира процес по време на зареждане. Ако изискването ви включва трафик преди вход, го удовлетворява само уредба на ниво устройство: тунел на устройство Always On VPN се удостоверява с машинен сертификат и се свързва преди потребителят да влезе, и Microsoft документира конфигурацията на тунела на устройството отделно от потребителския тунел. Android поема другия път, като налага винаги включен VPN и блокира връзките без него от системата, а не от процес на приложение.

Изпълнете теста, после сравнете две времеви линии

Рестартирайте с дестинация, която не струва нищо, ако изтече, и снемайте състояние по време на пролуката, а не след нея. Най-чистият метод е сонда при зареждане: oneshot unit или планирана задача, която стартира възможно най-рано, записва маршрута по подразбиране и състоянието на защитната стена, прави една заявка с кратък таймаут и добавя ред към локален файл. Сравнете този запис с часа на стартиране на VPN услугата от journalctl -b -u или системния журнал.

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

Затворете пролуката, без да си отрежете пътя обратно

Ако блокирането липсва при зареждане, преместете налагането слой по-надолу, вместо да добавяте второ клиентско правило. Запазете набора правила и го зареждайте от unit, подреден преди мрежата да е използваема, и се уверете, че този unit не се нуждае от DNS заявка или мрежово монтиране, което трябва да защитава. Обхватът е толкова важен, колкото и времето: правила, съпоставени по потребителски ID или cgroup, оставят всеки системен демон извън блокирането, а набор правила, който обработва само IPv4, оставя IPv6 и DNS достъпни.

Оставете си път обратно. Машина, която блокира всичко при зареждане и после не може да се удостовери, няма мрежа изобщо, а поправката не е да изтриете блокирането, а да поправите идентификационните данни или подредбата. Пазете документирана процедура за локална конзола и тясно, съзнателно изключение за това, от което тунелът наистина се нуждае, например адреса на сървъра и резолвера, използван преди тунелът да съществува.

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