Hogyan ellenőrizzük egy OpenVPN-profil szerverét importálás előtt

Valaki elküld Önnek egy profilt, Ön importálja, és harminc másodperccel később egy kliens olyan célpontot tárcsáz, amelyet senki nem ellenőrzött. Először olvassa el a fájlt egy szövegszerkesztőben, mert minden lényeges egy marék direktívában van: remote, proto, port, ca, cert, tls-crypt és verify-x509-name. Minden más alapértelmezés, és a meglepetések épp ott laknak.

Sorolja fel az összes végpontot, amelyet a fájl használhat

Kezdje a végpontokkal, mert egy profil többet is tartalmazhat. A grep -nE '^[[:space:]]*(remote|proto|port|remote-random|connection)' profile.ovpn minden jelöltet a fájl sorrendjében nyomtat ki, beleértve a beágyazott <connection> blokkok belsejében lévőket is.

Amikor egy direktíva elhagyja a portot, a kliens visszaesik a figyelő alapértelmezésére, így a csak remote vpn.example.com az 1194-es portot jelenti, bármilyen proto is jelenjen meg később a fájlban. Több egyszerű remote sor alternatíva: a kliens sorrendben próbálja őket, hacsak a remote-random össze nem keveri, és soha nem cseréli csendben egy másik szolgáltató gazdagépére. Két remote sor egymástól független tartományokon az a pont, ahol megáll és megkérdezi, melyiket szánták.

Figyeljen a proto írásmódjára is. A tcp elfogadott a kliensoldali tcp-client szinonimájaként, de a tcp-server kliensprofilban konfigurációs hiba, amely inkább elakad, mint tisztán meghiúsul.

Először a nevet, aztán a portot erősítse meg

A dig +short vpn.example.com megmondja, létezik-e a név és milyen címeket ad vissza, és egy többcímes vagy proxy mögötti végpont jogosan adhat vissza többet. A névfeloldás előfeltétel, nem a tulajdon bizonyítéka; bárki irányíthat egy nevet egy címre, és egy cím sok névre válaszolhat.

Ezután ellenőrizze a figyelőt a megtalált porton, a szállítási rétegnek megfelelően. TCP felett a openssl s_client -connect vpn.example.com:1194 -servername vpn.example.com kinyomtatja a kiszolgáló által bemutatott láncot. UDP felett DTLS kell: a openssl s_client -dtls1_2 -connect vpn.example.com:1194 ugyanazt a kézfogást futtatja datagramokon. A befejezett kézfogás bizonyítja, hogy valami figyel és tanúsítványt tart, ami több annál, mint amit a ping mutat, és kevesebb annál, mint amit a profil saját bizalmi beállításai megkövetelnek.

Amikor a kézfogás meghiúsul, és a gazdagép válaszol a pingre, a port valószínűleg rossz vagy szűrt. Tekintse ezt oknak a helyes port kérésére, nem meghívásnak a közeli portok végigseprésére. A nc -vzu egyes vermeken akkor is sikert jelent, amikor semmi nem figyel, így a puszta UDP-próba semmit sem jelent kézfogás nélkül mögötte.

A bizalmi tűket a címtől külön olvassa

A cím dönti el, hová megy a kliens; a bizalmi blokk dönti el, kiben hisz, amikor megérkezik. A verify-x509-name "vpn.example.com" name a tárgy köznapnevét tűzi ki, a remote-cert-tls server pedig megköveteli a kiterjesztett kulcshasználatot a kiszolgáló hitelesítéséhez. A szolgáltató által adott profilnak mindkettőt hordoznia kell.

Keresse a ca-t, egy beágyazott <ca> blokkot, és vagy a tls-crypt-öt, vagy a tls-auth-ot. A tls-auth-et használó profilnak a kliensen key-direction 1 kell, amikor a kiszolgáló oldal a 0 irányt használja, és az eltérés TLS-hibával buktatja a kézfogást, amely tanúsítványhibának olvasható. Az a beágyazott CA, amely nem ahhoz a szolgáltatóhoz tartozik, akinek a nevét épp most oldotta fel, azt jelenti, hogy a fájlt két forrásból állították össze, és ez az az eset, amelyet egyértelműen vissza kell utasítani.

A verify-x509-name a name, name-prefix vagy subject módot fogadja el, és az utolsó a teljes megkülönböztető nevet pontosan abban a sorrendben várja, ahogy a kiszolgáló kiírja. Olyan módot válasszon, amely illik az érték alakjához, mert a kliens minden kapcsolatot elutasít ahelyett, hogy közeli találatról figyelmeztetne. Egy Ön által nem írt fájlhoz az egyszerű gazdagépnévvel használt name a legkevésbé meglepő választás.

Ellenőrizze a csendben meghiúsuló beállításokat

A OpenVPN 2.6 a data-ciphers-en keresztül tárgyalja a titkosításokat, és egy csak régi cipher AES-256-CBC sort hordozó profil befejezheti a vezérlőcsatornát, majd elakadhat az adatoknál. Ennek az értéknek az olvasása megmondja, hogy a fájl régebbi-e annál a kiszolgálónál, amelyhez csatlakozik; a 2.6 kézikönyvoldala felsorolja a tárgyalási sorrendet, ha idéznie kell a szolgáltatónak.

A fájlnév nélküli auth-user-pass azt jelenti, hogy a kliens kérdezni fog, tehát az önállónak tűnő profilnak is kellenek hitelesítő adatok. A auth-user-pass credentials.txt azt jelenti, hogy olyan fájlt vár, amelyet valószínűleg nem küldtek el Önnek. A nobind és a resolv-retry infinite szokásos és ártalmatlan, míg a explicit-exit-notify csak UDP-hez való, és TCP felett értelmetlen.

Ezek egyike sem változtatja meg, hová csatlakozik a profil, de mindegyik megváltoztatja, hogy egyáltalán csatlakozik-e, és egyik sem látható a kliens importálási párbeszédablakában.

Döntsön, majd rögzítse, mit döntött

Az olvasás után három kimenetel van, és csak egy az importálás. Amikor a végpont és a tűk egyeznek a külön csatornán kapott utasításokkal, importálja. Amikor a végpont helyesnek tűnik, de a tűk vagy a CA nem egyeznek, kérjen javított fájlt. Amikor a fájl különböző forrásokból származó végpontokat vagy CA-anyagot kever, törölje, és kérjen friss másolatot.

Rögzítse az átnézett hash-t, hogy a következő ember tudja, változott-e a fájl: sha256sum profile.ovpn, a végpont mellé illesztve a jegyzeteiben. A profil egész elrendezés, nem címek listája, ezért soha ne illesszen egy működő remote-ot valaki más bizalmi blokkjába a hitelesítő adataik megtartásával.

Tartsa a privát kulcsokat és jelszavakat a képernyőképeken és csevegésszálakon kívül, miközben a jegyzeteit összeveti. A végpont és a nem titkos beállítások elegendőek egy pontos kérdéshez, a többi pedig a fájlban marad.

Ha mégis importálja, és az első kísérlet meghiúsul, futtassa a klienst a --verb 3 kapcsolóval, és olvassa el az első tíz sort: a feloldott remote-cím, a tárgyalt proto és a TLS-hiba ebben a sorrendben jelenik meg, ami megmondja, melyik ellenőrzést hagyta ki fent.