Från Access Server till Community OpenVPN: vad som måste byggas om

Access Server och Community OpenVPN talar samma protokoll och nästan ingenting annat på samma sätt. Handskakningen, förhandlingen om chiffer och tunnelns dataplan är kompatibla, så en klient kan ofta ansluta till båda utan att ändra sin profil. Skillnaden är vem som äger konfigurationen: den ena produkten levererar ett hanteringslager som skriver och upprätthåller policy, den andra ger dig en konfigurationsfil och en uppsättning krokar och förväntar sig att du bestämmer.

Den skillnaden är migreringsplanen. Allt det gamla produkten beslutade åt dig måste bli ett uttalat beslut någonstans i den nya driftsättningen.

Där de två driftsättningarna slutar vara utbytbara

I Access Server äger webbadministrationsgränssnittet användare, grupper, behörigheter per användare, certifikatutfärdande och det profilpaket en person laddar ner. Daemonen under styrs av det lagret, så tjänsten som kör är resultatet av sparat tillstånd som du sällan redigerar för hand. I Community OpenVPN är konfigurationsfilen tillståndet: den namnger lyssnaren, certifikatmyndigheten, autentiseringskroken och varje pushad option, och ingenting skriver om den åt dig. Samma TLS-maskin står alltså under två mycket olika ägarmodeller.

En kort kartläggning gör gapet konkret. Användare och grupper finns bara i den gamla databasen tills du återskapar dem. Profilpaket blir en konfigurationsfil plus certifikat som du distribuerar själv. Behörigheter per användare blir direktiv i client-config-dir. Administrationsgränssnittet blir den process du väljer för att utfärda certifikat och redigera filer.

Skriv ner kartläggningen innan du rör en server. Varje rad du inte kan fylla i är en funktion du är på väg att tappa, och att tappa den i tysthet är hur en migrering blir ett avbrott två veckor senare.

Identitet följer inte med certifikatfilerna

Certifikat från den gamla myndigheten kan tolkas korrekt i den nya tjänsten och ändå vara fel identitet, eftersom den gamla produkten parade dem med kontotillstånd som den nya inte ser. Avgör först om den nya driftsättningen autentiserar med certifikat enbart, med ett plugin som når PAM eller RADIUS, eller med en kombination, och kontrollera sedan att varje alternativ bevarar de egenskaper du behöver. Ett delat certifikat utan identitet per användare är en enda inloggning för alla som har det. Återkallning måste också fungera från dag ett, vilket i Community OpenVPN betyder en CRL-fil som crl-verify pekar på plus en process som återskapar den.

Planera registreringen före övergången, inte efter. Nya certifikat, en testad återkallningsväg och ett dokumenterat sätt att stänga av en person är förutsättningar, inte efterarbete. Om flerfaktorautentisering kom från den gamla produktens integration, namnge ersättningen uttryckligen, för ett plugin som inte är installerat faller stängt i värsta möjliga ögonblick.

Routning och namnmatchning följer den som skriver konfigurationen

Rutter, DNS-inställningar och beteendet för full tunnel är pushade alternativ i båda produkterna, men bara en räknar ut dem åt dig. I Community OpenVPN skriver du push-direktiven själv, avgör om redirect-gateway hör till servern eller klienten och bekräftar att vidarebefordran och NAT finns på värden. En avslutad handskakning säger ingenting om vidarebefordran, adressöversättning eller de rutter klienten faktiskt fick.

Beteende per klient kräver client-config-dir plus en fil som är namngiven efter klientcertifikatets common name, och ett site-till-site-par kräver iroute-poster för prefixen bakom. Är namnet fel ignoreras alternativen utan fel. Testa med en klient utanför produktion i dess egen adresspool och läs sedan den tilldelade adressen, rutterna den fick och de resolverinställningar den slutade med.

Sekvensera övergången så att den gamla tjänsten kan komma tillbaka

Kör den nya lyssnaren på en annan port eller adress och låt den gamla betjäna trafik medan du bevisar ersättaren. Två daemoner på en socket är ingen återrullningsplan.

Flytta en grupp i taget, med egna certifikat, egen pool och egna rutter, och öva returvägen i stället för att upptäcka den mitt i en incident. En återrullning som bara fungerar om den nya tjänsten stoppas först är fortfarande en återrullning, men den måste testas när ingenting brinner.

Slutligen, lista funktionerna utan direkt motsvarighet och avgör var och ens öde skriftligt: självbetjänad profilnedladdning, behörighetsflaggor per användare, själva administrationsgränssnittet, rapportering av anslutningar i realtid. Att ersätta dem med en dokumenterad manuell process är ett legitimt svar. Att lämna raden tom är det inte.

Arbetet är klart när en användare som aldrig sett den gamla portalen kan registrera sig, ansluta, nå den avsedda interna adressen och bli återkallad rent. Allt före det är förberedelse.