Kill switch у спісе функцый амаль нічога не кажа пра тое, што адбываецца, калі тунель падае. Адна рэалізацыя закрывае вылучаныя працэсы, другая ставіць фільтры пакетаў на мяжы аперацыйнай сістэмы, а трэцяя проста спрабуе перападключыцца. Розніца праяўляецца ў секундах пасля збою, а не на экране налад. Прайдзіце гэтыя праверкі па парадку і спыніцеся на першай, на якую не можаце адказаць сумленна, бо менавіта там канчаецца ваша рэальнае пакрыццё.

Спачатку назавіце механізм прымусу

Спыненне працэсаў — гэта функцыя жыццёвага цыкла праграмы. Яна знаходзіць вылучаныя праграмы пасля выяўленага збою тунеля і закрывае іх. Усё, што не з’яўляецца галоўным працэсам, выжывае: дапаможныя службы, фонавая сінхранізацыя і любая праграма, запушчаная на секунду пазней, маюць свой жыццёвы цыкл і свой тэрмін.

Фільтраванне пакетаў — гэта функцыя аперацыйнай сістэмы. Яно адмаўляе трафіку, які не ідзе дазволеным шляхам, што з’яўляецца мацнейшым абяцаннем, але толькі ў межах таго, чаму сапраўды адпавядае правіла. Сямейства адрасоў, інтэрфейс, выключаныя праграмы і выключэнні вырашаюць гэта, а не надпіс у кліенце.

Ці перажывае блакаванне кліент?

Задайце чатыры пытанні ў такім парадку: што адбываецца пры збоі, пры ручным выхадзе, пры выхадзе з сістэмы і пры перазагрузцы. Правіла, якое падтрымлівае сам кліент, звычайна выдаляецца падчас карэктнага завяршэння і часта застаецца пасля збою. Правіла, усталяванае ў сховішча платформы, можа паводзіць сябе наадварот: перажываць і кліент, і часам дэінсталяцыю.

Зачыніце кліент пасярэдзіне доўгага спампоўвання і паглядзіце, ці спыніцца перадача, ці працягнецца.

Шукайце стандартныя дзіркі

IPv6 — першая. Правіла, напісанае для адрасоў IPv4, пакідае трафік IPv6 некранутым, і многія кліенты пішуць толькі палову v4. Другая — інтэрфейс: USB-тэтэрынг, другі Wi-Fi адаптар і сотавы мадэм могуць не ўваходзіць у правіла, абмежаванае асноўным злучэннем. Выключаныя праграмы і выключэнні лакальнай сеткі — трэцяя.

У Windows можна прачытаць усталяваныя правілы замест таго, каб давяраць перамыкачу: Get-NetFirewallRule -DisplayName '*VPN*' і netsh wfp show filters паказваюць, што існуе. У Linux iptables -S, ip6tables -S і nft list ruleset пакрываюць звычайныя выпадкі, і параўнанне ўсіх трох — гэта і ёсць мэта.

DNS — звычайная ўцечка

Блакаванне TCP, калі UDP 53 застаецца адкрытым, дае вам вельмі пераканаўчы kill switch, які ўсё яшчэ адказвае на кожны запыт імя хоста. Тое ж тычыцца выпадку, калі DNS перадаецца рэзалверу на іншым інтэрфейсе, або калі кліент блакуе толькі v4, а рэзалвер даступны праз v6.

Калі тунель ляжыць, развяжыце адно вядомае імя і паглядзіце, ці вернецца адказ. Калі вернецца, трафік не заблакаваны цалкам, што б ні казала іконка стану.

Тэстуйце пераход, а не перамыкач

Выключэнне VPN з яго ўласнага меню — гэта карэктнае завяршэнне, а карэктны выпадак кожная рэалізацыя апрацоўвае добра. Важны пераход — грубы: забіце працэс тунеля, вырвіце сетку, дайце серверу перастаць адказваць. Затым запусціце запыт і паглядзіце, ці ён праваліцца, ці ціха выкарыстае фізічнае злучэнне.

Вынік з аднаго ноўтбука не пераносіцца на тэлефон ці маршрутызатар. Розныя API платформ, розныя значэнні па змаўчанні, а на Android розніца рэзкая: рэжым always-on з блакаваннем прымушае сістэма, а не кліент, таму ён працуе, калі кліент не працуе. Рэкамендацыі Android па VPN апісваюць гэты падзел.

Пакіньце шлях назад

Блакаванне на ўзроўні сістэмы мае процілеглы рэжым адмовы. Фільтры, якія перажываюць кліент, могуць пакінуць машыну зусім без сеткі пасля дэінсталяцыі, а гэта званок у падтрымку без відавочнай прычыны. Перад уключэннем любога kill switch, які піша правілы платформы, адзначце, як ён выдаляецца, і трымайце шлях рамонту ад пастаўшчыка там, дзе зможаце яго знайсці.

Калі вы не можаце адказаць на праверкі збою, IPv6, DNS і пераходу для свайго кліента, стаўцеся да яго як да перамыкача ўзроўню праграмы з вядомымі прагаламі і плануйце адпаведна.

Падобныя артыкулы