Sken UDP pravi filtrirano: je vaš WireGuard partner res nedosegljiv?

Skenerji za vrata UDP izpišejo odprto ali filtrirano, sklep pa običajno pride v nekaj sekundah: tunel je pokvarjen. Morda je res, a sken tega ni dokazal. UDP ne prenaša nobenega rokovanja s povezavo, WireGuard pa ne odgovori na nič, česar ne more overiti, zato je tišina pričakovani odgovor na večino sond.

Delajte raje od odjemalca navzven in sken obravnavajte kot eno šibko podatkovno točko med več.

Kaj skener lahko vidi in česa ne

Skener UDP pošlje tovor in čaka. Če se vrne ICMP port-unreachable, lahko vrata prijavi kot zaprta. Če se ne vrne nič, je rezultat po zasnovi dvoumen: filtrirana pot, odsoten gostitelj in delujoča storitev, ki je tovor prezrla, vsi ustvarijo enako tišino. Tri različna stanja, en niz izhoda.

WireGuard to dvoumnost namerno poslabša. Protokol paket sprejme le, ko se overi, zato se sonda z napačnimi ključi zavrže brez odgovora. Ni pasice, ni niza različice in ni sporočila o napaki za prstni odtis.

Preizkus TCP na isti številki vrat ne preizkusi ničesar povezanega. Izvaja drugega poslušalca, ki morda ne obstaja, in njegova zavrnitev ne pove nič o UDP.

Odprta filtrirana stanja torej natančneje opisujejo negotovost skenerja kot vaš strežnik.

Pojdite skozi pravega odjemalca od profila navznoter

Začnite s pogledom samega odjemalca. Ima vmesnik naslov, ali konfiguracija navaja pravo končno točko in ali se števec rokovanja premakne, ko se poskusi povezava? Odjemalec, ki ni nikoli poslal paketa, in odjemalec, katerega paketi so bili zavrženi, sta v statusnem oknu videti enako. Razlikujejo ju le števci, zato najprej preberite števce.

Nato opazujte stran strežnika med enim pooblaščenim poskusom, namesto da bi zagnali ločen sken s tretjega mesta:

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

Prvi ukaz poroča zadnje rokovanje na partnerja, kar je neposreden dokaz, da se je overjena izmenjava končala. Drugi pokaže, ali paketi za poslušalca sploh prispejo, kar v enem koraku loči težavo poti od težave konfiguracije.

Če zajem ne pokaže ničesar, paket ni nikoli dosegel gostitelja in konfiguracija tunela ni osumljenec. Če pokaže pakete, ki prihajajo s pričakovanega naslova, medtem ko rokovanje ostane na ničli, so ključi ali dovoljeni naslovi partnerja naslednje mesto za pogled.

Korelirajte na strežniku, ko ga upravljate

Potrdite, da poslušalec obstaja in da požarni zid ponudnika dovoljuje vrata UDP. Pravilo požarnega zidu gostitelja in varnostna skupina v oblaku sta dve neodvisni vrati in vsaka lahko zavrže paket, ki ga je druga dovolila. Preverite obe glede na dejanska vrata v konfiguraciji, ne glede na vrata, ki se jih spomnite.

Naslov je enako pomemben kot vrata. Strežnik, ki posluša na določenem naslovu, ne bo odgovoril na paket, ki prispe na drugega, gostitelj z več vmesniki pa lahko sondo prejme na vmesniku, ki ga niste nameravali.

Vsak preizkus imejte v sistemih, za katere ste pooblaščeni. Koristna primerjava je med enim resničnim poskusom odjemalca in pričakovano potjo strežnika, ne širši pregled naslovov, ki slučajno pripadajo istemu ponudniku.

Pošteno branje rezultata skena

Sken je poceni način, da preverite, ali gostitelj obstaja in ali vrat očitno ne blokira vmesna naprava. Ni dokaz dosegljivosti za overjen protokol in zagotovo ni preizkus konfiguracije.

Močnejši dokaz je končano rokovanje od odjemalca, ki vam je res pomemben, temu pa sledi zahteva, ki uporabi tunel in dobi odgovor. To zaporedje v enem zamahu preizkusi ključe, dovoljene naslove, oba požarna zidova in povratno pot.

Kjer resnični poskus spodleti, je treba okvaro še vedno diagnosticirati s števci odjemalca in zajemom na strežniku, ne z novo sondo. Opis protokola pojasni, zakaj neoverjen paket ne dobi odgovora, in to je ves razlog, da je rezultat skena dvoumen.