UDP VPN ne odgovara na skeniranje porta? Zašto se to događa
WireGuard i očvrsli OpenVPN odbacuju datagrame koji ne prođu autentifikaciju bez odgovora. Tišina sa skenera je očekivano ponašanje, a ne zatvoren port.
Skenirate VPN port, ne dobijate odgovor i zaključujete da je usluga pala ili da je firewall zatvoren. Kod WireGuarda i kod OpenVPN kontrolnih kanala koji nose vlastitu autentifikaciju taj zaključak ne slijedi. Datagram bez valjanog autentifikacijskog materijala odbacuje se bez odgovora, pa je tišina ono kako zdrava usluga izgleda izvana. Sonda je pogrešna prije nego što je tunel.
Tišina je protokol, a ne kvar
UDP nema uspostavljanje veze, pa nema SYN-a ni potvrde koja bi skeneru omogućila da razlikuje otvoren port od filtriranog. Sonda dolazi kao izolirani datagram, a usluga provjerava odgovara li on protokolu koji očekuje. Kada ne odgovara, paket se odbacuje, a odbacivanje je dokumentirano ponašanje, a ne kvar.
WireGuard kriptografski provjerava svoje handshake poruke i zanemaruje sve što ne prođe. OpenVPN s tls-auth ili tls-crypt čini isto za svoj kontrolni kanal. U oba slučaja proizvoljni payload nikada ne dosegne fazu okrenutu korisniku, pa nema čime odgovoriti ni greške koju vratiti.
TCP bi vam dao reset sa zatvorenog porta. UDP vas ostavlja u nedoumici, koju skeneri rješavaju ispisom otvoren ili filtriran umjesto pogađanja.
Šta skener može, a šta ne može zaključiti
Rezultat skeniranja informativan je onoliko koliko je informativan payload koji je poslao. Poredajte moguća zapažanja prema tome šta svako od njih zapravo potvrđuje:
| 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 |
Čitajte treći red kao jedini pozitivni test na listi. On zahtijeva pravi profil, pravi ključ i ispravan endpoint, a to je upravo ono što generički skener nema.
Pogledajte oba kraja puta
Za server kojim upravljate, snimite na interfejsu prije nego donesete bilo kakav zaključak, a zatim pitajte uslugu šta je vidjela. Obje komande zahtijevaju root na gatewayu:
tcpdump -ni any udp port 51820
tcpdump -ni any udp port 1194
wg show
Ako se na interfejsu ne pojavi nijedan paket, put ga je odbacio prije nego što je usluga išta vidjela, a sljedeća stanica je rutiranje i filtriranje. Ako paketi stižu, ali handshake se ne završi, usluga je dostupna, a nesklad je u ključevima, konfiguraciji endpointa ili verziji protokola. To poređenje odgovara na pitanje na koje skener nije mogao. Pokrenite ga dok se pravi klijent pokušava spojiti, a ne dok skener ponavlja sebe.
Promijenite test, ne zaštitu
Primamljiva prečica je isključiti zaštitu kontrolnog kanala da bi dijagnostika dobila odgovor. To mijenja stvarno sigurnosno svojstvo za ljepši rezultat skeniranja i to je pogrešan smjer. Umjesto toga upotrijebite valjan profil s odobrene mreže i zabilježite endpoint i vrijeme kako bi poređenje bilo ponovljivo.
Najkorisniji test je diferencijalni: isti profil na putu koji radi i na putu koji ne radi. Ako radni put proizvede handshake, a neuspjeli put ne proizvede ništa na interfejsu, locirali ste prekid bez ikakvog slabljenja.
Neodgovoreni UDP paket stoga ne dokazuje ni da je server offline ni da je siguran. Dokazuje da ova sonda, na ovom putu, u ovom trenutku, nije prihvaćena.