Always-on VPN немесе kill switch: шын мәнінде қайсысын қосқансыз?

Always-on мен kill switch бір баптау экранында екі жол қашықтықта тұрады, сондықтан адамдар оларды бір функцияның екі атауы ретінде оқиды. Олай емес. Always-on — қайта қосылу саясаты: жүктеу кезінде туннельді іске қосу, құлаудан немесе желі ауысқаннан кейін оны қайтару және ол сәтсіз болғанша қайталап көру. Kill switch — трафик саясаты: туннель өшіп тұрғанда қандай пакеттер машинадан шыға алатынын атайды. Біріншісін екіншісіз қосуға болады, және көптеген платформада әдепкі нәтиже сол аралықта трафикті сыртқа жібереді.

1-тексеру: бұғаттау жеке қосқыш па?

Android 10 және одан жаңа нұсқаларда сақталған VPN профилі тісті дөңгелек белгішесінің артында екі тәуелсіз қосқыш ашады: Always-on VPN және Block connections without VPN. Kill switch — тек екіншісі. Тек always-on болғанда туннель үзілістен кейін шынымен қайтады, ал сұраныс ортасындағы кез келген қолданба сол сәтке дейін Wi-Fi немесе мобильді деректер арқылы желіге шыға алады.

Басқарылатын құрылғылар саясат API-інде сол бөліністі сақтайды. setAlwaysOnVpnPackage() десте атауы мен lockdownEnabled жалаушасын қабылдайды; дестені орнатып, жалаушаны false күйінде қалдырған әкімші тұрақты туннель құрды, жабық құрылғы емес. Консольдегі тұжырым бұл айырмашылықты сирек көрсетеді.

Күйді консольден емес, құрылғыдан оқыңыз: adb shell settings get global always_on_vpn_app және adb shell settings get global always_on_vpn_lockdown. Егер біріншісі null қайтарса, платформа деңгейінде ешбір десте мәжбүрленбейді; егер екіншісі 0 қайтарса, платформа ештеңені бұғаттамайды. Android VPN нұсқаулығы оларды бір режим емес, бөлек мүмкіндіктер ретінде сипаттайды.

2-тексеру: бұғаттау қай қабаттың меншігінде?

Белгілер клиентте, ал бұғаттаулар әдетте firewall-де тұрады, сондықтан бір сөз әр платформада әртүрлі мағына береді. Төмендегі жолдар — кез келгеніне сенбес бұрын растауға тұрарлықтары.

Windows — бұғаттамайтын белгінің ең айқын мысалы. Онда Always On туннельдің тұрақтылығын сипаттайды: машина аутентификациясы үшін құрылғы туннелі, кірген тіркелгі үшін пайдаланушы туннелі, профиль XML немесе Add-VpnConnection арқылы бапталады. Бұл профильде туннель жоқ кезде шығыс пакетін тоқтататын ештеңе жоқ, ал шығыс сүзгілеу әдепкіде қосулы емес, сондықтан Wi-Fi-дағы ноутбук VPN өшіп тұрса да жұмысын жалғастырады.

WireGuard та дәл солай бөлінеді, бірақ клиент бойынша. WireGuard for Windows-те әр туннель үшін сүзгі ережелерін орнататын Block untunneled traffic опциясы бар; Linux құралдарында ондай қосқыш жоқ. wg-quick әр AllowedIPs жазбасы үшін маршрут және fwmark ережесін қосады, ал wg-quick down екеуін де жояды, сондықтан физикалық әдепкі маршрут бірде-бір пакет жоғалмай қайтадан өз міндетін алады.

Apple платформаларында always-on қадағаланатын құрылғылар үшін басқару профилінің функциясы ретінде келеді және құсбелгі емес, on-demand ережелері түрінде көрінеді. Пайдалы жүктемеден жауап беру керек сұрақ: сәтсіз туннель трафикті тыйяды ма, әлде тек басқа қосылым сұрайды ма. Мәзір тақырыбы мұны айтпайды.

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-тексерудегі ауысулар және бір әдейі ақау. Команда шығысымен толтыра алмайтын жол — тексерілмеген жол, ал қайта қосылу жолынан өтіп, жүктеу жолында құлайтын құрылғы жиі кездеседі, сондықтан қосымша он минутқа тұрарлық.

Оны бітті деп атамас бұрын:

• Бұғаттау баптауы қайта қосылу баптауынан бөлек екенін растап, оның мәнін құрылғыдан оқыңыз.
• Бұғаттауды қай қабат орындайтынын - клиент опциясы, құрылғы саясаты немесе firewall - және ол қабаттың қайда бапталатынын біліңіз.
• Бұғаттауды дәлелдейтін бір тексеру командасын сақтап, оны ауысу кезінде орындаңыз, кейін емес.
• Ерекшеліктер тізімін, соңғы нүктемен бірге, жазып, оны кім жаңартатынын белгілеңіз.
• Басқарылатын жабдықта мәжбүрленген саясатқа тиіспеңіз; бұғаттауды алып тастау туннельді жөндеудің орнына талапты өзгертеді.