Flyt OpenVPN fra TAP til TUN: en migreringsrækkefølge, der virker

At erstatte dev tap med dev tun ændrer, hvad tunnelen bærer, ikke blot hvad den hedder. En TAP-grænseflade giver Ethernet-rammer til en bro, så klienter opfører sig, som om de var sat i kontorets switch. En TUN-grænseflade bærer IP-pakker, så klienter har brug for ruter, og den anden side har brug for en vej tilbage. Klienterne, adresseplanen og LAN'ets returrute skal alle flytte med den ændring.

Migreringen er et redesign af netværket med en tunnel på, og rækkefølgen nedenfor holder den reversibel.

Kortlæg, hvad der faktisk afhænger af Ethernet

List applikationerne, ikke værtørne. Afgør, om hver enkelt bruger rutede TCP- eller UDP-tjenester, broadcast-baseret opdagelse, DHCP fra kontorets LAN, en Ethernet-protokol, der ikke er IP, eller en antagelse om, at begge ender er i samme subnet. Almindelig IP-adgang overlever et rutet design. En protokol, der kræver rå Ethernet-rammer, gør ikke, og ingen mængde routing får den til at virke. Applikationer, der afhænger af opdagelse, har brug for en erstatningsmekanisme, der besluttes før overgangen, ikke under den.

Den kortlægning er også acceptlisten. Hver post, du ikke kan migrere, bliver en dokumenteret undtagelse eller en grund til at holde et lille TAP-segment i live alene for den belastning.

Byg adresse- og returruteplanen

Vælg et klientpræfiks, der ikke overlapper LAN'et, det gamle brointerval eller et netværk, som en klient allerede når.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 godkendte TLS-, identitets-, transport- og adgangspolitik omkring det, og brug et præfiks, du har verificeret som frit.

Skriv derefter de destinationer ned, som klienterne skal nå, og hvem der leverer returvejen. Serveren har brug for videresendelse aktiveret og en tilladt vej videre. LAN-ruterne har brug for en rute tilbage til det nye præfiks, eller designet kræver kildetranslation med den synlighedspris, det indebærer. En rute, der skubbes til klientkonfigurationen, konfigurerer klienten, ikke LAN'ets svarvej.

Pilot på en separat lytter

Rejs den nye tjeneste ved siden af den gamle på sin egen port og sit eget adresseområde i stedet for at erstatte det eneste indgangspunkt, der virker. Udsted pilotprofiler gennem den eksisterende tilmeldingsproces, så ingen genopbygger CA'en for en migrering. Forbind én repræsentativ klient med kun pilotvejen aktiv, og sammenlign derefter tildelte adresser, privat DNS, applikationerne fra kortlægningen og de veje, der skal forblive blokerede.

Medtag en genopkoblings- og en returtrafiktest. Et håndtryk, der gennemføres, siger intet om, hvorvidt den anden side kan svare.

Flyt klienter i grupper med en tilbagerulning

Migrer i grupper, der er små nok til, at en fejl er en supportopgave og ikke et nedbrud. Hold den gamle tjeneste kørende og dokumenteret, indtil hver gruppes reelle arbejdsgange består, og skriv tilbagerulningen som et skift tilbage til den forrige profil og ikke en genopbygning. Opdater adressebaserede firewallregler, overvågning og enhver serverinitieret adgang til det nye præfiks, efterhånden som hver gruppe flytter.

Grupper giver dig også et sted at opdage den applikation, som ingen nævnte, mens den gamle vej stadig findes at sammenligne med.

Nedlæg først broen efter accept

Fjernelse af TAP-enheden er det sidste skridt, ikke det første. Kontrollér, om broen stadig bærer serverens administrationsadresse, en overvågningsvej eller en urelateret belastning, før du sletter noget. Nedlæg opstartsafhængigheder, bromedlemskab og DHCP-reservationer gennem deres ejere, i den rækkefølge, med en note om, hvad der blev fjernet.

Migreringen er færdig, når den rutede adgangsmodel virker for kortlægningen, ikke når en TAP-grænseflade forsvinder fra outputtet af ip link.