Co vlastně soubor .ovpn obsahuje a co nedokáže

Většina lidí předpokládá, že soubor .ovpn konfiguruje VPN. Není to tak: konfiguruje jednoho klienta a vše, co požaduje, už musí existovat na druhé straně. Změna řádku v souboru může změnit, co se váš stroj pokouší udělat, nikdy ne to, co nabízí server. Tento rozdíl vysvětluje většinu zmatků kolem profilů, které se nedaří importovat nebo připojit.

Čtěte soubor jako seznam požadavků adresovaných vašemu klientovi a většina jeho řádků bude zřejmá.

Soubor popisuje vašeho klienta, ne server

Profil spojuje remote koncový bod, transport, typ rozhraní, identitní materiál a jakékoli chování na straně klienta, které operátor chce. Každý řádek spouští klient při startu. Žádný z nich se nedostane na server jako změna konfigurace a žádný nemůže vytvořit naslouchající socket, který už neběží. Profil, který uvádí TCP 443 proti serveru, který poslouchá jen na UDP 1194 selže už na prvním paketu.

Proto se stejný soubor chová na dvou klientech různě: soubor žádá a klient rozhoduje, kolik z požadavku může splnit.

Transportní řádky musí odpovídat naslouchajícímu socketu, který už existuje

proto a remote musí odpovídat tomu, co server skutečně váže. UDP je obvyklá volba, protože ztracený datagram nezastaví tunel, zatímco TCP přežije restriktivní sítě za cenu blokování čela fronty uvnitř tunelu. Přepnutí profilu z UDP na TCP nezpůsobí, že server přijme TCP; jen způsobí, že klient posílá na port, který nikdo nečte.

Port 443 je oblíbený, protože prochází sítěmi, které téměř nic jiného nepovolují, a zůstává OpenVPN relací, nikoli požadavkem HTTPS. Pokud operátor zveřejní několik remote řádků, klient je zkouší v pořadí, což je seznam pro přepnutí při selhání, nikoli rozhodnutí o vyvažování zátěže. Zachovejte kombinace, které operátor dodal, místo abyste míchali hostitele z jedné položky s portem z jiné.

Vložené klíče mění, jak se souborem zacházíte

Certifikáty a klíče mohou být vložené mezi značkami <ca>, <cert> a <key>, nebo na ně lze odkázat jako na samostatné soubory. Vložený materiál dělá profil soběstačným a také z něj dělá tajemství, protože soukromý klíč klienta cestuje uvnitř. Certifikát CA je veřejný důvěryhodný materiál a je bezpečné ho sdílet; soukromý klíč ne, i když vypadá jako nečitelný blok textu.

Heslová fráze chránící klíč je samostatné tajemství od hesla účtu a jejich záměna vede k chybě ověřování, která vypadá jako špatné přihlašovací údaje.

Trasy a DNS nemusí pocházet ze souboru vůbec

Směrování může protlačit server, nastavit profil pomocí redirect-gateway, nebo může zůstat na vlastních výchozích hodnotách klienta. Stažený soubor tedy zcela neurčuje, kam provoz po zvednutí tunelu půjde. Když se interní názvy překládají a veřejné stránky ne, politika rozděleného tunelu dělá to, k čemu byla navržena, a neselhává.

DNS sleduje stejný vzor: protlačený dhcp-option DNS může klient použít, ignorovat nebo jej přebít místní správce překladače. Po připojení zkontrolujte stav překladače, místo abyste znovu četli profil.

Nepodporované volby jsou otázkou verze klienta

Upozornění při importu obvykle znamenají, že klient neimplementuje určitou direktivu, ne že je soubor poškozený. Desktopoví klienti mohou spouštět skripty a pluginy pod dokumentovanou kontrolou, zatímco mobilní klienti přijímají užší sadu a mohou tiše zahodit řádky, kterým nerozumí. Nastavení šifry nebo TLS, které starší klient odmítá, je problém verze, který je třeba řešit s operátorem. Zapnutí neznámých oprávnění k vynucení importu mění varování za širší útočnou plochu.

Uchovejte původní soubor pro srovnání, uveďte v žádosti přesnou nepodporovanou direktivu a požádejte o profil vytvořený pro klienta, kterého skutečně používáte.

Po každém nahrazení ověřte, kterou položku profilu aplikace používá, protože import nového souboru ne vždy přepíše starý.