Flytta OpenVPN från TAP till TUN: en migreringsordning som fungerar

Att byta dev tap mot dev tun ändrar vad tunneln bär, inte bara vad den heter. Ett TAP-gränssnitt lämnar Ethernet-ramar till en brygga, så klienterna beter sig som om de var inkopplade i kontorets switch. Ett TUN-gränssnitt bär IP-paket, så klienterna behöver rutter och andra sidan behöver en väg tillbaka. Klienterna, adressplanen och LAN:ets returväg måste alla flyttas med den ändringen.

Migreringen är en omdesign av nätet med en tunnel påkopplad, och ordningen nedan håller den reversibel.

Kartlägg vad som faktiskt är beroende av Ethernet

Lista applikationerna, inte värdarna. Avgör om var och en använder routade TCP- eller UDP-tjänster, upptäckt via broadcast, DHCP från kontors-LAN:et, ett Ethernet-protokoll som inte är IP, eller ett antagande att båda ändar ligger i samma subnät. Vanlig IP-åtkomst överlever en routad design. Ett protokoll som behöver råa Ethernet-ramar gör det inte, och ingen mängd routning får det att fungera. Applikationer som är beroende av upptäckt behöver en ersättningsmekanism som bestämts före övergången, inte under den.

Den kartläggningen är också acceptanslistan. Varje post du inte kan flytta blir ett dokumenterat undantag eller en anledning att hålla ett litet TAP-segment vid liv enbart för den arbetsbelastningen.

Bygg planen för adresser och returvägar

Välj ett klientprefix som inte överlappar LAN:et, det gamla bryggområdet eller något nät som en klient redan når. En server med subnätstopologi behöver ett fragment som dev tun, topology subnet och server 10.78.0.0 255.255.255.0, men det är ett fragment och inte en fungerande profil. Behåll den godkända policyn för TLS, identitet, transport och åtkomst runt det, och använd ett prefix som du har verifierat är ledigt.

Skriv sedan ned målen som klienterna måste nå och vem som tillhandahåller returvägen. Servern behöver vidarebefordran aktiverad och en tillåten väg vidare. LAN-routrar behöver en rutt tillbaka till det nya prefixet, eller så behöver designen källöversättning med den synlighetskostnad det innebär. En rutt som skjuts till klienten konfigurerar klienten, inte LAN:ets svarsväg.

Testa på en egen lyssnare

Sätt upp den nya tjänsten bredvid den gamla på sin egen port och sitt eget adressområde, i stället för att ersätta den enda ingångspunkt som fungerar. Utfärda pilotprofiler genom den befintliga registreringsprocessen så att ingen bygger om CA:n för en migrering. Anslut en representativ klient med bara pilotvägen aktiv och jämför sedan tilldelade adresser, privat DNS, applikationerna från kartläggningen och de vägar som ska förbli blockerade.

Ta med ett test för återanslutning och returtrafik. En handskakning som slutförs säger ingenting om huruvida andra sidan kan svara.

Flytta klienter i grupper med en återrullning

Migrera i grupper som är små nog att ett fel blir en supportuppgift i stället för ett avbrott. Håll den gamla tjänsten igång och dokumenterad tills varje grupps verkliga arbetsflöden passerar, och skriv återrullningen som en återkoppling till föregående profil, inte en ombyggnad. Uppdatera adressbaserade brandväggsregler, övervakning och all serverinitierad åtkomst för det nya prefixet i takt med att varje grupp flyttas.

Grupper ger dig också en plats att upptäcka applikationen som ingen nämnde, medan den gamla vägen fortfarande finns att jämföra med.

Avveckla bryggan först efter acceptans

Att ta bort TAP-enheten är det sista steget, inte det första. Kontrollera om bryggan fortfarande bär serverns administrationsadress, en övervakningsväg eller en orelaterad arbetsbelastning innan du raderar något. Avveckla startberoenden, bryggmedlemskap och DHCP-reservationer via deras ägare, i den ordningen, med en anteckning om vad som togs bort.

Migreringen är klar när den routade åtkomstmodellen fungerar för kartläggningen, inte när ett TAP-gränssnitt försvinner från utdata från ip link.