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