Vi bruger OpenVPN: protokol, motor eller app? Hvad man i stedet bør spørge om

Sætningen »vi bruger OpenVPN« dukker op i tickets, indkøbsformularer og onboardingdokumenter, og den besvarer et forskelligt spørgsmål i hver af dem. Nogle gange betegner den en trådprotokol, nogle gange softwaren på en gateway og nogle gange den app, en ny medarbejder skal installere. De tre fakta fører til forskellige næste skridt, og at spørge, hvilken der menes, tager kortere tid end at gætte. Resten af undersøgelsen følger af det svar.

Begynd med at skille rollen fra brandet, for brandet dækker alle tre.

Navnet dækker tre roller, som fejler forskelligt

Som protokol beskriver OpenVPN, hvordan kompatible parter etablerer en tunnel og beskytter det, der passerer den. Som software er det en implementering, der taler den protokol i en klient- eller serverrolle. Som klient er det et program, nogen installerer, med sin egen version, profilformat og platformsæregenheder. En fejl i én rolle betyder ikke en fejl i en anden, og derfor har »OpenVPN er nede« brug for et subjekt.

Spørg, hvad den, der melder det, kan se: en profilfil, et installeret program eller en gateway, som personen administrerer. Den ene detalje fortæller dig, om næste skridt er en klientlog, et spørgsmål om pakken eller et lyttertjek på serversiden.

OpenVPN 2 og OpenVPN 3 er ikke et opgraderingspar

OpenVPN 2.x kører i både server- og klientrollen, og det er den, de fleste gatewayudrulninger stadig bruger. OpenVPN 3 er en separat klientorienteret implementering med sin egen konfiguration og sessionsmodel, ikke den næste udgivelse, du installerer oven på en 2.x-server. OpenVPN Connect er et klientprogram bygget på OpenVPN 3-motoren. At installere en af dem opretter ikke en internetudgangstjeneste; udgangen er det, operatøren har konfigureret.

Kompatibilitet på protokolniveau strækker sig ikke til profildirektiver, så en profil, der importeres rent, kan stadig fejle på et direktiv, som klienten ikke implementerer.

Transporten er ikke applikationen indeni

Den ydre forbindelse bruger en transport som UDP eller TCP til at nå en konfigureret lytter, og alt, hvad tunnelen bærer, kører indeni den. En webforespørgsel gennem VPN’et har ikke brug for sin egen OpenVPN-lytter og bliver ikke til en OpenVPN-pakke på ledningen. I TLS-tilstand forhandler kontrolkanalen nøglemateriale, mens datakanalen beskytter nyttelasten, og det er en adskillelse, der er værd at holde styr på, når du læser logfiler.

At blande lagene giver anmodninger som at åbne en port for et website, der allerede virker gennem tunnelen. Porten tilhører den ydre forbindelse, ikke applikationen.

Hvad en profil kan love, og hvad den ikke kan

En profil fortæller én klient, hvordan den når én tjeneste: endpoint, transport, identitetsmateriale og ofte nogle routing- og DNS-præferencer. Den siger intet om, hvem der driver den tjeneste, eller om kontoen er autoriseret. Ruter, resolverindstillinger, videresendelsesregler og adgangspolitik afgør, hvad sessionen faktisk når. En profil, der importeres med succes, er begyndelsen på en fungerende forbindelse, ikke beviset for den.

Når nogen spørger, om en ressource kan nås over VPN’en, afhænger svaret af serverens politik og ikke af klientens konfigurationsfil.

Bed om det, der kan leveres

Omsæt det brede navn til tre konkrete ting: klienten og dens version, den autoriserede profil til den klient og den ressource, personen skal nå. Med dem er levering en konkret opgave. Uden dem er hvert svar et gæt på, hvilken OpenVPN spørgsmålet mente.

Skriv svaret ned i selve anmodningen. Den næste ticket vil stille det samme spørgsmål på den samme tvetydige måde.