Да ли заштитни прекидач VPN преживљава рестартовање? Како то проверити

Рестартовање је најчешћи начин на који људи тестирају заштитни прекидач, и то је тест који најчешће лаже. Поље за потврду у клијенту је само подешавање; важно је да ли нешто намеће блокирање између тренутка када се мрежни стек подигне и тренутка када је тунел заиста успостављен. На Windows-у то нешто је обично филтер у Windows Filtering Platform, на Linux-у скуп правила који учитава јединица, на macOS-у сидро pf, на Android-у сопствене заставице система за стално-укључено и закључавање. Ови распореди се понашају веома различито током рестартовања, и само они на нивоу платформе су на месту пре него што било ко може да се пријави.

Рестартовање поставља три одвојена питања

Поделите питање. Прво, да ли политика постоји на диску у облику који нешто чита при подизању? Друго, да ли се тај читач извршава пре него што било који саобраћај може да изађе? Треће, да ли политика покрива саобраћај који вас занима, то јест сваки процес, обе породице адреса и DNS. Да на прво и не на друго стварају тачно онај дефект који људи пријављују као заштитни прекидач који не преживљава рестартовање: саобраћај при покретању неколико секунди изађе напоље, и нико то не примети док неко не оде да провери.

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

Пронађите објекат који обнавља блокирање

На Linux-у правила netfilter-а живе у језгру. Ништа их не записује назад при подизању осим ако то нисте уредили: iptables-save плус netfilter-persistent, nftables.service учитава /etc/nftables.conf, или systemd јединица која извршава вашу сопствену скрипту. Проверите шта је омогућено, уместо онога чега се сећате да сте подесили.

systemctl is-enabled nftables netfilter-persistent 2>/dev/null
sudo nft list ruleset
sudo iptables -S OUTPUT

Празан скуп правила неколико секунди после подизања је одговор на питање из наслова. На Windows-у питајте услугу клијента како се покреће, затим извуците стање филтера платформе док је тунел спуштен.

Get-Service | Where-Object { $_.Name -match 'vpn' } | Select-Object Name, Status, StartType
netsh wfp show state

Друга команда записује wfpstate.xml у текући директоријум. Тражите филтере са дејством блокирања који већ постоје пре него што се клијент повеже. Base Filtering Engine се покреће рано при подизању и обнавља филтере додате са трајном заставицом, зато неки заштитни прекидачи блокирају саобраћај пре него што постоји било који прозор клијента, а други не. На macOS-у sudo pfctl -s info извештава да ли је pf омогућен, sudo pfctl -s rules показује шта је учитано, а VPN клијенти обично причвршћују своја правила за сидро уместо за главни скуп. Правило које именује utun3 може после следећег подизања да показује на други интерфејс, јер се тај број додељује током извршавања.

Пратите јаз између подизања мреже и подизања тунела

Опасни интервал није цело рестартовање, то је јаз. Интерфејс у једном тренутку добија закуп и подразумевану руту, VPN услуга се покреће у другом, а тунел се аутентификује још касније, понекад тек после тога што се корисник пријави и изврши агент акредитива. Ако се блокирање примени последње, све у јазу излази откривено.

На systemd домаћинима читајте редослед уместо да га погађате. Извршите systemctl cat на VPN и јединицама заштитног зида и тражите After= или Before= према network-pre.target и network-online.target. Јединица заштитног зида поређана после network-online.target губи од интерфејса; она која је тражена од и поређана пре network-pre.target побеђује. На Windows-у еквивалентна питања су тип покретања услуге и њене зависности, јер услуга постављена на Manual не може да блокира процес при подизању. Ако ваш захтев укључује саобраћај пре пријаве, задовољава га само распоред на нивоу уређаја: тунел уређаја Always On VPN се аутентификује сертификатом машине и повезује пре него што се корисник пријави, и Microsoft документује конфигурацију тунела уређаја одвојено од корисничког тунела. Android иде другим путем, намеће стално укључен VPN и блокира везе без њега из система, а не из процеса апликације.

Извршите тест, затим упоредите две временске линије

Рестартујте са одредиштем које ништа не кошта ако процури, и забележите стање током јаза, а не после њега. Најчистији метод је сонда при подизању: oneshot јединица или заказани задатак који се покреће најраније што платформа дозвољава, бележи подразумевану руту и стање заштитног зида, покушава један захтев са кратким временским ограничењем и додаје ред у локалну датотеку. Упоредите тај запис са временом почетка VPN услуге из journalctl -b -u или системског дневника.

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

Затворите јаз без тога да си пресечете пут назад

Ако блокирање недостаје при подизању, спустите спровођење један слој ниже уместо да додате друго клијентско правило. Сачувајте скуп правила и учитајте га из јединице поређане пре него што мрежа постане употребљива, и уверите се да тој јединици не треба DNS претрага или мрежно монтирање које треба да штити. Обухват је важан колико и време: правила која се поклапају са корисничким ID-ом или cgroup-ом остављају сваки системски демон изван блокирања, а скуп који обрађује само IPv4 оставља IPv6 и DNS доступним.

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

Пре него што поверујете овом распореду, потврдите четири ствари по реду. Политика је сачувана тамо где је чита подизање. Тај читач се извршава пре него што интерфејс постане употребљив. Блокирање покрива обе породице адреса и DNS. VPN још може да се аутентификује док је блокирање активно. Када сва четири важе, рестартовање не мења ништа.