Van Access Server naar Community OpenVPN: wat opnieuw gebouwd moet worden

Access Server en Community OpenVPN spreken hetzelfde protocol en vrijwel niets anders op dezelfde manier. De handshake, de onderhandeling over cijfers en het datavlak van de tunnel zijn compatibel, waardoor een client vaak op beide kan inloggen zonder zijn profiel te wijzigen. Het verschil is wie de configuratie bezit: het ene product levert een beheerslaag die beleid schrijft en afdwingt, het andere geeft je een configuratiebestand en een set hooks en verwacht dat jij beslist.

Dat verschil is het migratieplan. Alles wat het oude product namens jou besliste, moet ergens in de nieuwe uitrol een expliciete beslissing worden.

Waar de twee uitrollen ophouden uitwisselbaar te zijn

In Access Server bezit de webbeheerinterface gebruikers, groepen, rechten per gebruiker, certificaatuitgifte en het profielpakket dat iemand downloadt. De daemon eronder wordt door die laag geconfigureerd, dus de draaiende dienst is het product van opgeslagen toestand die je zelden met de hand bewerkt. In Community OpenVPN is het configuratiebestand de toestand: het benoemt de listener, de certificaatautoriteit, de authenticatiehook en elke gepushte optie, en niets herschrijft het voor je. Dezelfde TLS-machinerie staat dus onder twee heel verschillende eigendomsmodellen.

Een korte mapping maakt de kloof concreet. Gebruikers en groepen bestaan alleen in de oude database tot je ze opnieuw aanmaakt. Profielpakketten worden een configuratiebestand plus certificaten die je zelf verspreidt. Rechten per gebruiker worden richtlijnen in client-config-dir. De beheerinterface wordt het proces dat je kiest voor het uitgeven van certificaten en het bewerken van bestanden.

Schrijf die mapping op voordat je een server aanraakt. Elke rij die je niet kunt invullen is een functie die je op het punt staat te verliezen, en stil verliezen is hoe een migratie twee weken later een storing wordt.

Identiteit gaat niet mee met de certificaatbestanden

Certificaten van de oude autoriteit kunnen in de nieuwe dienst correct worden geparseerd en toch de verkeerde identiteit zijn, omdat het oude product ze koppelde aan accountstatus die het nieuwe niet ziet. Bepaal eerst of de nieuwe uitrol authenticeert met alleen een certificaat, met een plugin die PAM of RADIUS bereikt, of met een combinatie, en controleer daarna of elke optie de eigenschappen behoudt die je nodig hebt. Een gedeeld certificaat zonder identiteit per gebruiker is één credential voor iedereen die het heeft. Intrekking moet ook vanaf de eerste dag werken, wat in Community OpenVPN een CRL-bestand betekent waarnaar crl-verify verwijst plus een proces dat het opnieuw genereert.

Plan de inschrijving vóór de overgang, niet erna. Nieuwe certificaten, een getest intrekkingspad en een gedocumenteerde manier om één persoon uit te schakelen zijn voorwaarden, geen nawerk. Als multifactorauthenticatie uit de integratie van het oude product kwam, benoem de vervanging dan expliciet, want een plugin die niet is geïnstalleerd faalt gesloten op het slechtste moment.

Routering en naamresolutie volgen de schrijver van de configuratie

Routes, DNS-instellingen en het gedrag van een volledige tunnel zijn gepushte opties in beide producten, maar slechts één berekent ze voor je. In Community OpenVPN schrijf je de push-richtlijnen zelf, bepaal je of redirect-gateway bij de server of de client hoort, en bevestig je dat doorsturen en NAT op de host bestaan. Een voltooide handshake zegt niets over doorsturen, adresvertaling of de routes die de client werkelijk ontving.

Gedrag per client vereist client-config-dir plus een bestand genoemd naar de common name van het clientcertificaat, en een site-naar-site-peer vereist iroute-vermeldingen voor de prefixen erachter. Is de naam verkeerd, dan worden de opties genegeerd zonder fout. Test met één niet-productieclient in zijn eigen adrespool en lees daarna het toegewezen adres, de ontvangen routes en de resolverinstellingen waarmee hij eindigde.

Orden de overgang zodat de oude dienst kan terugkeren

Draai de nieuwe listener op een andere poort of een ander adres, en laat de oude verkeer bedienen terwijl je de vervanging bewijst. Twee daemons op één socket is geen terugdraaiplan.

Verplaats één groep tegelijk, met eigen certificaten, eigen pool en eigen routes, en oefen de terugweg in plaats van die tijdens een incident te ontdekken. Een terugdraai die alleen werkt als eerst de nieuwe dienst stopt, blijft een terugdraai, maar moet worden getest terwijl er niets in brand staat.

Ten slotte: lijst de functies zonder direct equivalent op en beslis het lot van elk schriftelijk: zelfbediening van profieldownloads,rechtengrendels per gebruiker, de beheerinterface zelf, live rapportage van verbindingen. Ze vervangen door een gedocumenteerd handmatig proces is een legitiem antwoord. De rij leeg laten is dat niet.

Het werk is klaar wanneer iemand die het oude portaal nooit zag zich kan inschrijven, verbinden, het bedoelde interne adres kan bereiken en netjes kan worden ingetrokken. Alles daarvoor is voorbereiding.