Fra Access Server til Community OpenVPN: hva som må bygges opp igjen

Access Server og Community OpenVPN snakker samme protokoll og nesten ingenting annet på samme måte. Håndtrykket, forhandlingen av chiffere og tunnelens dataplan er kompatible, så en klient kan ofte koble seg til begge uten å endre profilen. Forskjellen er hvem som eier konfigurasjonen: det ene produktet leverer et styringslag som skriver og håndhever policy, det andre gir deg en konfigurasjonsfil og noen kroker og forventer at du bestemmer selv.

Den forskjellen er migreringsplanen. Alt det gamle produktet avgjorde på dine vegne, må bli et tydelig valg et sted i den nye utrullingen.

Der de to utrullingene slutter å være utskiftbare

I Access Server eier nettadministrasjonsgrensesnittet brukere, grupper, rettigheter per bruker, sertifikatutstedelse og profilpakken noen laster ned. Tjeneren under styres av det laget, så tjenesten som kjører er resultatet av lagret tilstand du sjelden redigerer for hånd. I Community OpenVPN er konfigurasjonsfilen tilstanden: den navngir lytteren, sertifikatmyndigheten, autentiseringskroken og hvert eneste dyttede alternativ, og ingenting skriver den om for deg. Den samme TLS-maskinen står dermed under to svært forskjellige eierskapsmodeller.

En kort kartlegging gjør gapet konkret. Brukere og grupper finnes bare i den gamle databasen til du lager dem på nytt. Profilpakker blir en konfigurasjonsfil pluss sertifikater du deler ut selv. Rettigheter per bruker blir direktiver i client-config-dir. Administrasjonsgrensesnittet blir den prosessen du velger for å utstede sertifikater og redigere filer.

Skriv kartleggingen ned før du tar på en server. Hver rad du ikke kan fylle ut er en funksjon du er i ferd med å miste, og å miste den i stillhet er måten en migrering blir et avbrudd to uker senere.

Identitet følger ikke med sertifikatfilene

Sertifikater fra den gamle myndigheten kan tolkes riktig i den nye tjenesten og likevel være feil identitet, fordi det gamle produktet koblet dem til kontotilstand den nye ikke ser. Avgjør først om den nye utrullingen autentiserer med sertifikat alene, med en plugin som når PAM eller RADIUS, eller med en kombinasjon, og sjekk deretter at hvert alternativ beholder egenskapene du trenger. Et delt sertifikat uten identitet per bruker er én innlogging for alle som har det. Tilbakekalling må også virke fra første dag, som i Community OpenVPN betyr en CRL-fil som crl-verify peker på, pluss en prosess som lager den på nytt.

Planlegg registreringen før overgangen, ikke etterpå. Nye sertifikater, en testet tilbakekallingsvei og en dokumentert måte å slå av én person er forutsetninger, ikke oppfølging. Hvis flerfaktorautentisering kom fra integrasjonen i det gamle produktet, navngi erstatningen tydelig, fordi en plugin som ikke er installert feiler lukket på det verste tidspunktet.

Ruting og navneoppslag følger den som skriver konfigurasjonen

Ruter, DNS-innstillinger og oppførselen til full tunnel er dyttede alternativer i begge produktene, men bare én regner dem ut for deg. I Community OpenVPN skriver du push-direktivene selv, bestemmer om redirect-gateway hører til tjeneren eller klienten, og bekrefter at videresending og NAT finnes på verten. Et fullført håndtrykk sier ingenting om videresending, adresseoversettelse eller rutene klienten faktisk fikk.

Oppførsel per klient krever client-config-dir pluss en fil som er oppkalt etter klientens sertifikat-common-name, og et site-til-site-par krever iroute-oppføringer for prefiksene bak. Er navnet feil, ignoreres alternativene uten feilmelding. Test med én klient utenfor produksjon i sitt eget adressebasseng, og les deretter adressen den fikk, rutene den fikk og resolverinnstillingene den endte med.

Rekkefølgen på overgangen må la den gamle tjenesten komme tilbake

Kjør den nye lytteren på en annen port eller adresse, og la den gamle betjene trafikk mens du beviser erstatningen. To tjenere på én socket er ikke en tilbakerullingsplan.

Flytt én gruppe om gangen, med egne sertifikater, eget basseng og egne ruter, og øv på returveien i stedet for å oppdage den midt i en hendelse. En tilbakerulling som bare virker hvis den nye tjenesten stoppes først, er fortsatt en tilbakerulling, men den må testes når ingenting brenner.

Til slutt: list opp funksjonene uten direkte motstykke og avgjør skjebnen til hver av dem skriftlig: selvbetjent profilnedlasting, rettighetsflagg per bruker, selve administrasjonsgrensesnittet, sanntidsrapportering av tilkoblinger. Å erstatte dem med en dokumentert manuell prosess er et gyldig svar. Å la raden stå tom er det ikke.

Arbeidet er ferdig når en bruker som aldri har sett den gamle portalen kan registrere seg, koble til, nå den tiltenkte interne adressen og bli ryddig tilbakekalt. Alt før det er forberedelse.