Изход или прекъсване: два различни резултата за VPN

Менюто предлага Прекъсване, прозорецът има бутон за затваряне, а диспечерът на задачи предлага Край на задачата. Всяко от тях изглежда като начин да спрете VPN, и всяко може да остави машината в различно състояние. Едно може да спре тунела, като остави блокирането на място, друго може да изчисти всичко като част от коректно излизане, а трето може само да скрие интерфейса, докато фоновият компонент продължава да работи. Да ги третирате като синоними е начинът, по който тест за поверителност стига до грешно заключение какво е станало.

Документацията на клиента е единственото надеждно място, където да научите кое кое е.

Четири контрола, вероятно четири поведения

Прекъсването обикновено разваля тунела, докато клиентът остава в паметта, което значи, че услуга, компонент в системната област или правило на kill switch може да преживее щракването. След това много клиенти продължават да блокират трафика, защото политиката им казва, че устройството не бива да пада към директен достъп, докато клиентът присъства. Това поведение изглежда като счупена мрежа и е умишлена защита.

Изходът е предназначен да завърши приложението и добре държащият се клиент премахва правилата си при излизане. Някои дизайни вместо това оставят отделен помощник, който налага политиката, и това е избор, а не дефект. Затварянето на прозореца е действие на интерфейса без определен ефект върху тунела, а Пауза, където се предлага, е четвърто поведение със свои правила.

Авария от страна на сървъра е напълно пети път и именно с него потребителите се сблъскват най-често.

Прочетете състоянието преди и след всяко действие

Запишете списъка с процеси, състоянието на услугата и правилата на защитната стена преди действието, после повторете записа веднага след него. Сравняването на двата списъка показва какво наистина е направил контролът, без да разчита на собственото описание на интерфейса.

systemctl status wg-quick@wg0 --no-pager
pgrep -a -f 'openvpn|wireguard|vpnagent'
ip link show | grep -E 'tun|wg'
nft list ruleset | grep -E 'drop|reject' | head -20
scutil --nc list

Ако правилата изчезнат заедно с процеса, клиентът е бил техен собственик. Ако правилата останат, докато процесът е изчезнал, нещо друго налага политиката, и намирането на този компонент идва преди всяка промяна. Запишете състоянието на услугата в същия момент, защото спрян интерфейс не казва нищо за системна услуга.

Ръчното прекъсване не е срив

Прекъсването изпълнява предвидения път за изключване, а сривът го пропуска. Затова резултатите от едното не се пренасят върху другото, така че тест, използвал елемент от менюто, не може да подкрепи твърдение за поведението, когато клиентът умре.

По същия начин сривът не ви казва нищо за одобрена временна пауза. Дръжте тези три въпроса отделно в тестовия план и във всичко, което се записва после. Пътят на изключване обяснява също защо коректен изход може да премахне правила, които сривът оставя. Същият бутон, различен код, различни доказателства.

Изберете недостъпното състояние, което наистина ви трябва

Ако трафикът трябва да остава блокиран винаги, когато тунелът е спрян, проверете това изискване по време на конкретното действие, което ви интересува, използвайки безвреден трафик към известна дестинация. Включете изключения за приложения и изключения за локалната мрежа, защото налагането за цялото устройство често е по-тясно, отколкото подсказва името му. След това потвърдете какво се случва след рестарт, защото тогава обикновено се появява остаряло състояние.

Ако целта е обикновен директен достъп, използвайте документирания контрол, вместо да убивате процеси или да изключвате цялата защитна стена. Остарелите правила, оставени от прекъснат изход, са различен проблем от умишленото заключване и изискват различно възстановяване.

Запишете кой компонент е спрял: тунелът, видимото приложение или слоят, който налага политиката. Това едно изречение предотвратява повечето объркване, което тези контроли създават.