OpenVPN az 53-as porton: három beszélgetés, amit összekevernek
A végpont feloldása, a titkosított átvitel és az alagút utáni DNS három beszélgetés. Állapítsa meg, melyik szakasz hibázott, mielőtt portot vagy feloldót vált.
Azok a jelentések, amelyek szerint a VPN blokkolva van az 53-as porton, három olyan megfigyelést kevernek össze, amelyek különböző okokból hibáznak. A végpont nevének feloldása még azelőtt történik, hogy bármilyen alagút létezne, a titkosított átvitel külön beszélgetés, és a később végzett DNS-kérések a harmadik. Mindegyiknek megvan a maga hiba-aláírása, és közülük csak egy szól a DNS-ről.
Rendezze a csomagokat cél szerint, mielőtt bármit módosítana, mert a javítás a szakaszt követi.
Három beszélgetés, egy portszám
Az első beszélgetés a végpont nevének keresése: a gépe a beállított feloldót kérdezi meg arról, hogy hol található vpn.example.com, és ez a válasz a szokásos DNS-en érkezik, mielőtt a kliens egyetlen alagútcsomagot is elküldene. A második maga az OpenVPN-átvitel, amely ahhoz a címhez csatlakozik, amelyet a keresés adott, azon a protokollon és porton, amelyet a profil megnevez. A harmadik azután történik, hogy az alagút felállt, amikor az alkalmazások neveket kérnek, és a leküldött feloldóbeállítások döntik el, ki válaszol.
Ez a három egymástól függetlenül sikerülhet vagy hibázhat. Egy kliens tökéletesen feloldhatja a végpontját, és mégis elakadhat, mielőtt elérné a figyelőt, és alagutat is létesíthet úgy, hogy minden belső névfeloldás hibázik, mert a DNS-beállítások soha nem érkeztek meg.
| Conversation | When it happens | What has to be true |
|---|---|---|
| Endpoint lookup | Before the client contacts a hostname | An underlying resolver path can answer for the endpoint name |
| OpenVPN transport | During tunnel establishment | The gateway listens on its configured transport, address and port, and nothing filters it |
| Application DNS | During or after the protected session | A resolver the client can reach, plus routing that carries its queries |
A táblázatot ellenőrzőlistaként olvassa, ne leírásként. Ha a végpont neve nem oldódik fel, semmi későbbi nem működhet, és az alagút el sem indul.
A portszám nem nevezi meg az alkalmazást
Az 53-as port hagyományból DNS-t hordoz, és egy OpenVPN-üzemeltető is közzétehet ott figyelőt, éppen ezért rossz azonosító a szám. Az UDP 53-on futó OpenVPN-munkamenet továbbra is OpenVPN-munkamenet, és az 53-as porton lévő kiszolgálónak küldött DNS-kérdés semmit nem mond arról, engedélyezett-e az alagút. A profil proto és remote sorai határozzák meg a külső végpontot; a portszám önmagában semmit nem határoz meg.
Ez diagnosztikánál mindkét irányba vág: az 53-as portra küldött általános UDP-próba azt bizonyítja, hogy egy port válaszol, nem azt, hogy a VPN-szolgáltatás válaszol. A valódi klienssel és a valódi profillal teszteljen, mert csak az gyakorolja azt a kézfogást, amelyet a szolgáltatás vár.
Bizonyítsa a figyelőt, mielőtt a hálózatot hibáztatja
A kiszolgálón ellenőrizze ss -lunp | grep 53 segítségével, mi van kötve, és hasonlítsa össze a profil protokolljával és portjával. A kliens hálózatából futtassa a klienst nagyobb részletességgel, hogy a napló mutassa, melyik címet és átvitelt próbálta. Ha a kiszolgáló figyel, és a kliens csomagjai nem érkeznek meg, az útvonal vagy a szabályzat tagadja meg őket, és ez a hálózat tulajdonosával folytatott beszélgetés, nem ok a portváltásra.
Egy másik port csak akkor segít, ha a szolgáltatás valóban ott figyel, és az üzemeltetés engedi. A figyelő áthelyezése egy felügyelt hálózat szűrésének kikerülésére szabályzati döntés, nem hibaelhárítási lépés. Kérdezze meg a hálózat tulajdonosát, mi engedélyezett, mielőtt a szolgáltatást módosítja, mert a szabályzatot sértő kerülőutat később úgyis lezárják. Jegyezze fel a választ a profil mellé, hogy a következő ember ne ismételje meg a kérést.
Ellenőrizze a DNS-t az alagút után, külön
Miután az alagút felállt, vizsgálja meg a feloldó állapotát a VPN-interfészen, és kérdezzen le egy belső és egy nyilvános nevet. Ha a belső nevek hibáznak, miközben az alagút forgalmat szállít, a leküldött DNS-beállítások nem érvényesültek, ami kliensintegrációs kérdés, nem átviteli. Ha a nyilvános nevek hibáznak, a belső nevek pedig működnek, az osztott alagút szabályzata azt teszi, amire beállították.
A DNS-változásokat hagyja a feloldó tulajdonosánál. Egy felügyelt feloldókonfiguráció felülírása egyetlen teszt kedvéért elronthatja a privát neveket a gép minden más használata számára. Ha az alagút feloldót küld le, és a kliens figyelmen kívül hagyja, a kliensintegrációt javítsa ahelyett, hogy máshol statikus bejegyzést adna hozzá. A statikus bejegyzések elrejtik a hibát, amíg valaki hálózatot nem vált. Írja le, melyik névtérre melyik feloldónak kell válaszolnia.