Presun OpenVPN z TAP na TUN: poradie migrácie, ktoré funguje

Výmena dev tap za dev tun mení to, čo tunel prenáša, nielen jeho názov. Rozhranie TAP odovzdáva Ethernetové rámce mostu, takže klienti sa správajú, akoby boli pripojení kancelárskeho prepínača. Rozhranie TUN prenáša IP pakety, takže klienti potrebujú trasy a druhá strana potrebuje cestu späť. Klienti, plán adries aj spätná trasa LAN sa musia presunúť spolu s touto zmenou.

Migrácia je prepracovanie siete s pripojeným tunelom a poradie nižšie ju udržiava vratnou.

Zinventarizujte, čo skutočne závisí od Ethernetu

Vypíšte aplikácie, nie hosty. Určte, či každá používa smerované služby TCP alebo UDP, objavovanie vysielaním, DHCP z kancelárskej LAN, Ethernetový protokol, ktorý nie je IP, alebo predpoklad, že oba konce sú v tej istej podsieti. Bežný prístup cez IP prežije smerovaný návrh. Protokol, ktorý potrebuje surové Ethernetové rámce, neprežije a žiadne množstvo smerovania to nespraví. Aplikácie závislé od objavovania potrebujú náhradný mechanizmus rozhodnutý pred prechodom, nie počas neho.

Tá inventarizácia je zároveň akceptačný zoznam. Každá položka, ktorú nedokážete presunúť, sa stane zdokumentovanou výnimkou alebo dôvodom ponechať malý segment TAP nažive len pre toto pracovné zaťaženie.

Zostavte plán adries a spätných trás

Vyberte klientsky prefix, ktorý sa neprekrýva s LAN, starým rozsahom mosta ani so sieťou, do ktorej sa klient už dostane. Server s topológiou podsiete potrebuje fragment ako dev tun, topology subnet a server 10.78.0.0 255.255.255.0, ale to je fragment, nie fungujúci profil. Zachovajte okolo neho schválenú politiku TLS, identity, transportu a prístupu a použite prefix, ktorý ste overili ako voľný.

Potom zapíšte destinácie, ku ktorým sa klienti musia dostať, a kto zabezpečuje spätnú cestu. Server potrebuje zapnuté preposielanie a povolenú cestu ďalej. Routery LAN potrebujú trasu späť k novému prefixu, alebo návrh potrebuje preklad zdroja s nákladmi na viditeľnosť, ktoré to prináša. Trasa tlačená klientovi konfiguruje klienta, nie spätnú cestu LAN.

Otestujte na samostatnom poslucháči

Postavte novú službu vedľa starej na jej vlastnom porte a vo vlastnom rozsahu adries, namiesto nahradenia jediného funkčného vstupného bodu. Vydávajte pilotné profily cez existujúci proces registrácie, aby nikto neprestavoval CA pre migráciu. Pripojte jedného reprezentatívneho klienta s aktívnou iba pilotnou cestou, potom porovnajte pridelené adresy, súkromné DNS, aplikácie z inventarizácie a cesty, ktoré majú zostať zablokované.

Zahrňte test opätovného pripojenia a spätnej prevádzky. Dokončený handshake nič nehovorí o tom, či druhá strana dokáže odpovedať.

Presúvajte klientov v skupinách s návratom

Migrujte v skupinách, ktoré sú dosť malé na to, aby zlyhanie bolo úlohou podpory a nie výpadkom. Nechajte starú službu bežať a zdokumentovanú, kým neprejdú skutočné pracovné postupy každej skupiny, a návrat napíšte ako prepnutie späť na predchádzajúci profil, nie ako prestavbu. Ako sa jednotlivé skupiny presúvajú, aktualizujte pravidlá firewallu založené na adresách, monitorovanie a akýkoľvek prístup iniciovaný serverom pre nový prefix.

Skupiny vám tiež dajú miesto, kde objaviť aplikáciu, o ktorej nikto nehovoril, kým stará cesta ešte existuje na porovnanie.

Most vyraďte až po akceptácii

Odstránenie zariadenia TAP je posledný krok, nie prvý. Skôr než čokoľvek zmažete, skontrolujte, či most ešte prenáša adresu správy servera, monitorovaciu cestu alebo nesúvisiacu záťaž. Vyraďte závislosti pri štarte, členstvo v moste a rezervácie DHCP cez ich vlastníkov, v tomto poradí, s poznámkou o tom, čo bolo odstránené.

Migrácia je hotová, keď smerovaný model prístupu funguje pre inventarizáciu, nie keď rozhranie TAP zmizne z výstupu ip link.