Kva ei .ovpn-fil faktisk inneheld, og kva ho ikkje kan gjere

Dei fleste trur at ei .ovpn-fil konfigurerer ein VPN. Det gjer ho ikkje: ho konfigurerer éin klient, og alt ho ber om, må allereie finnast på den andre sida. Å endre ei linje i fila kan endre kva maskina di prøver, aldri kva serveren byr på. Den skilnaden forklarer det meste av forvirringa rundt profilar som ikkje kan importerast eller koplast til.

Les fila som ei liste med førespurnader retta mot klienten din, og dei fleste av linjene blir opplagde.

Fila skildrar klienten din, ikkje serveren

Ein profil samlar eit remote-endepunkt, ein transport, ein grensesnittlek, identitetsmateriale og kva som helst klientåtferd operatøren ønskjer. Kvar linje blir utførd av klienten ved oppstart. Ingen av dei når serveren som ei konfigurasjonsendring, og ingen kan skape ein lyttar som ikkje allereie køyrer. Ein profil som nemner TCP 443 mot ein server som berre lyttar på UDP 1194 feilar ved den første pakken.

Det er òg grunnen til at same fila gjer seg ulikt på to klientar: fila spør, og klienten avgjer kor mykje av førespurnaden han kan etterkome.

Transportlinjer må svare til ein lyttar som allereie finst

proto og remote linjer må stemme med det serveren faktisk bind. UDP er det vanlege valet fordi ein tapt datagram ikkje stoggar tunnelen, medan TCP kan overleve restriktive nettverk på kostnad av blokkering i køhovudet inne i tunnelen. Å bytte ein profil frå UDP til TCP får ikkje serveren til å godta TCP; det får berre klienten til å sende til ein port ingen les.

Port 443 er populær fordi han passerer nettverk som knapt tillèt noko anna, og han blir verande ein OpenVPN økt i staden for ein HTTPS-førespurnad. Viss operatøren publiserer fleire remote linjer, prøver klienten dei i rekkjefølgje, noko som er ei failover-liste og ikkje ei avgjerd om lastbalansering. Hald på kombinasjonane operatøren leverte i staden for å blande ein vert frå éin oppføring med ein port frå ei anna.

Innbygde nøklar endrar korleis du handterer fila

Sertifikat og nøklar kan stå innbygde mellom <ca>, <cert> og <key>-taggene, eller bli refererte til som separate filer. Innbygd materiale gjer profilen sjølvforsynt og gjer han òg til ein løyndom, fordi den private nøkkelen til klienten reiser inni han. Eit CA-sertifikat er offentleg tillitsmateriale og er trygt å dele; ein privat nøkkel er det ikkje, sjølv når han ser ut som ein uleseleg tekstblokk.

Passfrasen som verner ein nøkkel, er ein eigen løyndom frå kontopassordet, og å blande dei gir ein autentiseringsfeil som ser ut som feil påloggingsdetaljar.

Ruter og DNS kjem kanskje ikkje frå fila i det heile

Ruting kan bli dytta av serveren, sett av profilen med redirect-gateway, eller overlaten til klienten sine eigne standardverdiar. Fila du lasta ned avgjer derfor ikkje fullt ut kvar trafikken går etter at tunnelen er oppe. Når interne namn blir løyste og offentlege nettstader ikkje, gjer policyen for delt tunnel det han er laga for, og feilar ikkje.

DNS følgjer same mønster: ein dytta dhcp-option DNS kan bli brukt av klienten, ignorert eller overstyrt av ein lokal resolver-handterar. Sjekk tilstanden til resolvern etter tilkopling i staden for å lese profilen på nytt.

Ikkje-støtta val er eit spørsmål om klientversjon

Importåtvaringar tyder vanlegvis at klienten ikkje implementerer eit direktiv, ikkje at fila er øydelagd. Skrivebordsklientar kan køyre skript og plugins under dokumenterte kontrollar, medan mobilklientar godtek eit smalare sett og kan stille droppe linjer dei ikkje forstår. Ei cipher- eller TLS-innstilling som ein eldre klient avviser, er eit versjonsproblem som må løysast med operatøren. Å slå på ukjende rettar for å tvinge gjennom ein import byter ei åtvaring mot ei større åtaksoverflate.

Hald på originalfila for samanlikning, noter det nøyaktige ikkje-støtta direktivet i førespurnaden din, og be om ein profil bygd for klienten du faktisk køyrer.

Etter kvar utskifting, stadfest kva profiloppføring appen brukar, fordi import av ei ny fil ikkje alltid overskriv den gamle.