UDP VPN mlčí při skenování portů? Proč se to děje
WireGuard a zpevněný OpenVPN zahazují datagramy, které neprojdou autentizací, aniž by odpověděly. Ticho od skeneru je očekávané chování, ne zavřený port.
Skenujete port VPN, nedostanete odpověď a usoudíte, že služba nefunguje nebo že je firewall zavřený. U WireGuardu a u řídicích kanálů OpenVPN, které nesou vlastní autentizaci, tento závěr neplatí. Datagram bez platného autentizačního materiálu je zahozen bez odpovědi, takže ticho je to, jak zdravá služba vypadá zvenčí. Sonda je špatná dřív, než je špatný tunel.
Ticho je protokol, ne závada
UDP nemá navazování spojení, takže neexistuje SYN ani potvrzení, které by skeneru umožnilo rozeznat otevřený port od filtrovaného. Sonda přichází jako izolovaný datagram a služba ověřuje, zda odpovídá protokolu, který očekává. Když neodpovídá, paket se zahodí, a zahození je dokumentované chování, nikoli porucha.
WireGuard kryptograficky ověřuje své zprávy handshake a všechno, co neprojde, ignoruje. OpenVPN s tls-auth nebo tls-crypt dělá totéž pro svůj řídicí kanál. V obou případech se libovolný payload nikdy nedostane do fáze obrácené k uživateli, takže není čím odpovědět a není chybu, kterou vrátit.
TCP by vám dal reset ze zavřeného portu. UDP vás nechává v nejistotě, kterou skenery řeší vypsáním otevřený nebo filtrovaný místo hádání.
Co skener může a co nemůže usoudit
Výsledek skenování je tak informativní, jak informativní je odeslaný payload. Seřaďte možná pozorování podle toho, co každé z nich skutečně potvrzuje:
| 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 |
Čtěte třetí řádek jako jediný pozitivní test v seznamu. Vyžaduje skutečný profil, skutečný klíč a správný endpoint, což je přesně to, co obecný skener nemá.
Podívejte se na oba konce cesty
U serveru, který spravujete, zachyťte provoz na rozhraní, než uděláte jakýkoli závěr, a potom se služby zeptejte, co viděla. Oba příkazy vyžadují root na bráně:
tcpdump -ni any udp port 51820
tcpdump -ni any udp port 1194
wg showPokud se na rozhraní neobjeví žádný paket, cesta ho zahodila dřív, než služba cokoli viděla, a další zastávkou je směrování a filtrování. Pokud pakety dorazí, ale handshake se nedokončí, služba je dostupná a neshoda je v klíčích, konfiguraci endpointu nebo verzi protokolu. Toto srovnání odpovídá na otázku, kterou skener nedokázal. Spusťte ho, když se skutečný klient pokouší připojit, ne když skener opakuje sám sebe.
Změňte test, ne ochranu
Lákavou zkratkou je vypnout ochranu řídicího kanálu, aby diagnostika dostala odpověď. To vyměňuje skutečnou bezpečnostní vlastnost za hezčí výsledek skenování a je to špatný směr. Použijte místo toho platný profil ze schválené sítě a poznamenejte endpoint a čas, aby bylo srovnání opakovatelné.
Nejužitečnější test je diferenciální: stejný profil na cestě, která funguje, a na cestě, která nefunguje. Pokud funkční cesta vytvoří handshake a selhávající cesta nevytvoří na rozhraní nic, lokalizovali jste přerušení, aniž byste cokoli oslabili.
Neodpovězený UDP paket tedy nedokazuje ani to, že je server offline, ani to, že je bezpečný. Dokazuje, že tato sonda, na této cestě, v tomto okamžiku nebyla přijata.