UDP VPN tyli portų skenavimo metu? Kodėl taip nutinka
WireGuard ir sukietintas OpenVPN atmeta autentifikacijos nepraėjusias datagramas neatsakydami. Tyla iš skaenerio yra laukiamas elgesys, o ne uždaras portas.
Jūs skenuojate VPN portą, negaunate atsakymo ir darote išvadą, kad paslauga neveikia arba užkarda uždaryta. Su WireGuard ir su OpenVPN valdymo kanalais, kurie neša savą autentifikaciją, ši išvada neseka. Datagrama be galiojančios autentifikacijos medžiagos atmetama be atsakymo, todėl tyla yra tai, kaip sveika paslauga atrodo iš išorės. Tikrinimas klaidingas anksčiau, nei tunelis.
Tyla yra protokolas, o ne gedimas
UDP neturi ryšio nustatymo, todėl nėra nei SYN, nei patvirtinimo, kuris leistų skaeneriui atskirti atvirą portą nuo filtruojamo. Tikrinimas ateina kaip atskira datagrama, o paslauga patikrina, ar ji atitinka laukiamą protokolą. Jei neatitinka, paketas atmetamas, o atmetimas yra dokumentuotas elgesys, o ne sutrikimas.
WireGuard kriptografiškai tikrina savo handshake pranešimus ir ignoruoja viską, kas nepavyksta. OpenVPN su tls-auth arba tls-crypt daro tą patį savo valdymo kanalui. Abiem atvejais savavališka naudingoji apkrova niekada nepasiekia vartotojui skirto etapo, todėl nėra kuo atsakyti ir nėra klaidos, kurią būtų galima grąžinti.
TCP būtų davęs reset iš uždaro porto. UDP palieka neapibrėžtumą, kurį skaeneriai išsprendžia atspausdindami atviras arba filtruojamas, o ne spėliodami.
Ką skaeneris gali ir ko negali padaryti išvados
Skenavimo rezultatas yra tik tiek informatyvus, kiek informatyvi išsiųsta naudingoji apkrova. Surikiuokite galimus stebėjimus pagal tai, ką kiekvienas jų iš tikrųjų pagrindžia:
| 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 |
Trečią eilutę skaitykite kaip vienintelį teigiamą testą sąraše. Jam reikia tikro profilio, tikro rakto ir teisingo galinio taško, o būtent to bendras skaeneris neturi.
Pažiūrėkite į abu kelio galus
Jei administruojate serverį, prieš darydami kokią nors išvadą fiksuokite sąsajoje, tada paklauskite paslaugos, ką ji matė. Abiem komandoms reikia root tinklų sietuve:
tcpdump -ni any udp port 51820
tcpdump -ni any udp port 1194
wg showJei sąsajoje neatsiranda joks paketas, kelias jį atmetė anksčiau, nei paslauga ką nors pamatė, o kita stotelė yra maršrutizavimas ir filtravimas. Jei paketai ateina, bet joks handshake nebaigiamas, paslauga pasiekiama, o neatitikimas yra raktuose, galinio taško konfigūracijoje arba protokolo versijoje. Šis palyginimas atsako į klausimą, į kurį skaeneris negalėjo. Vykdykite jį, kai tikras klientas bando prisijungti, o ne kai skaeneris kartoja save.
Pakeiskite testą, o ne apsaugą
Viliojantis trumpiausias kelias yra išjungti valdymo kanalo apsaugą, kad diagnostika gautų atsakymą. Tai iškeičia tikrą saugumo savybę į gražesnį skenavimo rezultatą, ir tai yra neteisinga kryptis. Vietoj to naudokite galiojantį profilį iš patvirtinto tinklo ir užsirašykite galinį tašką bei laiką, kad palyginimą būtų galima pakartoti.
Naudingiausias testas yra diferencinis: tas pats profilis kelyje, kuris veikia, ir kelyje, kuris neveikia. Jei veikiantis kelias sukuria handshake, o nepavykęs kelias sąsajoje nesukuria nieko, jūs radote trūkio vietą nieko nesusilpninę.
Taigi neatsakytas UDP paketas neįrodo nei to, kad serveris neprisijungęs, nei to, kad jis saugus. Jis įrodo, kad šis tikrinimas, šiame kelyje, šiuo momentu nebuvo priimtas.