Sken UDP hlásí filtrováno: je váš protějšek WireGuardu skutečně nedostupný?

Skenery vypisují u portu UDP otevřeno, nebo filtrováno, a závěr obvykle přijde během několika sekund: tunel je rozbitý. Možná ano, ale sken to neprokázal. UDP nenese žádné navázání spojení a WireGuard neodpovídá na nic, co nedokáže ověřit, takže ticho je očekávaná reakce na většinu sond.

Postupujte naopak od klienta směrem ven a berte sken jako jeden slabý údaj mezi několika dalšími.

Co skener vidí a co ne

Skener UDP pošle užitečné zatížení a čeká. Vrátí-li se ICMP port-unreachable, může port nahlásit jako zavřený. Pokud se nevrátí nic, je výsledek záměrně nejednoznačný: filtrovaná cesta, chybějící hostitel i běžící služba, která obsah ignorovala, vytvářejí stejné ticho. Tři různé stavy, jeden výstupní řetězec.

WireGuard tuto nejednoznačnost záměrně zhoršuje. Protokol přijme paket jen tehdy, když jej ověří, takže sonda s nesprávnými klíči je zahozena bez odpovědi. Neexistuje žádný banner, žádný řetězec verze ani chybová zpráva k otisku.

Test TCP na stejném čísle portu nezkouší nic souvisejícího. Procvičuje jiný naslouchající proces, který nemusí existovat, a jeho odmítnutí o UDP nic neříká.

Otevřené filtrované stavy tedy popisují nejistotu skeneru přesněji než váš server.

Projděte skutečného klienta od profilu dovnitř

Začněte pohledem samotného klienta. Má rozhraní adresu, uvádí konfigurace správný koncový bod a hýbe se počitadlo handshake, když se zkusí spojení? Klient, který nikdy neposlal paket, a klient, jehož pakety byly zahozeny, vypadají ve stavovém okně stejně. Rozliší je jen počitadla, proto čtěte nejprve počitadla.

Potom sledujte stranu serveru během jednoho autorizovaného pokusu, místo abyste spouštěli samostatný sken ze třetího místa:

wg show wg0 latest-handshakes
tcpdump -n -i eth0 udp port 51820 -c 10

První příkaz hlásí poslední handshake pro každý protějšek, což je přímý důkaz, že ověřená výměna proběhla. Druhý ukazuje, zda pakety pro naslouchající proces vůbec dorazí, a tím v jednom kroku oddělí problém cesty od problému konfigurace.

Pokud zachycení nic neukáže, paket se k hostiteli nikdy nedostal a konfigurace tunelu není podezřelá. Pokud ukazuje přicházející pakety očekávané adresy, zatímco handshake zůstává na nule, jsou klíče nebo povolené adresy protějšku dalším místem, kam se podívat.

Korelace na serveru, když jej spravujete

Ověřte, že naslouchající proces existuje a že firewall poskytovatele povoluje port UDP. Pravidlo firewallu hostitele a cloudová bezpečnostní skupina jsou dvě nezávislé brány a každá může zahodit paket, který ta druhá povolila. Zkontrolujte obě proti skutečnému portu v konfiguraci, ne proti portu, který si pamatujete.

Adresa je stejně důležitá jako port. Server naslouchající na konkrétní adrese neodpoví na paket, který dorazí na jinou, a hostitel s více rozhraními může sondu přijmout na rozhraní, které jste nezamýšleli.

Každý test držte v systémech, které máte oprávnění testovat. Užitečné srovnání je mezi jedním skutečným pokusem klienta a očekávanou cestou serveru, ne širším průchodem adres, které náhodou patří stejnému poskytovateli.

Jak číst výsledek skenu poctivě

Sken je levný způsob, jak ověřit, že hostitel existuje a že port není zjevně blokován mezilehlým zařízením. Není to důkaz dosažitelnosti pro ověřený protokol a rozhodně to není test konfigurace.

Silnějším důkazem je dokončený handshake s klientem, na kterém vám skutečně záleží, následovaný požadavkem, který tunel použije a dostane odpověď. Tato posloupnost v jednom kroku procvičí klíče, povolené adresy, oba firewally i cestu zpět.

Když skutečný pokus selže, selhání se stále musí diagnostikovat pomocí počitadel klienta a zachycení na serveru, ne pomocí další sondy. Popis protokolu vysvětluje, proč neověřený paket nedostane odpověď, a to je celý důvod, proč je výsledek skenu nejednoznačný.