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, платформа ништа не блокира. Водич за VPN на Android-у описује то као одвојене могућности, а не један режим.

Провера 2: који слој држи блокаду?

Налепнице живе у клијенту, а блокаде обично у заштитном зиду, зато иста реч на свакој платформи значи нешто друго. Редови испод су они које вреди потврдити пре него што поверујете било коме од њих.

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 плус један намерни квар. Ред који не можете да испуните излазом команде је ред који нисте испробали, а уређај који прође ред поновног повезивања и падне на реду подизања довољно је чест да оправда додатних десет минута.

Пре него што то прогласите готовим:

• Потврдите да је подешавање блокаде одвојено од подешавања поновног повезивања и прочитајте његову вредност на уређају.
• Знајте који слој спроводи блокаду - опција клијента, политика уређаја или заштитни зид - и где се тај слој конфигурише.
• Сачувајте једну пробну команду која доказује блокаду и покрените је током прелаза, а не после.
• Запишите списак изузетака, укључујући крајњу тачку, и забележите ко га освежава.
• На управљаном хардверу оставите наметнуту политику на миру; уклањање блокаде мења захтев уместо да поправи тунел.