Vad en .ovpn-fil egentligen innehåller, och vad den inte kan göra

De flesta antar att en .ovpn-fil konfigurerar en VPN. Det gör den inte: den konfigurerar en klient, och allt den begär måste redan finnas på andra sidan. Att ändra en rad i filen kan ändra vad din maskin försöker, aldrig vad servern erbjuder. Den skillnaden förklarar det mesta av förvirringen kring profiler som inte kan importeras eller anslutas.

Läs filen som en lista med förfrågningar riktade till din klient, och de flesta av dess rader blir självklara.

Filen beskriver din klient, inte servern

En profil samlar en remote-ändpunkt, en transport, en gränssnittstyp, identitetsmaterial och alla klientbeteenden som operatören vill ha. Varje rad körs av klienten vid start. Ingen av dem når servern som en konfigurationsändring, och ingen kan skapa en lyssnare som inte redan körs. En profil som anger TCP 443 mot en server som bara lyssnar på UDP 1194 misslyckas vid det första paketet.

Det är också därför samma fil beter sig olika på två klienter: filen frågar, och klienten avgör hur mycket av begäran den kan uppfylla.

Transportrader måste matcha en lyssnare som redan finns

proto och remote måste stämma med det servern faktiskt binder. UDP är det vanliga valet eftersom ett förlorat datagram inte stoppar tunneln, medan TCP kan överleva restriktiva nätverk till priset av blockering i köns huvud inne i tunneln. Att byta en profil från UDP till TCP får inte servern att acceptera TCP; det får bara klienten att skicka till en port som ingen läser.

Port 443 är populär eftersom den passerar nätverk som knappt tillåter något annat, och den förblir en OpenVPN session i stället för en HTTPS-förfrågan. Om operatören publicerar flera remote rader provar klienten dem i ordning, vilket är en failover-lista och inte ett beslut om lastbalansering. Behåll kombinationerna operatören levererade i stället för att blanda en värd från en post med en port från en annan.

Inbäddade nycklar ändrar hur du hanterar filen

Certifikat och nycklar kan stå inbäddade mellan <ca>, <cert> och <key>-taggarna, eller refereras som separata filer. Inbäddat material gör profilen självförsörjande och gör den också till en hemlighet, eftersom klientens privata nyckel färdas inuti den. Ett CA-certifikat är offentligt förtroendematerial och är säkert att dela; en privat nyckel är det inte, även när den ser ut som ett oläsligt textblock.

Lösenfrasen som skyddar en nyckel är en egen hemlighet från kontolösenordet, och att blanda ihop dem ger ett autentiseringsfel som ser ut som fel inloggningsuppgifter.

Rutter och DNS kanske inte kommer från filen alls

Routing kan knuffas av servern, ställas in av profilen med redirect-gateway, eller lämnas åt klientens egna standardvärden. Filen du laddade ner avgör därför inte helt vart trafiken tar vägen efter att tunneln är uppe. När interna namn löses upp och offentliga webbplatser inte gör det, gör policyn för delad tunnel det den är designad för, och misslyckas inte.

DNS följer samma mönster: en knuffad dhcp-option DNS kan tillämpas av klienten, ignoreras eller skrivas över av en lokal resolverhanterare. Kontrollera resolverens status efter anslutning i stället för att läsa profilen igen.

Icke-stödda alternativ är en fråga om klientversion

Importvarningar betyder oftast att klienten inte implementerar ett direktiv, inte att filen är skadad. Skrivbordsklienter kan köra skript och plugin under dokumenterade kontroller, medan mobilklienter accepterar en snävare uppsättning och kan tyst hoppa över rader de inte förstår. En cipher- eller TLS-inställning som en äldre klient avvisar är ett versionsproblem som måste lösas med operatören. Att aktivera okända behörigheter för att tvinga igenom en import byter en varning mot en större attackyta.

Behåll originalfilen för jämförelse, anteckna det exakta icke-stödda direktivet i din begäran och be om en profil byggd för den klient du faktiskt kör.

Efter varje utbyte, bekräfta vilken profilpost appen använder, eftersom import av en ny fil inte alltid skriver över den gamla.