Како проверити да ли VPN тунел на Linux-у заиста ради

Cron сваких десет минута поново покреће потпуно здрав VPN, а исти посао оставља мртав тунел да ради читаву недељу. Обе грешке долазе отуда што се «ради» третира као једна чињеница, а то је најмање четири. Уређај може бити административно омогућен, исправно рутиран, потпуно шифрован и ипак не преносити ништа корисно. Прво раздвојите запажања, и провера се готово сама напише.

Заставице везе описују уређај, а не путању

Провера коју сви копирају тражи хардверску адресу од самих нула. Тај трик код неких драјвера одваја прави интерфејс од замене, а код осталих не доказује ништа, јер tun уређај уопште нема MAC да га пријави. ip -brief link show tun0 уместо тога даје заставице: UP значи да је администратор омогућио уређај, а LOWER_UP значи да драјвер сматра везу употребљивом. Читане заједно, оне кажу да уређај постоји и да није административно искључен. Ниједна од њих не каже да пакет има куда да оде.

OpenVPN ствара свој tun уређај пре него што се руте инсталирају, па заставице могу изгледати савршено док ништа није рутирано. Третирајте их као предуслов, никада као одговор.

Питајте куда би пакет отишао

Претрага руте одговара на питање на које заставице не могу. ip route get 10.8.0.1 from 10.8.0.2 именује интерфејс, изворну адресу и табелу коју би језгро користило, а то је управо оно према чему подељени тунел мора да се провери. Без изворне адресе питате нешто друго, а са рутирањем по политикама одговор може да се разликује по извору. Ово је најјефтинији поштен тест, јер се саветује са истим правилима која ће користити и ваш саобраћај.

За WireGuard додајте руковање. wg show штампа временску ознаку последњег руковања по партнеру, а ознака која је престала да напредује значи да партнера нема, шта год заставице интерфејса говориле. Конфигурисан интерфејс без скорашњег руковања један је од најчешћих лажних позитива у домаћем надзору.

Табела 220 прича причу IPsec-а

strongSwan инсталира руте за договорене селекторе у табелу 220 када је инсталација рута омогућена. ip route list table 220 зато одваја договорено од рутираног: празна табела поред учитане везе значи да су се IKE и CHILD SA подигли док се никакав саобраћај не усмерава ка њима. Проверите ip xfrm state поред ње, јер наводи инсталиране безбедносне асоцијације и њихове крајње тачке.

Политика замке је случај на који треба пазити. Она чека занимљив саобраћај уместо да га рутира, па табела остаје празна док нешто не активира тунел.

Стање менаџера и стање демона су различите листе

NetworkManager наводи само везе које поседује. nmcli -t -f NAME,TYPE connection show --active не враћа ништа за тунел који је директно покренуо wg-quick или OpenVPN демон.

Та разлика је важна када скрипта треба да одлучи ког од два менаџера да пита. Изаберите онај који стварно поседује тунел на овом хосту и игноришите ћутање другог. Ако постоје оба, одлучите који је меродаван и искључите други, јер два менаџера која преписују руте на једном интерфејсу стварају кварове које нико не може да репродукује. Запис који недостаје је информација о менаџеру, не о тунелу.

Условите следећи корак провером која му је потребна

Анкетирање UDP порта не доказује ништа о спремности, јер UDP нема руковање и nc -u успева чим пакет изађе. Проверите шта следећи корак стварно троши: TCP везу до прослеђеног порта, захтев ка хосту унутар тунела, име које се разрешава само тамо. Ограничите чекање временским ограничењем и бројем покушаја, и гласно откажите када истекну.

Куке су боље од анкетирања када их клијент нуди. --up и --down скрипте OpenVPN-а се извршавају након што интерфејс промени стање, што потпуно уклања трку, али раде са привилегијама које је демон задржао. Ако је OpenVPN сишао на непривилеговани налог кроз user и group, кука ради као тај налог. Рестартовање системске услуге тада захтева sudo да дозволи управо ту наредбу. Предајте понављање менаџеру услуга, а не cron петљи: ограничена политика рестартовања са границом покретања открива покварен тунел, док га неограничена петља крије неодређено.