Přesun OpenVPN z TAP na TUN: pořadí migrace, které funguje

Nahrazení dev tap za dev tun mění, co tunel nese, ne jen jak se jmenuje. Rozhraní TAP předává Ethernetové rámce mostu, takže klienti se chovají, jako by byli zapojeni do kancelářského switche. Rozhraní TUN nese IP pakety, takže klienti potřebují trasy a protistrana potřebuje cestu zpět. Klienti, adresní plán i zpětná trasa lokální sítě se musí přesunout spolu s touto změnou.

Migrace je redesign sítě s připojeným tunelem a pořadí níže ho udržuje vratné.

Zmapujte, co skutečně závisí na Ethernetu

Vypisujte aplikace, ne hostitele. Určete, zda každá používá směrované služby TCP nebo UDP, broadcastové objevování, DHCP z kancelářské lokální sítě, ne-IP Ethernetový protokol nebo předpoklad, že oba konce jsou ve stejné podsíti. Běžný IP přístup směrovaný design přežije. Protokol, který potřebuje surové Ethernetové rámce, ne, a žádné množství směrování ho nerozjede. Aplikace závislé na objevování potřebují náhradní mechanismus rozhodnutý před přechodem, ne během něj.

Tento soupis je také seznam přijetí. Každá položka, kterou nedokážete migrovat, se stane zdokumentovanou výjimkou nebo důvodem ponechat malý segment TAP živý jen pro tuto zátěž.

Sestavte plán adres a zpětných tras

Vyberte klientský prefix, který se nepřekrývá s lokální sítí, starým rozsahem mostu ani sítí, kam se klient už dostane.dev tun, topology subnet a server 10.78.0.0 255.255.255.0, ale to je fragment, ne funkční profil. Zachovejte kolem něj schválenou politiku TLS, identity, transportu a přístupu a použijte prefix, který jste ověřili jako volný.

Potom zapište cíle, kam se klienti musí dostat, a kdo poskytuje zpětnou cestu. Server potřebuje zapnuté předávání a povolenou cestu dál. Routery lokální sítě potřebují trasu zpět k novému prefixu, nebo design potřebuje překlad zdroje s cenou viditelnosti, kterou to přináší. Trasa vložená do konfigurace klienta konfiguruje klienta, ne odpovědní cestu lokální sítě.

Otestujte na samostatném posluchači

Postavte novou službu vedle staré na jejím vlastním portu a vlastním rozsahu adres, místo abyste nahradili jediný funkční vstupní bod. Vydávejte zkušební profily stávajícím procesem zápisu, aby kvůli migraci nikdo nepřestavoval CA. Připojte jednoho reprezentativního klienta s aktivní jen zkušební cestou a potom porovnejte přidělené adresy, soukromé DNS, aplikace ze soupisu a cesty, které mají zůstat blokované.

Zahrňte test opětovného připojení a zpětného provozu. Dokončený handshake nic neříká o tom, zda protistrana umí odpovědět.

Přesouvejte klienty ve skupinách s návratem

Migrujte ve skupinách dost malých na to, aby selhání bylo podpůrným úkolem, ne výpadkem. Držte starou službu běžící a zdokumentovanou, dokud neprojdou skutečné pracovní postupy každé skupiny, a návrat popište jako přepnutí zpět na předchozí profil, ne jako přestavbu. Aktualizujte pravidla firewallu založená na adresách, monitoring a jakýkoli serverem iniciovaný přístup pro nový prefix, jak se skupiny přesouvají.

Skupiny vám také dají místo, kde objevit aplikaci, kterou nikdo nezmínil, zatímco stará cesta ještě existuje pro srovnání.

Vyřaďte most až po přijetí

Odstranění zařízení TAP je poslední krok, ne první. Před smazáním čehokoli zkontrolujte, zda most ještě nenese adresu správy serveru, monitorovací cestu nebo nesouvisející zátěž. Vyřaďte závislosti při startu, členství v mostu a rezervace DHCP prostřednictvím jejich vlastníků, v tomto pořadí, s poznámkou, co bylo odstraněno.

Migrace je hotová, když směrovaný model přístupu funguje pro soupis, ne když rozhraní TAP zmizí z výstupu ip link.