UDP-s VPN hallgat a portvizsgálatnál? Miért történik ez
A WireGuard és a megerősített OpenVPN válasz nélkül dobja el a hitelesítésen át nem jutó datagramokat. A vizsgáló felől érkező csend várt viselkedés, nem zárt port.
Megvizsgálja a VPN portját, nem kap választ, és arra jut, hogy a szolgáltatás leállt, vagy hogy a tűzfal zárva van. A WireGuardnál és a saját hitelesítést hordozó OpenVPN-vezérlőcsatornáknál ez a következtetés nem áll. Az érvényes hitelesítési anyag nélküli datagram válasz nélkül eldobódik, tehát a csend az, ahogy egy egészséges szolgáltatás kívülről látszik. A próba hamarabb téves, mint az alagút.
A csend maga a protokoll, nem hiba
Az UDP-nek nincs kapcsolatfelépítése, így nincs SYN és nincs olyan nyugta, amely lehetővé tenné egy vizsgáló számára a nyitott port megkülönböztetését a szűrttől. A próba izolált datagramként érkezik, és a szolgáltatás ellenőrzi, hogy megfelel-e az elvárt protokollnak. Ha nem, a csomag eldobódik, és az eldobás a dokumentált viselkedés, nem üzemzavar.
A WireGuard kriptográfiailag ellenőrzi a kézfogási üzeneteit, és mindent figyelmen kívül hagy, ami meghiúsul. OpenVPN a tls-auth vagy tls-crypt mellett ugyanezt teszi a vezérlőcsatornájával. Mindkét esetben egy tetszőleges hasznos teher soha nem ér el felhasználó felé forduló szakaszt, így nincs mivel válaszolni, és nincs visszaadandó hiba.
A TCP visszaállítást adott volna egy zárt portról. Az UDP bizonytalanságban hagyja, amelyet a vizsgálók úgy oldanak fel, hogy nyitott vagy szűrt értéket írnak ki találgatás helyett.
Mit vonhat le egy vizsgáló és mit nem
Egy vizsgálat eredménye csak annyira informatív, mint az elküldött hasznos teher. Rendezze a lehetséges megfigyeléseket aszerint, hogy melyik mit támaszt alá valójában:
| 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 |
Olvassa a harmadik sort a lista egyetlen pozitív tesztjeként. Ehhez valódi profil, valódi kulcs és helyes végpont kell, és pontosan ez az, ami egy általános vizsgálónak nincs.
Nézze meg az útvonal mindkét végét
Egy általa felügyelt kiszolgálónál rögzítsen az interfészen, mielőtt bármilyen következtetést levon, majd kérdezze meg a szolgáltatást, mit látott. Mindkét parancshoz root kell az átjárón:
tcpdump -ni any udp port 51820
tcpdump -ni any udp port 1194
wg showHa nem jelenik meg csomag az interfészen, az útvonal még az előtt eldobta, hogy a szolgáltatás bármit látott volna, és a következő állomás az útválasztás és a szűrés. Ha a csomagok megérkeznek, de egyetlen kézfogás sem fejeződik be, a szolgáltatás elérhető, és az eltérés a kulcsokban, a végpont konfigurációjában vagy a protokoll verziójában van. Ez az összehasonlítás válaszol arra a kérdésre, amelyre a vizsgáló nem tudott. Akkor futtassa, amikor egy valódi kliens csatlakozni próbál, nem amikor a vizsgáló ismétli önmagát.
A tesztet változtassa meg, ne a védelmet
A csábító rövidítés a vezérlőcsatorna védelmének kikapcsolása, hogy egy diagnosztika választ kapjon. Ez egy valódi biztonsági tulajdonságot cserél szebb vizsgálati eredményre, és ez a rossz irány. Használjon inkább érvényes profilt egy jóváhagyott hálózatról, és jegyezze fel a végpontot és az időt, hogy az összehasonlítás megismételhető legyen.
A leghasznosabb teszt egy differenciális: ugyanaz a profil egy működő útvonalon és a nem működő útvonalon. Ha a működő útvonal kézfogást hoz létre, a sikertelen útvonal pedig semmit az interfészen, akkor minden gyengítése nélkül lokalizálta a törést.
Egy megválaszolatlan UDP-csomag tehát nem bizonyítja sem azt, hogy a kiszolgáló offline, sem azt, hogy biztonságos. Azt bizonyítja, hogy ez a próba, ezen az útvonalon, ebben a pillanatban nem kapott elfogadást.