Flytte OpenVPN fra TAP til TUN: en migreringsrekkefølge som fungerer

Å bytte dev tap mot dev tun endrer hva tunnelen bærer, ikke bare hva den heter. Et TAP-grensesnitt leverer Ethernet-rammer til en bro, så klientene oppfører seg som om de var koblet til kontorets svitsj. Et TUN-grensesnitt bærer IP-pakker, så klientene trenger ruter og den andre siden trenger en vei tilbake. Klientene, adresseplanen og LAN-ets returrute må alle flyttes med den endringen.

Migreringen er en redesign av nettverket med en tunnel påmontert, og rekkefølgen nedenfor holder den reversibel.

Kartlegg hva som faktisk er avhengig av Ethernet

List applikasjonene, ikke vertene. Avgjør om hver av dem bruker rutede TCP- eller UDP-tjenester, oppdagelse via kringkasting, DHCP fra kontor-LAN-et, en Ethernet-protokoll som ikke er IP, eller en antakelse om at begge ender ligger i samme subnett. Vanlig IP-tilgang overlever et rutet design. En protokoll som trenger rå Ethernet-rammer gjør det ikke, og ingen mengde ruting får den til å virke. Applikasjoner som er avhengige av oppdagelse trenger en erstatningsmekanisme som er bestemt før overgangen, ikke under den.

Den kartleggingen er også akseptlisten. Hver oppføring du ikke kan flytte, blir et dokumentert unntak eller en grunn til å holde et lite TAP-segment i live for nettopp den arbeidsmengden.

Lag planen for adresser og returruter

Velg et klientprefiks som ikke overlapper LAN-et, det gamle broområdet eller noe nettverk en klient allerede når. En server med subnett-topologi trenger et fragment som dev tun, topology subnet og server 10.78.0.0 255.255.255.0, men det er et fragment, ikke en fungerende profil. Behold den godkjente TLS-, identitets-, transport- og tilgangspolicyen rundt det, og bruk et prefiks du har verifisert som ledig.

Skriv deretter ned målene klientene må nå og hvem som sørger for returveien. Serveren trenger videresending aktivert og en tillatt vei videre. LAN-rutere trenger en rute tilbake til det nye prefikset, eller så trenger designet kildetranslasjon med den synlighetskostnaden det innebærer. En rute som pushes til klienten konfigurerer klienten, ikke LAN-ets svarvei.

Prøv på en egen lytter

Sett den nye tjenesten opp ved siden av den gamle på sin egen port og sitt eget adresseområde, i stedet for å erstatte det eneste inngangspunktet som virker. Utsted pilotprofiler gjennom den eksisterende registreringsprosessen så ingen bygger CA-en på nytt for en migrering. Koble til én representativ klient med bare pilotveien aktiv, og sammenlign deretter tildelte adresser, privat DNS, applikasjonene fra kartleggingen og veiene som skal forbli blokkert.

Ta med en test for gjenoppkobling og returtrafikk. Et håndtrykk som fullføres sier ingenting om hvorvidt den andre siden kan svare.

Flytt klienter i grupper med en tilbakerulling

Migrer i grupper som er små nok til at en feil blir en støtteoppgave i stedet for en driftsstans. Hold den gamle tjenesten i drift og dokumentert til hver gruppes reelle arbeidsflyter passerer, og skriv tilbakerullingen som en tilbakekobling til forrige profil, ikke en gjenoppbygging. Oppdater adressebaserte brannmurregler, overvåking og all serverinitiert tilgang for det nye prefikset etter hvert som hver gruppe flyttes.

Grupper gir deg også et sted å oppdage applikasjonen ingen nevnte, mens den gamle veien fortsatt finnes å sammenligne med.

Avvikle broen først etter aksept

Å fjerne TAP-enheten er det siste trinnet, ikke det første. Sjekk om broen fortsatt bærer serverens administrasjonsadresse, en overvåkingsvei eller en urelatert arbeidsmengde før du sletter noe. Avvikle oppstartsavhengigheter, bromedlemskap og DHCP-reservasjoner gjennom eierne deres, i den rekkefølgen, med et notat om hva som ble fjernet.

Migreringen er ferdig når den rutede tilgangsmodellen fungerer for kartleggingen, ikke når et TAP-grensesnitt forsvinner fra utdataene til ip link.