Att byta namn på en Viscosity-fil .visz till .ovpn ändrar inte vad som finns inuti, eftersom filändelsen aldrig beskrev ett protokoll. Jämförelsen som spelar roll är mellan ett paket med beroenden och en vanlig klientprofil utan några. Avgör vilken container du faktiskt fick innan du ber en importör på Linux att läsa den.

Vad varje container innehåller

Viscositys exportdokumentation beskriver ett anslutningspaket av typen .visc och en arkivform .visz, som är ett komprimerat tar-arkiv. Ett paket bär konfigurationen tillsammans med de certifikat-, nyckel- och skriptfiler som det är beroende av. En vanlig OpenVPN-profil är en enda fil, och allt den refererar till måste finnas separat eller vara inbäddat inuti.

Den skillnaden är hela jämförelsen. Paketets relationer är en del av artefakten; den vanliga profilens relationer är ett antagande. Att flytta ett paket till Linux utan att bevara dessa relationer ger en fil som öppnas och sedan misslyckas vid den första saknade referensen. En profil som bäddar in sina certifikat undviker det felet genom att bära allt på ett ställe, vilket är praktiskt tills någon behöver byta ut ett av dem.

Den yttre filändelsen berättar vilken container du har, inte vilken klient som kan använda den.

Var konfigurationen faktiskt börjar

Inuti paketet dokumenterar leverantören en config.conf bredvid de beroende filerna, med referenser som löses lokalt. Den filen är utgångspunkten, inte arkivets namn och inte det certifikat som råkar ligga överst i kataloglistan.

På Linux kan paketet visas som en mapp i stället för ett enda objekt, eftersom arkivet packas upp till filer som förväntar sig att ligga tillsammans. Håll relativa sökvägar konsekventa i arbetsytan du packar upp till, och översätt inte en absolut Windows-sökväg till en Linux-sökväg för hand. En saknad beroende fil och en felaktig sökväg ger samma klagomål från klienten.

Att ta bort ett tillits- eller identitetsalternativ för att tysta det klagomålet är ingen rättelse.

Vad paketet inte tar med sig

Viscositys egna inställningar är inte alla OpenVPN-alternativ. Skript, ruttbeteende och programinställningar kan behöva representeras av Linux-klientens stödda integration i stället för att kopieras som text som ett annat program kan köra.

Behandla ett medföljande skript som data tills du har läst det och beslutat att det är tillåtet. Att köra det eftersom exporten innehöll det vänder på den granskning du skulle göra. Samma försiktighet gäller inbäddade inloggningsuppgifter: ett paket kan bära privat nyckelmaterial, så en arbetskopia hör hemma på en skyddad plats och inte i en nedladdningsmapp.

Originalet förblir skyddat tills migreringen accepteras.

Vad Linux-sidan måste avgöra

Avgör vem som ska äga anslutningen: Community OpenVPN ensamt, NetworkManager-insticksmodulen eller en annan stödd klient. Var och en accepterar en annan uppsättning alternativ, och var och en äger rutter, resolvers och hemligheter på sitt eget sätt. En fil som öppnas framgångsrikt i en importör kan avvisas av en annan, och framgång vid import bevisar inte kompatibilitet med den avsedda anslutningen. Fråga operatören om det redan finns en Linux-kompatibel profil, eftersom det är kortare att börja från den stödda artefakten än att översätta en.

Håll servertillit, klientidentitet och skydd av privat nyckel som tre separata frågor.

Granskningen innan du ansluter

Kontrollera slutpunkten och transporten, autentiseringsmetoden, varje filreferens och den avsedda rutt- och DNS-policyn. Verifiera sedan anslutningen och det nödvändiga programmet oberoende av varandra, eftersom en tunnel som kommer upp inte säger något om huruvida programmet når det det behöver.

openvpn --config ./config.conf --verb 4

Jämför det förhandlade resultatet med vad operatören säger att profilen ska göra, och notera alla alternativ som Linux-klienten ignorerade.

När migreringen accepteras, avveckla överföringskopiorna genom den vanliga processen för hantering av inloggningsuppgifter. Ett paket som lämnas i en delad mapp är inloggningsuppgifter som lämnas i en delad mapp.

Relaterade artiklar