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 плюс адзін наўмысны збой. Радок, які вы не можаце запоўніць вывадам каманды, - гэта радок, які вы не правяралі, а прылада, якая праходзіць радок перападключэння і правальвае радок загрузкі, сустракаецца досыць часта, каб каштаваць дадатковых дзесяці хвілін.

Перш чым назваць гэта завершаным:

• Пераканайцеся, што налада блакавання асобная ад налады перападключэння, і прачытайце яе значэнне на прыладзе.
• Ведайце, які слой ужывае блакіроўку - опцыя кліента, палітыка прылады або фаер - і дзе гэты слой наладжаны.
• Трымайце адну каманду праверкі, якая даказвае блакіроўку, і запускайце яе падчас пераходу, а не пасля.
• Запішыце спіс выключэнняў, уключаючы канцавы пункт, і адзначце, хто яго абнаўляе.
• На кіраваным абсталяванні пакіньце ўжытую палітыку; зняцце блакіроўкі змяняе патрабаванне, а не рамантуе тунель.