UDP-skaneerimine näitab filtreeritud: kas sinu WireGuard partner on tõesti maas?

Skannerid väljastavad UDP-pordi kohta oleku avatud või filtreeritud ja järeldus tuleb tavaliselt sekundite jooksul: tunnel on katki. Võib olla, aga skaneerimine ei tõestanud seda. UDP ei kanna ühtegi ühenduse käepigistust ja WireGuard ei vasta millelegi, mida ta ei suuda autentida, seega vaikus on enamiku sondide ootuspärane vastus.

Tööta hoopis kliendist väljapoole ja käsitle skaneerimist ühe nõrga andmepunktina paljude seas.

Mida skanner näeb ja mida mitte

UDP-skanner saadab koormuse ja ootab. Kui tagasi tuleb ICMP port-unreachable, võib ta teatada pordi suletuks. Kui midagi ei tule, on tulemus konstruktsiooni tõttu mitmetähenduslik: filtreeritud tee, puuduv host ja töötav teenus, mis koormuse ignoreeris, tekitavad kõik sama vaikuse. Kolm erinevat olekut, üks väljundstring.

WireGuard teeb selle mitmetähenduslikkuse meelega hullemaks. Protokoll võtab paketi vastu ainult siis, kui see autendib, seega vale võtmetega sond visatakse vastuseta kõrvale. Pole bännerit, pole versioonistringi ega veateadet, mida sõrmejäljendada.

TCP-test samal pordi numbril ei testi midagi seonduvat. See koormab teist kuulajat, mida ei pruugi olla, ja selle keeldumine ei ütle UDP kohta midagi.

Avatud filtreeritud olekud kirjeldavad seega skanneri ebakindlust täpsemalt kui sinu serverit.

Käi päris klient profiilist sissepoole läbi

Alusta kliendi enda vaatest. Kas liidesel on aadress, kas seadistus nimetab õige otspunkti ja kas käepigistuse loendur liigub, kui ühendust proovitakse? Klient, kes ei saatnud kunagi paketti, ja klient, kelle paketid maha visati, näevad olekuaknas ühesugused välja. Neid eristavad ainult loendurid, seega loe kõigepealt loendureid.

Seejärel jälgi serveripoolt ühe volitatud katse ajal, selle asemel et käivitada eraldi skaneerimine kolmandast kohast:

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

Esimene käsk teatab viimase käepigistuse partneri kohta, mis on otsene tõend, et autenditud vahetus lõppes. Teine näitab, kas kuulaja jaoks paketid üldse kohale jõuavad, mis eraldab tee probleemi seadistuse probleemist ühe sammuga.

Kui jäädvustus ei näita midagi, ei jõudnud pakett kunagi hostini ja tunneli seadistus ei ole kahtlusalune. Kui see näitab saabuvaid pakette oodatud aadressilt, samal ajal kui käepigistus jääb nulli, tuleb järgmisena vaadata võtmeid või partneri lubatud aadresse.

Korreleeri serveris, kui sa seda haldad

Kinnita, et kuulaja on olemas ja et teenusepakkuja tulemüür lubab UDP-porti. Hostipõhine tulemüürireegel ja pilve turbegrupp on kaks sõltumatut väravat ja kumbki võib maha visata paketi, mille teine lubas. Kontrolli mõlemat seadistuses oleva tegeliku pordi vastu, mitte selle pordi vastu, mida mäletad.

Aadress loeb sama palju kui port. Kindlal aadressil kuulav server ei vasta paketile, mis saabub teisele aadressile, ja mitme liidesega host võib sondi vastu võtta liidesel, mida sa ei kavatsenud.

Hoia iga test süsteemides, mille testimiseks oled volitatud. Kasulik võrdlus on ühe päris kliendikatse ja oodatud serveritee vahel, mitte laiem aadresside läbivaatus, mis juhtumisi kuuluvad samale teenusepakkujale.

Skaneerimistulemuse aus lugemine

Skaneerimine on odav viis kontrollida, kas host on olemas ja kas porti ei blokeeri ilmselt vahepealne seade. See ei ole autenditud protokolli kättesaadavuse tõestus ja kindlasti mitte seadistuse test.

Tugevam tõend on lõpule viidud käepigistus kliendiga, millest sa tõesti hoolid, millele järgneb päring, mis kasutab tunnelit ja saab vastuse. See jada koormab ühe hoobiga võtmeid, lubatud aadresse, mõlemat tulemüüri ja tagasiteed.

Kui päris katse ebaõnnestub, tuleb riket siiski diagnoosida kliendi loendurite ja serveri jäädvustusega, mitte veel ühe sondiga. Protokolli kirjeldus selgitab, miks autentimata pakett vastust ei saa, ja just see ongi põhjus, miks skaneerimistulemus on mitmetähenduslik.