Viscosity-eksport kontra en vanlig OpenVPN-profil på Linux

Å gi en Viscosity-fil .visz nytt navn til .ovpn endrer ikke det som ligger inni, fordi filendelsen aldri beskrev en protokoll. Sammenligningen som betyr noe, er mellom en pakke med avhengigheter og en vanlig klientprofil uten noen. Avgjør hvilken container du faktisk mottok, før du ber en importør på Linux om å lese den.

Hva hver container inneholder

Viscositys eksportdokumentasjon beskriver en tilkoblingspakke av typen .visc og en arkivform .visz, som er et komprimert tar-arkiv. En pakke bærer konfigurasjonen sammen med sertifikat-, nøkkel- og skriptfilene den er avhengig av. En vanlig OpenVPN-profil er én fil, og alt den viser til, må finnes separat eller være innebygd inni.

Den forskjellen er hele sammenligningen. Pakkens relasjoner er en del av artefakten; den vanlige profilens relasjoner er en antakelse. Å flytte en pakke til Linux uten å bevare disse relasjonene gir en fil som åpnes og deretter feiler på den første manglende referansen. En profil som bygger inn sertifikatene sine, unngår den feilen ved å bære alt på ett sted, noe som er praktisk helt til noen må bytte ut ett av dem.

Den ytre filendelsen forteller hvilken container du har, ikke hvilken klient som kan bruke den.

Hvor konfigurasjonen faktisk begynner

Inne i pakken dokumenterer leverandøren en config.conf ved siden av de avhengige filene, med referanser som løses lokalt. Den filen er utgangspunktet, ikke arkivets navn og ikke sertifikatet som tilfeldigvis ligger øverst i kataloglisten.

På Linux kan pakken fremstå som en mappe i stedet for et enkelt objekt, fordi arkivet pakkes ut til filer som forventer å ligge sammen. Hold relative stier sammenhengende i arbeidsområdet du pakker ut til, og ikke oversett en absolutt Windows-sti til en Linux-sti for hånd. En manglende avhengig fil og en feil sti gir samme klage fra klienten.

Å slette et tillits- eller identitetsalternativ for å dempe den klagen er ikke en retting.

Hva pakken ikke tar med seg

Viscositys egne innstillinger er ikke alle OpenVPN-alternativer. Skript, ruteatferd og applikasjonsinnstillinger må kanskje representeres av Linux-klientens støttede integrasjon i stedet for å kopieres som tekst et annet program kan kjøre.

Behandle et medfølgende skript som data til du har lest det og bestemt at det er tillatt. Å kjøre det fordi eksporten inneholdt det, snur gjennomgangen du skulle ha gjort. Samme forsiktighet gjelder innebygde påloggingsdata: en pakke kan bære privat nøkkelmateriale, så en arbeidskopi hører hjemme på et beskyttet sted og ikke i en nedlastingsmappe.

Originalen forblir beskyttet til migreringen er godtatt.

Hva Linux-siden må avgjøre

Avgjør hvem som skal eie tilkoblingen: Community OpenVPN alene, NetworkManager-pluginen eller en annen støttet klient. Hver godtar et forskjellig sett med alternativer, og hver eier ruter, resolvere og hemmeligheter på sin måte. En fil som åpnes med hell i én importør, kan avvises av en annen, og suksess ved import beviser ikke kompatibilitet med den tiltenkte tilkoblingen. Spør operatøren om det allerede finnes en Linux-kompatibel profil, fordi det er kortere å starte fra den støttede artefakten enn å oversette en.

Hold servertillit, klientidentitet og beskyttelse av privat nøkkel som tre separate spørsmål.

Gjennomgangen før du kobler til

Kontroller endepunktet og transporten, autentiseringsmetoden, hver filreferanse og den tiltenkte rute- og DNS-policyen. Deretter verifiser tilkoblingen og applikasjonen som kreves, uavhengig av hverandre, fordi en tunnel som kommer opp ikke sier noe om hvorvidt applikasjonen når det den trenger.

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

Sammenlign det forhandlede resultatet med det operatøren sier at profilen skal gjøre, og noter ethvert alternativ Linux-klienten ignorerte.

Når migreringen er godtatt, utfase overføringskopiene gjennom den vanlige prosessen for håndtering av påloggingsdata. En pakke som blir liggende i en delt mappe, er påloggingsdata som blir liggende i en delt mappe.