Draagbaarheid van OpenVPN-profielen: draagbare sleutels versus platformopties

Hetzelfde .ovpn-bestand opent een tunnel in de ene client en start niet in de andere, en het certificaat is meestal de eerste verdachte. Vaker bevat het bestand een richtlijn die slechts één engine implementeert. Een profiel is een contract met een specifieke client, geen draagbaar script.

Scheid wat met de identiteit meereist van wat bij een platform hoort. Dan noemt de storing zich meestal zelf.

Eén bestand, twee contracten

Een profiel bundelt drie soorten inhoud: identiteitsmateriaal zoals CA- en clientcertificaten en de privésleutel, transportgegevens zoals het externe eindpunt en het protocol, en gedragsrichtlijnen zoals DNS-afhandeling of apparaatopties. De eerste twee zijn breed draagbaar tussen engines die hetzelfde protocol ondersteunen. De derde is waar de implementaties uiteenlopen. Het hele bestand als één draagbare eenheid behandelen is wat de verwarrende storingen veroorzaakt.

Een bestand dat in een GUI op het ene platform werkt, is niet automatisch geldig voor de commandoregelclient op een ander. Zelfs wanneer beide OpenVPN zijn, verschillen de parsers en de optiesets. Daarom is een geslaagde import geen bewijs van een draagbaar profiel.

Draagbaar materiaal versus platformrichtlijnen

De identiteits- en transportsecties zijn het deel dat bewaard moet blijven. ca, cert, key en remote beschrijven wie verbindt en waarheen, en ze betekenen hetzelfde voor elke conforme client.

Gedragsrichtlijnen zijn het deel dat vergeleken moet worden. block-outside-dns bestaat bijvoorbeeld om het DNS-gedrag onder Windows te wijzigen. Een Unix-client herkent die misschien helemaal niet.

Lees de optielijst van de ontvangende client in plaats van die van de verzendende. De OpenVPN 2.6-referentiehandleiding documenteert de opties van de engine, en de importdialoog van een GUI is die lijst niet.

Lees de parserfout vóór het certificaat

Een fout die een onbekende optie noemt, is een parserfout, geen authenticatiefout. De verbinding bereikte nooit TLS, dus certificaten vervangen kan niet helpen. Lees de eerste fout van de werkelijke client en versie en verwijder of vervang daarna alleen de richtlijn die die client niet kan implementeren. Certificaat- of routesecties wissen om het bestand te laten laden is de manier waarop een werkend profiel onveilig wordt.

Als de fout de handshake, een certificaat of een cijfer noemt, is het profiel geparsed en zit het probleem elders.

Bewaar het originele bestand naast het aangepaste. Wanneer het aangepaste bestand later faalt, is het origineel de controle die zegt of de wijziging of de omgeving bewoog.

Rechten zijn een tweede grens

Rechten zijn de andere grens: een tunnelapparaat aanmaken, routes installeren en een privésleutel lezen hangen allemaal af van lokale machtigingen. Een sleutelbestand dat alleen root kan lezen is een normale uitrol, geen profielgebrek. De oplossing hoort bij eigendom of capabilities, niet in het bestand.

De client met sudo draaien kan een lokale machtigingsweigering oplossen, en het kan geen richtlijn toevoegen die het binaire bestand niet implementeert. Het verandert ook welke sleutelhanger, configuratiepaden en netwerkbeheerdercontext gelden, dus het resultaat is niet dezelfde test.

Pas bewust aan

Wanneer een provider aparte profielen publiceert, neem het profiel dat voor de ontvangende client bedoeld is. Het bestand van een ander platform aanpassen is een laatste redmiddel. Dat vereist een vastlegging van elke gewijzigde optie en een kopie van het origineel.

Test identiteit, routering en DNS als drie afzonderlijke uitkomsten. Een profiel dat authenticeert en routeert maar de naamresolutie breekt, is een gedeeltelijk aangepast profiel, geen werkend profiel.