UDP skenēšana rāda filtrēts: vai jūsu WireGuard partneris tiešām ir izslēgts?

Skenētāji UDP portam izvada atvērts vai filtrēts, un secinājums parasti nāk dažu sekunžu laikā: tunelis ir salūzis. Tas var būt, bet skenēšana to nepierādīja. UDP nepārnes nekādu savienojuma rokasspiedienu, un WireGuard neatbild uz neko, ko tas nevar autentificēt, tāpēc klusums ir gaidītā atbilde uz lielāko daļu zondējumu.

Tā vietā strādājiet no klienta uz āru un uzskatiet skenēšanu par vienu vāju datu punktu starp vairākiem.

Ko skenētājs var redzēt un ko ne

UDP skenētājs nosūta kravu un gaida. Ja atgriežas ICMP port-unreachable, tas var ziņot, ka ports ir slēgts. Ja nekas neatgriežas, rezultāts pēc konstrukcijas ir neviennozīmīgs: filtrēts ceļš, neesošs resursdators un darbojošs serviss, kas ignorēja kravu, visi rada vienu un to pašu klusumu. Trīs dažādi stāvokļi, viena izvades virkne.

WireGuard apzināti padara šo neviennozīmību sliktāku. Protokols pieņem paketi tikai tad, kad tā autentificējas, tāpēc zonde ar nepareizām atslēgām tiek izmesta bez atbildes. Nav ne reklāmkaroga, ne versijas virknes, ne kļūdas ziņojuma, kam uzņemt pirkstu nospiedumu.

TCP tests ar to pašu porta numuru nepārbauda neko saistītu. Tas noslogo citu klausītāju, kura var arī nebūt, un tā atteikums neko nepasaka par UDP.

Tāpēc atvērti filtrēti stāvokļi precīzāk raksturo skenētāja nenoteiktību nekā jūsu serveri.

Izejiet cauri īstajam klientam no profila uz iekšpusi

Sāciet ar paša klienta skatījumu. Vai saskarnē ir adrese, vai konfigurācija nosauc pareizo galapunktu un vai rokasspiedienu skaitītājs kustas, kad tiek mēģināts savienojums? Klients, kas nekad nav nosūtījis paketi, un klients, kura paketes tika izmestas, statusa logā izskatās identiski. Tos atšķir tikai skaitītāji, tāpēc vispirms lasiet skaitītājus.

Pēc tam vērojiet servera pusi viena atļauta mēģinājuma laikā, nevis palaidiet atsevišķu skenēšanu no trešās vietas:

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

Pirmā komanda ziņo pēdējo rokasspiedienu katram partnerim, un tas ir tiešs pierādījums, ka autentificēta apmaiņa ir pabeigta. Otrā parāda, vai paketes klausītājam vispār pienāk, un tas vienā solī atdala ceļa problēmu no konfigurācijas problēmas.

Ja uztveršana neko neuzrāda, pakete nekad nav sasniegusi resursdatoru un tuneļa konfigurācija nav aizdomās turamā. Ja tā uzrāda pienākošas paketes no gaidītās adreses, kamēr rokasspiediens paliek nullē, atslēgas vai partnera atļautās adreses ir nākamā vieta, kur skatīties.

Korelējiet serverī, kad to administrējat

Apstipriniet, ka klausītājs pastāv un ka pakalpojumu sniedzēja ugunsmūris atļauj UDP portu. Resursdatora ugunsmūra noteikums un mākoņa drošības grupa ir divi neatkarīgi vārti, un jebkurš no tiem var izmest paketi, ko otrs atļāva. Pārbaudiet abus pret faktisko portu konfigurācijā, nevis pret portu, ko atceraties.

Adrese ir tikpat svarīga kā ports. Serveris, kas klausās konkrētā adresē, neatbildēs uz paketi, kas pienāk citā, un resursdators ar vairākām saskarnēm var saņemt zondi saskarnē, kuru jūs neplānojāt.

Turiet katru testu sistēmās, kuras jums ir atļauts testēt. Noderīgais salīdzinājums ir starp vienu īstu klienta mēģinājumu un gaidīto servera ceļu, nevis plašāka adrešu pārbaude, kas nejauši pieder tam pašam pakalpojumu sniedzējam.

Godīgi nolasīt skenēšanas rezultātu

Skenēšana ir lēts veids, kā pārbaudīt, vai resursdators pastāv un vai portu acīmredzami nebloķē starpniekierīce. Tas nav autentificēta protokola sasniedzamības pierādījums un noteikti nav konfigurācijas tests.

Spēcīgākais pierādījums ir pabeigts rokasspiediens no klienta, kas jums patiešām rūp, kam seko pieprasījums, kas izmanto tuneli un saņem atbildi. Šī secība vienā reizē noslogo atslēgas, atļautās adreses, abus ugunsmūrus un atgriešanās ceļu.

Kad īstais mēģinājums neizdodas, kļūme tomēr jādignozē ar klienta skaitītājiem un servera uztveršanu, nevis ar vēl vienu zondi. Protokola apraksts izskaidro, kāpēc neautentificēta pakete nesaņem atbildi, un tas ir viss iemesls, kāpēc skenēšanas rezultāts ir neviennozīmīgs.