Jak ověřit server profilu OpenVPN před importem

Někdo vám pošle profil, vy jej naimportujete a o třicet sekund později klient vytáčí cíl, který nikdo neprověřil. Nejprve si soubor přečtěte v textovém editoru, protože vše podstatné se vejde do hrstky direktiv: remote, proto, port, ca, cert, tls-crypt a verify-x509-name. Všechno ostatní jsou výchozí hodnoty a právě tam bydlí překvapení.

Vypište každý koncový bod, který soubor může použít

Začněte koncovými body, protože jeden profil jich může obsahovat několik. grep -nE '^[[:space:]]*(remote|proto|port|remote-random|connection)' profile.ovpn vypíše každého kandidáta v pořadí souboru, včetně těch vnořených do vložených bloků <connection>.

Když direktiva vynechá port, klient se vrátí k výchozí hodnotě naslouchajícího procesu, takže samotné remote vpn.example.com znamená port 1194 s jakýmkoli proto, který se v souboru objeví později. Několik obyčejných řádků remote jsou alternativy: klient je zkouší popořadě, pokud je remote-random nezamíchá, a nikdy potichu nenahradí hostitele jiného operátora. Dva řádky remote na nesouvisejících doménách jsou místo, kde se zastavíte a zeptáte se, který byl míněn.

Všimněte si i pravopisu proto. tcp se přijímá jako synonymum klientského tcp-client, ale tcp-server v klientském profilu je chyba konfigurace, která spíš visí, než aby čistě selhala.

Nejprve potvrďte jméno, pak port

dig +short vpn.example.com vám řekne, zda jméno existuje a které adresy vrací, a koncový bod s více adresami nebo za proxy může legitimně vrátit několik. Rozlišení jména je předpoklad, ne důkaz vlastnictví; kdokoli může namířit jméno na adresu a jedna adresa může odpovídat za mnoho jmen.

Potom zkontrolujte naslouchající proces na portu, který jste našli, podle transportu. Po TCP openssl s_client -connect vpn.example.com:1194 -servername vpn.example.com vypíše řetězec, který server předkládá. Po UDP potřebujete DTLS: openssl s_client -dtls1_2 -connect vpn.example.com:1194 vede stejný handshake přes datagramy. Dokončený handshake dokazuje, že něco naslouchá a drží certifikát, což je víc, než ukáže ping, a méně, než vyžadují vlastní nastavení důvěry profilu.

Když handshake selže a hostitel na ping odpovídá, port je pravděpodobně špatný nebo filtrovaný. Berte to jako důvod vyžádat správný port, ne jako pozvánku pročesat ty sousední. nc -vzu navíc na některých sítích hlásí úspěch, i když nic nenaslouchá, takže holá UDP sonda nic neznamená bez handshaku za ní.

Špendlíky důvěry čtěte odděleně od adresy

Adresa rozhoduje, kam klient jde; blok důvěry rozhoduje, komu uvěří, když dorazí. verify-x509-name "vpn.example.com" name připíná obecné jméno subjektu a remote-cert-tls server vyžaduje rozšířené použití klíče pro autentizaci serveru. Profil, který vám předá operátor, by měl nést obojí.

Hledejte ca, vložený blok <ca> a buď tls-crypt, nebo tls-auth. Profil s tls-auth potřebuje na klientu key-direction 1, když strana serveru používá směr 0, a neshoda shodí handshake chybou TLS, která se čte jako závada certifikátu. Vložená CA, která nepatří operátorovi, jehož jméno jste právě rozlišili, znamená, že soubor byl složen ze dvou zdrojů, a to je případ, který je wart rozhodného odmítnutí.

verify-x509-name přijímá režimy name, name-prefix nebo subject a poslední očekává plné rozlišující jméno v přesném pořadí, v jakém je server vypisuje. Vyberte režim, který odpovídá tvaru hodnoty, protože klient odmítne každé spojení místo varování před blízkým minutím. Pro soubor, který jste nenapsali, je name s prostým jménem hostitele nejméně překvapivá volba.

Zkontrolujte volby, které selhávají potichu

OpenVPN 2.6 vyjednává šifry přes data-ciphers a profil, který nese jen starý řádek cipher AES-256-CBC, může dokončit řídicí kanál a pak uváznout na datech. Přečtení této hodnoty vám řekne, zda soubor předchází server, ke kterému se připojujete; stránka manuálu pro 2.6 uvádí pořadí vyjednávání, pokud to potřebujete operátorovi ocitovat.

auth-user-pass bez názvu souboru znamená, že se klient zeptá, takže profil, který vypadá soběstačně, přesto potřebuje přihlašovací údaje. auth-user-pass credentials.txt znamená, že očekává soubor, který vám pravděpodobně neposlali. nobind a resolv-retry infinite jsou obyčejné a neškodné, zatímco explicit-exit-notify je jen pro UDP a přes TCP zbytečný.

Nic z toho nemění, kam se profil připojuje, ale každé mění, zda se připojí vůbec, a nic z toho není vidět v dialogu importu klienta.

Rozhodněte a pak zapište, co jste rozhodli

Po tomto čtení existují tři výsledky a jen jeden je import. Když koncový bod a špendlíky odpovídají pokynům, které jste dostali jiným kanálem, naimportujte jej. Když koncový bod vypadá správně, ale špendlíky nebo CA nesedí, požádejte o opravený soubor. Když soubor míchá koncové body nebo materiál CA z různých zdrojů, smažte jej a požádejte o čerstvou kopii.

Zapište hash, který jste prošli, aby další člověk poznal, zda se soubor změnil: sha256sum profile.ovpn, vložený vedle koncového bodu ve vašich poznámkách. Profil je celistvé uspořádání, ne seznam adres, takže nikdy nezapojujte funkční remote do cizího bloku důvěry a přitom si nechte jejich přihlašovací údaje.

Soukromé klíče a hesla držte mimo snímky obrazovky a chatová vlákna, když porovnáváte poznámky. Koncový bod a neveřejné volby stačí k přesné otázce a zbytek patří do souboru.

Pokud jej přesto naimportujete a první pokus selže, spusťte klienta s --verb 3 a přečtěte si prvních deset řádků: rozlišená adresa remote, vyjednaný proto a chyba TLS se objevují v tomto pořadí, což vám řekne, kterou z kontrol výše jste vynechali.