VPN prin UDP tăcut la o scanare de porturi? De ce se întâmplă
WireGuard și OpenVPN întărit aruncă datagramele care nu trec autentificarea fără să răspundă. Tăcerea unui scanner este comportamentul așteptat, nu un port închis.
Scanezi portul VPN, nu primești niciun răspuns și concluzionezi că serviciul este căzut sau că firewallul este închis. La WireGuard, și la canalele de control OpenVPN care își poartă propria autentificare, această concluzie nu decurge. Un datagram fără material de autentificare valid este aruncat fără răspuns, așa că tăcerea este felul în care un serviciu sănătos arată din exterior. Sonda este greșită înainte ca tunelul să fie.
Tăcerea este protocolul, nu o defecțiune
UDP nu are stabilirea conexiunii, așa că nu există SYN și nici o confirmare care să permită unui scanner să distingă un port deschis de unul filtrat. Sonda ajunge ca un datagram izolat, iar serviciul verifică dacă se potrivește cu protocolul pe care îl așteaptă. Când nu se potrivește, pachetul este aruncat, iar aruncarea este comportamentul documentat, nu o defecțiune.
WireGuard își validează criptografic mesajele de handshake și ignoră tot ce eșuează. OpenVPN cu tls-auth sau tls-crypt face același lucru pentru canalul său de control. În ambele cazuri, o încărcătură arbitrară nu ajunge niciodată la o etapă orientată spre utilizator, așa că nu există nimic cu care să răspunzi și nicio eroare de returnat.
TCP ți-ar fi dat un reset dintr-un port închis. UDP te lasă în ambiguu, pe care scanerele îl rezolvă tipărind deschis sau filtrat în loc să ghicească.
Ce poate și ce nu poate concluziona un scanner
Rezultatul unei scanări este la fel de informativ pe cât este încărcătura trimisă. Ordonează observațiile posibile după ce susține fiecare cu adevărat:
| 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 |
Citește al treilea rând ca singurul test pozitiv din listă. Necesită profilul real, cheia reală și punctul final corect, iar exact asta nu are un scanner generic.
Privește ambele capete ale drumului
Pentru un server pe care îl administrezi, capturează pe interfață înainte de a trage orice concluzie, apoi întreabă serviciul ce a văzut. Ambele comenzi necesită root pe gateway:
tcpdump -ni any udp port 51820
tcpdump -ni any udp port 1194
wg showDacă nu apare niciun pachet pe interfață, calea l-a aruncat înainte ca serviciul să vadă ceva, iar următoarea oprire este rutarea și filtrarea. Dacă pachetele sosesc dar niciun handshake nu se finalizează, serviciul este accesibil iar diferența este în chei, configurația punctului final sau versiunea protocolului. Comparația aceea răspunde la întrebarea la care scannerul nu putea. Ruleaz-o în timp ce un client real încearcă să se conecteze, nu în timp ce scannerul se repetă.
Schimbă testul, nu protecția
Scurtătura tentantă este să dezactivezi protecția canalului de control ca un diagnostic să primească răspuns. Asta schimbă o proprietate reală de securitate pe un rezultat de scanare mai frumos, și este direcția greșită. Folosește în schimb un profil valid dintr-o rețea aprobată și notează punctul final și ora pentru ca comparația să fie repetabilă.
Cel mai util test este unul diferențial: același profil pe un drum care funcționează și pe drumul care nu funcționează. Dacă drumul funcțional produce un handshake iar drumul care eșuează nu produce nimic pe interfață, ai localizat ruptura fără să slăbești nimic.
Un pachet UDP fără răspuns nu dovedește așadar nici că serverul este offline, nici că este sigur. Dovedește că această sondă, pe acest drum, în acest moment, nu a fost acceptată.