Wij gebruiken OpenVPN: protocol, engine of app? Wat je in plaats daarvan moet vragen

De zin «wij gebruiken OpenVPN» komt binnen in tickets, inkoopformulieren en onboardingdocumenten, en beantwoordt in elk daarvan een andere vraag. Soms noemt hij een transportprotocol, soms de software op een gateway en soms de app die een nieuwe medewerker moet installeren. Die drie feiten leiden tot verschillende vervolgstappen, en vragen welke bedoeld wordt kost minder tijd dan gokken. De rest van het onderzoek volgt uit dat antwoord.

Begin met de rol van het merk te scheiden, want het merk dekt alle drie.

De naam dekt drie rollen die op verschillende manieren falen

Als protocol beschrijft OpenVPN hoe compatibele peers een tunnel opzetten en beschermen wat erdoorheen gaat. Als software is het een implementatie die dat protocol spreekt in een client- of serverrol. Als client is het een applicatie die iemand installeert, met een eigen versie, eigen profielformaat en eigenaardigheden per platform. Een storing in de ene rol betekent niet een storing in de andere, en daarom heeft «OpenVPN ligt eruit» een onderwerp nodig.

Vraag wat de melder kan zien: een profielbestand, een geïnstalleerd programma of een gateway die hij beheert. Dat ene detail zegt je of de volgende stap een clientlog, een vraag over het pakket of een listenercontrole aan de serverkant is.

OpenVPN 2 en OpenVPN 3 zijn geen upgradepaar

OpenVPN 2.x draait zowel in de server- als in de clientrol, en dat is wat de meeste gateway-implementaties nog gebruiken. OpenVPN 3 is een aparte, op de client gerichte implementatie met een eigen configuratie en sessiemodel, niet de volgende release die je over een 2.x-server heen installeert. OpenVPN Connect is een clientapplicatie gebouwd op de OpenVPN 3-engine. Het installeren van een van deze maakt geen internetuitgangsdienst; de uitgang is wat de operator heeft geconfigureerd.

Compatibiliteit op protocolniveau strekt zich niet uit tot profieldirectieven, dus een profiel dat schoon importeert kan alsnog falen op een directief die de client niet implementeert.

Het transport is niet de applicatie erbinnen

De buitenste verbinding gebruikt een transport zoals UDP of TCP om een geconfigureerde listener te bereiken, en alles wat de tunnel draagt, rijdt daarbinnen. Een webverzoek via de VPN heeft geen eigen OpenVPN-listener nodig en wordt op de lijn geen OpenVPN-pakket. In TLS-modus onderhandelt het controlekanaal sleutelmateriaal terwijl het datakanaal de payload beschermt, en dat is een scheiding die je bij het lezen van logs goed wilt houden.

Het verwarren van de lagen levert verzoeken op zoals een poort openen voor een website die al via de tunnel werkt. De poort hoort bij de buitenste verbinding, niet bij de applicatie.

Wat een profiel wel en niet kan beloven

Een profiel vertelt één client hoe hij één dienst bereikt: eindpunt, transport, identiteitsmateriaal en vaak wat routing- en DNS-voorkeuren. Het zegt niets over wie die dienst beheert of of het account gemachtigd is. Routes, resolverinstellingen, doorstuurregels en toegangsbeleid bepalen wat de sessie werkelijk bereikt. Een profiel dat met succes importeert is het begin van een werkende verbinding, niet het bewijs ervan.

Als iemand vraagt of een resource via de VPN bereikbaar is, hangt het antwoord af van het beleid van de server en niet van het configuratiebestand van de client.

Vraag naar wat geleverd kan worden

Maak van de brede naam drie concrete dingen: de client en zijn versie, het gemachtigde profiel voor die client en de resource die de persoon moet bereiken. Daarmee is levering een concrete taak. Zonder die is elk antwoord een gok naar welke OpenVPN de vraag bedoelde.

Leg het antwoord vast in het verzoek zelf. Het volgende ticket stelt dezelfde vraag op dezelfde dubbelzinnige manier.