Скенери исписују отворено или филтрирано за 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 порт. Правило заштитног зида домаћина и безбедносна група у облаку су две независне капије, и свака може да одбаци пакет који је друга дозволила. Проверите обе према стварном порту у конфигурацији, а не према порту којег се сећате.

Адреса је једнако важна као порт. Сервер који слуша на одређеној адреси неће одговорити на пакет који стигне на другу, а домаћин са више интерфејса може да прими сонду на интерфејсу који нисте намеравали.

Држите сваки тест унутар система за које сте овлашћени. Корисно поређење је између једног стварног покушаја клијента и очекиване путање сервера, а не ширег прегледа адреса које случајно припадају истом провајдеру.

Често читање резултата скенирања

Скенирање је јефтин начин да проверите да ли домаћин постоји и да ли порт није очигледно блокиран посредничким уређајем. То није доказ доступности за аутентификовани протокол и свакако није тест конфигурације.

Јачи доказ је завршено руковање од клијента који вам је заиста важан, након чега следи захтев који користи тунел и добија одговор. Тај след у једном потезу вежба кључеве, дозвољене адресе, оба заштитна зида и повратну путању.

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

Повезани чланци