UDP VPN klusē portu skenēšanas laikā? Kāpēc tā notiek
WireGuard un rūdītais OpenVPN atmet autentifikāciju neizturējušos datagrammas, neatbildot. Klusums no skenera ir gaidīta uzvedība, nevis aizvērts ports.
Jūs skenējat VPN portu, nesaņemat atbildi un secināt, ka pakalpojums ir apstājies vai ugunsmūris ir aizvērts. Ar WireGuard un ar OpenVPN vadības kanāliem, kas nes savu autentifikāciju, šis secinājums neizriet. Datagramma bez derīga autentifikācijas materiāla tiek atmesta bez atbildes, tāpēc klusums ir tas, kā veselīgs pakalpojums izskatās no ārpuses. Pārbaude ir nepareiza pirms tam, kad ir tunelis.
Klusums ir protokols, nevis kļūda
UDP nav savienojuma izveides, tāpēc nav ne SYN, ne apstiprinājuma, kas ļautu skenerim atšķirt atvērtu portu no filtrēta. Pārbaude pienāk kā atsevišķa datagramma, un pakalpojums pārbauda, vai tā atbilst gaidītajam protokolam. Ja neatbilst, pakete tiek atmesta, un atmešana ir dokumentēta uzvedība, nevis darbības traucējums.
WireGuard kriptogrāfiski validē savus handshake ziņojumus un ignorē visu, kas neizdodas. OpenVPN ar tls-auth vai tls-crypt dara to pašu savam vadības kanālam. Abos gadījumos patvaļīga lietderīgā slodze nekad nesasniedz lietotājam vērstu posmu, tāpēc nav ar ko atbildēt un nav kļūdas, ko atgriezt.
TCP būtu devis reset no aizvērta porta. UDP atstāj jūs nenoteiktībā, ko skeneri atrisina, izdrukājot atvērts vai filtrēts, nevis minot.
Ko skeneris var un ko nevar secināt
Skenēšanas rezultāts ir tikpat informatīvs, cik informatīva ir nosūtītā lietderīgā slodze. Sakārtojiet iespējamos novērojumus pēc tā, ko katrs no tiem patiešām pamato:
| Probe | Observed result | What it supports |
|---|---|---|
| Empty datagram | No reply | Nothing beyond the fact that UDP was used |
| Random payload | No reply | Consistent with an authenticated service |
| Valid handshake from a real client | A protocol reply | The service is alive and reachable |
| ICMP port unreachable | Unreachable message | The host answered, usually because nothing listens |
Lasiet trešo rindu kā vienīgo pozitīvo testu sarakstā. Tam vajadzīgs īsts profils, īsta atslēga un pareizs galapunkts, un tas ir tieši tas, kā vispārīgam skenerim nav.
Paskatieties uz abiem ceļa galiem
Serverim, kuru pārvaldāt, pirms jebkāda secinājuma izdarīšanas ierakstiet saskarnē, pēc tam pajautājiet pakalpojumam, ko tas redzēja. Abām komandām vajadzīgs root uz vārtejas:
tcpdump -ni any udp port 51820
tcpdump -ni any udp port 1194
wg showJa saskarnē neparādās neviens pakets, ceļš to atmeta, pirms pakalpojums kaut ko ieraudzīja, un nākamā pietura ir maršrutēšana un filtrēšana. Ja paketes pienāk, bet neviens handshake netiek pabeigts, pakalpojums ir sasniedzams un neatbilstība ir atslēgās, galapunkta konfigurācijā vai protokola versijā. Šis salīdzinājums atbild uz jautājumu, uz kuru skeneris nespēja. Izpildiet to, kamēr īsts klients mēģina savienoties, nevis kamēr skeneris atkārto sevi.
Mainiet testu, nevis aizsardzību
Kārdinošais īsceļš ir izslēgt vadības kanāla aizsardzību, lai diagnostika saņemtu atbildi. Tas apmaina īstu drošības īpašību pret glītāku skenēšanas rezultātu, un tas ir nepareizais virziens. Tā vietā izmantojiet derīgu profilu no apstiprināta tīkla un pierakstiet galapunktu un laiku, lai salīdzinājumu varētu atkārtot.
Noderīgākais tests ir diferenciālais: tas pats profils ceļā, kas darbojas, un ceļā, kas nedarbojas. Ja strādājošais ceļš rada handshake, bet nespējīgais ceļš saskarnē nerada neko, jūs esat lokalizējis pārrāvumu, neko nevājinot.
Tāpēc neatbildēta UDP pakete nepierāda nedz to, ka serveris ir bezsaistē, nedz to, ka tas ir drošs. Tā pierāda, ka šī pārbaude, šajā ceļā, šajā brīdī netika pieņemta.