UDP сканирането казва филтриран: наистина ли вашият WireGuard партньор е спрян?
Неудостоверена проба често не получава никакъв отговор от здрав партньор. Тествайте истинския клиент и след това корелирайте слушателя и пътя на пакетите на сървъра.
Скенерите отпечатват отворен или филтриран за UDP порт и заключението обикновено идва за секунди: тунелът е счупен. Може и да е, но сканирането не го доказа. UDP не носи никакво ръкостискане на връзката, а WireGuard не отговаря на нищо, което не може да удостовери, така че тишината е очакваният отговор на повечето проби.
Работете вместо това от клиента навън и третирайте сканирането като една слаба точка от данни сред няколко.
Какво скенерът може и какво не може да види
UDP скенер изпраща полезен товар и чака. Ако се върне ICMP port-unreachable, той може да отчете порта като затворен. Ако нищо не се върне, резултатът е двусмислен по дизайн: филтриран път, липсващ хост и работеща услуга, която е игнорирала товара, всички създават една и съща тишина. Три различни състояния, един изходен низ.
WireGuard умишлено влошава тази двусмисленост. Протоколът приема пакет само когато той се удостовери, затова проба с грешни ключове се отхвърля без отговор. Няма банер, низ за версия и съобщение за грешка, които да се разпознаят.
TCP тест на същия номер на порт не проверява нищо свързано. Той упражнява друг слушател, който може да не съществува, и отказът му не казва нищо за UDP.
Затова отворените филтрирани състояния описват несигурността на скенера по-точно, отколкото описват вашия сървър.
Преминете през истинския клиент от профила навътре
Започнете със собствената гледна точка на клиента. Има ли интерфейсът адрес, посочва ли конфигурацията правилната крайна точка и движи ли се броячът на ръкостисканията, когато се опита връзка? Клиент, който никога не е изпращал пакет, и клиент, чиито пакети са били отхвърлени, изглеждат еднакво в прозорец за състояние. Само броячите ги различават, затова първо четете броячите.
След това наблюдавайте страната на сървъра, докато тече един разрешен опит, вместо да стартирате отделно сканиране от трето място:
wg show wg0 latest-handshakes
tcpdump -n -i eth0 udp port 51820 -c 10
Първата команда отчита последното ръкостискане за всеки партньор, което е пряко доказателство, че удостоверен обмен е завършил. Втората показва дали пакетите за слушателя изобщо пристигат, което с една стъпка отделя проблем с пътя от проблем с конфигурацията.
Ако записът не показва нищо, пакетът никога не е достигнал до хоста и конфигурацията на тунела не е заподозряната. Ако показва пристигащи пакети от очаквания адрес, докато ръкостискането остава на нула, ключовете или разрешените адреси на партньора са следващото място за проверка.
Корелирайте на сървъра, когато го администрирате
Потвърдете, че слушателят съществува и че защитната стена на доставчика разрешава UDP порта. Правило на защитната стена на хоста и група за сигурност в облака са две независими порти и всяка от тях може да отхвърли пакет, който другата е разрешила. Проверете и двете спрямо действителния порт в конфигурацията, а не спрямо порта, който помните.
Адресът е също толкова важен, колкото портът. Сървър, който слуша на конкретен адрес, няма да отговори на пакет, който пристига на друг, а хост с няколко интерфейса може да получи пробата на интерфейса, който не сте имали предвид.
Дръжте всеки тест в системи, за които имате разрешение. Полезното сравнение е между един истински опит на клиента и очаквания път на сървъра, а не по-широк преглед на адреси, които случайно принадлежат на същия доставчик.
Честно четене на резултата от сканиране
Сканирането е евтин начин да проверите дали хост съществува и дали порт не е очевидно блокиран от междинно устройство. То не е доказателство за достъпност за удостоверен протокол и със сигурност не е тест на конфигурацията.
По-силното доказателство е завършено ръкостискане от клиента, който наистина ви интересува, последвано от заявка, която използва тунела и получава отговор. Тази последователност упражнява ключовете, разрешените адреси, двете защитни стени и обратния път наведнъж.
Когато истинският опит се провали, повредата все пак трябва да се диагностицира с броячите на клиента и записа на сървъра, а не с още една проба. Описанието на протокола обяснява защо неудостоверен пакет не получава отговор и точно това е причината резултатът от сканирането да е двусмислен.