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: кој слој го држи блокирањето?

Ознаките живеат во клиентот, а блокирањата обично во огнениот ѕид, затоа истиот збор значи различно на секоја платформа. Долните редови се тие што вреди да се потврдат пред да поверувате на било која од нив.

Where you see the labelWhat the label promisesWhat actually blocks
Android VPN profileAlways-on VPNBlock connections without VPN
Android device policyAlways-on packagelockdownEnabled flag
Windows built-in VPNAlways On tunnelOutbound firewall rules
WireGuard for WindowsTunnel serviceBlock untunneled traffic option
wg-quick on LinuxRoute via AllowedIPsYour own nftables or iptables rules

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

Пред да го наречете готово:

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

Поврзани статии