Always-on VPN или kill switch: кое всъщност включихте?

Always-on и kill switch стоят на два реда в един и същ екран с настройки, затова хората ги четат като две имена на една функция. Не са. Always-on е политика за повторно свързване: стартира тунела при зареждане, връща го след срив или смяна на мрежата и продължава да опитва, докато не успее. Kill switch е политика за трафик: той назовава пакетите, които още могат да напуснат машината, докато тунелът е спрян. Можете да включите първото без второто и на повечето платформи резултатът по подразбиране все още пуска трафик в промеждутъка.

Проверка 1: блокадата отделен превключвател ли е?

На Android 10 и по-нови запазен профил на VPN отваря зад иконата на зъбното колело два независими превключвателя: Always-on VPN и Блокиране на връзки без VPN. Само вторият е kill switch. Само с always-on тунелът се връща след прекъсване, но всяко приложение по средата на заявка достига мрежата през Wi-Fi или мобилни данни, докато това стане.

Управляваните устройства пазят същото разделение в API за политики. setAlwaysOnVpnPackage() приема името на пакета и флаг lockdownEnabled; администратор, който зададе пакета и остави флага неверен, е построил постоянен тунел, а не затворено устройство. Формулировката в конзолата рядко показва тази разлика.

Четете състоянието от устройството, не от конзолата: adb shell settings get global always_on_vpn_app и adb shell settings get global always_on_vpn_lockdown. Ако първата върне null, на платформено ниво не е наложен пакет; ако втората върне 0, платформата не блокира нищо. Ръководството за VPN в Android описва тези като отделни възможности, а не като един режим.

Проверка 2: кой слой притежава блокадата?

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

Windows е най-ясният пример за етикет, който не блокира. Always On там описва устойчивост на тунела: тунел за устройството при машинно удостоверяване, потребителски тунел за вписания акаунт, конфигурирани чрез XML на профила или Add-VpnConnection. Нищо в този профил не спира изходящ пакет, когато тунелът липсва, а изходящата филтрация не е включена по подразбиране, така че лаптоп на Wi-Fi продължава да работи, докато VPN е спрян.

WireGuard се разделя по същия начин, но по клиент. WireGuard за Windows има опция за всеки тунел Блокиране на трафик извън тунела, която инсталира филтърни правила; инструментите за Linux нямат такъв превключвател. wg-quick добавя маршрут за всеки запис AllowedIPs плюс правило fwmark, а wg-quick down премахва и двете, така че физическият маршрут по подразбиране поема отново без загубен пакет между тях.

На платформите на Apple always-on идва като функция на профил за управление за наблюдавани устройства и се изразява като правила при поискване, а не като отметка. Въпросът от полезния товар е дали неуспешният тунел отказва трафик, или само иска друга връзка. Заглавието на менюто няма да ви каже.

Проверка 3: измерете промеждутъка, не иконата

Четири прехода имат значение и се провалят различно: зареждане, преди някой да влезе, сън и събуждане, смяна от Wi-Fi към мобилни данни и срив на клиента, който оставя интерфейса на тунела наполовина конфигуриран. Чисто повторно свързване при един от тях не доказва нищо за другите три.

Най-евтиният тест спира тунела нарочно и после се опитва да излезе. При спрян тунел curl -m 5 -sS -o /dev/null -w '%{http_code}' https://example.com с връщане 200 означава, че политиката е fail-open; изтичане на времето или отказана връзка означава, че нещо още блокира. ip route get 1.1.1.1 назовава интерфейса, който би пренесъл пакета, което обикновено говори повече от иконата в системния трей, а systemctl status wg-quick@wg0 показва дали интерфейсът е премахнат чисто.

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

Проверка 4: решете изключенията, преди да заключите

Две изключения са структурни. Клиентът трябва да достигне самия сървър на VPN, затова набор от правила, който изхвърля всичко, предотвратява и повторното свързване, което би възстановило защитата. Captive portal също не е достъпен през тунел, който не работи, затова заключено устройство на хотелски Wi-Fi се нуждае от документиран начин да отвори портала, а не от импровизиран.

Минимална форма, крайната точка разрешена, всичко останало изхвърлено:

table inet vpnlock {
  chain output {
    type filter hook output priority 0; policy drop;
    oifname "lo" accept
    ip daddr 203.0.113.10 udp dport 51820 accept
    oifname "wg0" accept
  }
}

Отнасяйте се към този ред за крайната точка като към променлива, не като към константа. Доставчиците сменят адреси и остарялото изключение е обичайната причина работещ kill switch да се превърне в устройство, което не може да се свърже. Локалните принтери, споделените ресурси NAS и услугите за разработка принадлежат в същия писмен списък, иначе се откриват по едно запитване до поддръжката.

Проверка 5: запишете какво наистина доказахте

Дръжте টেবিল с четири колони и я попълвайте с тестове: състояние, очаквано поведение, наблюдавано поведение, доказателство. Редовете са преходите от проверка 3 плюс един умишлен провал. Ред, който не можете да попълните с изход от команда, е ред, който не сте тествали, а устройство, което минава реда за повторно свързване и се проваля на реда за зареждане, е достатъчно често, за да си струват допълнителните десет минути.

Преди да го обявите за готово:

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