OpenVPN-profilens flyttbarhet: flyttbara nycklar kontra plattformsalternativ
En .ovpn-fil blandar flyttbart identitetsmaterial med direktiv som bara en klient förstår. Jämför de två innan du ger certifikatet skulden för ett fel.
Samma .ovpn-fil öppnar en tunnel i en klient och startar inte i en annan, och certifikatet är oftast den första misstänkta. Oftare innehåller filen ett direktiv som bara en motor implementerar. En profil är ett avtal med en bestämd klient, inte ett flyttbart skript.
Skilj det som följer med identiteten från det som hör till en plattform. Då namnger felet sig oftast självt.
En fil, två avtal
En profil samlar tre slags innehåll: identitetsmaterial som CA- och klientcertifikat och den privata nyckeln, transportfakta som fjärrendpunkten och protokollet, och beteendedirektiv som DNS-hantering eller enhetsalternativ. De två första är brett flyttbara mellan motorer som stöder samma protokoll. Det tredje är där implementationerna går isär. Att behandla hela filen som en enda flyttbar enhet är det som skapar de förvirrande felen.
En fil som fungerar i ett GUI på en plattform är inte automatiskt giltig för kommandoradsklienten på en annan. Även när båda är OpenVPN skiljer sig parsrarna och alternativmängderna. Därför är en lyckad import inget bevis på en flyttbar profil.
Flyttbart material kontra plattformsdirektiv
Identitets- och transportavsnitten är den del som ska bevaras. ca, cert, key och remote beskriver vem som ansluter och vart, och de betyder samma sak för varje konform klient.
Beteendedirektiv är den del som ska jämföras. block-outside-dns finns till exempel för att ändra DNS-beteendet i Windows. En Unix-klient känner kanske inte igen det alls.
Läs alternativlistan för den mottagande klienten i stället för den sändande. OpenVPN 2.6-referenshandboken dokumenterar motorns alternativ, och importdialogen i ett GUI är inte den listan.
Läs parserfelet före certifikatet
Ett fel som namnger ett okänt alternativ är ett parserfel, inte ett autentiseringsfel. Anslutningen nådde aldrig TLS, så att byta certifikat kan inte hjälpa. Läs det första felet från den faktiska klienten och versionen och ta sedan bort eller ersätt bara det direktiv som klienten inte kan implementera. Att radera certifikat- eller ruttavsnitt för att få filen att läsas in är vägen där en fungerande profil blir osäker.
Om felet nämner handskakningen, ett certifikat eller ett chiffer parsades profilen och problemet ligger någon annanstans.
Behåll originalfilen bredvid den anpassade. När den anpassade filen senare misslyckas är originalet kontrollen som säger om ändringen eller miljön flyttade sig.
Behörigheter är en andra gräns
Behörigheter är den andra gränsen: att skapa en tunnelenhet, installera rutter och läsa en privat nyckel beror alla på lokala rättigheter. En nyckelfil som bara root kan läsa är en normal driftsättning, inte en profildefekt. Rättelsen hör till ägande eller kapabiliteter, inte i filen.
Att köra klienten med sudo kan lösa ett lokalt åtkomstnekande, och det kan inte lägga till ett direktiv som binärfilen inte implementerar. Det ändrar också vilken nyckelring, vilka konfigurationssökvägar och vilken nätverkshanterarkontext som gäller, så resultatet är inte samma test.
Anpassa medvetet
När en leverantör publicerar separata profiler tar du den som är avsedd för den mottagande klienten. Att anpassa en annan plattforms fil är en sista utväg. Det kräver en förteckning över varje ändrat alternativ och en kopia av originalet.
Testa identitet, routning och DNS som tre separata utfall. En profil som autentiserar och routar men bryter namnmatchningen är en delvis anpassad profil, inte en fungerande.