Sken UDP hlási filtrované: je váš protiľahlý uzol WireGuard naozaj nedostupný?

Skenery vypisujú pri porte UDP otvorené alebo filtrované a záver zvyčajne prichádza v priebehu sekúnd: tunel je pokazený. Možno áno, ale sken to nepreukázal. UDP neprenáša žiadne nadviazanie spojenia a WireGuard neodpovedá na nič, čo nedokáže overiť, takže ticho je očakávaná odpoveď na väčšinu sond.

Postupujte namiesto toho od klienta smerom von a berte sken ako jeden slabý údaj medzi viacerými.

Čo skener vidí a čo nie

Skener UDP odošle užitočné zaťaženie a čaká. Ak sa vráti ICMP port-unreachable, môže port nahlásiť ako zatvorený. Ak sa nevráti nič, výsledok je zámerne nejednoznačný: filtrovaná cesta, chýbajúci hostiteľ aj bežiaca služba, ktorá obsah ignorovala, vytvárajú rovnaké ticho. Tri rôzne stavy, jeden výstupný reťazec.

WireGuard túto nejednoznačnosť zámerne zhoršuje. Protokol prijme paket len vtedy, keď ho overí, takže sonda s nesprávnymi kľúčmi sa zahodí bez odpovede. Neexistuje žiadny banner, žiadny reťazec verzie ani chybová správa na odtlačok.

Test TCP na rovnakom čísle portu netestuje nič súvisiace. Precvičuje iný poslucháč, ktorý nemusí existovať, a jeho odmietnutie o UDP nič nehovorí.

Otvorené filtrované stavy teda opisujú neistotu skenera presnejšie než váš server.

Prejdite skutočného klienta od profilu dovnútra

Začnite pohľadom samotného klienta. Má rozhranie adresu, uvádza konfigurácia správny koncový bod a hýbe sa počítadlo handshake, keď sa skúsi spojenie? Klient, ktorý nikdy neposlal paket, a klient, ktorého pakety boli zahodené, vyzerajú v stavovom okne rovnako. Rozlíšia ich len počítadlá, preto najprv čítajte počítadlá.

Potom sledujte stranu servera počas jedného autorizovaného pokusu, namiesto spúšťania samostatného skenu z tretieho miesta:

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

Prvý príkaz hlási posledný handshake pre každý protiľahlý uzol, čo je priamy dôkaz, že overená výmena sa dokončila. Druhý ukazuje, či pakety pre poslucháč vôbec dorazia, a tým v jednom kroku oddelí problém cesty od problému konfigurácie.

Ak zachytenie nič neukáže, paket sa k hostiteľovi nikdy nedostal a konfigurácia tunela nie je podozrivá. Ak ukazuje prichádzajúce pakety z očakávanej adresy, zatiaľ čo handshake zostáva na nule, kľúče alebo povolené adresy protiľahlého uzla sú ďalším miestom, kam sa pozrieť.

Korelujte na serveri, keď ho spravujete

Overte, že poslucháč existuje a že firewall poskytovateľa povoľuje port UDP. Pravidlo firewallu hostiteľa a cloudová bezpečnostná skupina sú dve nezávislé brány a každá môže zahodiť paket, ktorý tá druhá povolila. Skontrolujte obe proti skutočnému portu v konfigurácii, nie proti portu, ktorý si pamätáte.

Adresa je rovnako dôležitá ako port. Server počúvajúci na konkrétnej adrese neodpovie na paket, ktorý dorazí na inú, a hostiteľ s viacerými rozhraniami môže sondu prijať na rozhraní, ktoré ste nezamýšľali.

Každý test držte v systémoch, ktoré máte oprávnenie testovať. Užitočné porovnanie je medzi jedným skutočným pokusom klienta a očakávanou cestou servera, nie širším prechodom adries, ktoré náhodou patria rovnakému poskytovateľovi.

Ako čítať výsledok skenu čestne

Sken je lacný spôsob, ako overiť, že hostiteľ existuje a že port nie je zjavne blokovaný medziležiacim zariadením. Nie je to dôkaz dosiahnuteľnosti pre overený protokol a rozhodne to nie je test konfigurácie.

Silnejším dôkazom je dokončený handshake s klientom, na ktorom vám skutočne záleží, nasledovaný požiadavkou, ktorá tunel použije a dostane odpoveď. Táto postupnosť precvičí kľúče, povolené adresy, oba firewally aj cestu späť v jednom kroku.

Keď skutočný pokus zlyhá, zlyhanie sa stále musí diagnostikovať pomocou počítadiel klienta a zachytenia na serveri, nie pomocou ďalšej sondy. Opis protokolu vysvetľuje, prečo neoverený paket nedostane odpoveď, a to je celý dôvod, prečo je výsledok skenu nejednoznačný.