OpenVPN perkėlimas iš TAP į TUN: veikianti migracijos tvarka

Jei dev tap pakeičiamas į dev tun, keičiasi tai, ką tunelis perduoda, o ne vien jo pavadinimas. TAP sąsaja perduoda Ethernet kadrus tiltui, todėl klientai elgiasi taip, tarsi būtų prijungti prie biuro komutatoriaus. TUN sąsaja perduoda IP paketus, todėl klientams reikia maršrutų, o kita pusė turi turėti kelią atgal. Klientai, adresų planas ir LAN grįžimo maršrutas turi keistis kartu su šiuo pakeitimu.

Migracija yra tinklo pertvarka su prijungtu tuneliu, o toliau pateikta tvarka leidžia ją vykdyti grįžtamai.

Inventorizuokite, kas iš tikrųjų priklauso nuo Ethernet

Sudarykite programų, o ne serverių sąrašą. Nustatykite, ar kiekviena jų naudoja maršrutizuotas TCP ar UDP paslaugas, transliavimo aptikimą, DHCP iš biuro LAN, ne IP Ethernet protokolą arba prielaidą, kad abu galai yra tame pačiame potinklyje. Įprasta IP prieiga maršrutizuotoje schemoje išlieka. Protokolas, kuriam reikia neapdorotų Ethernet kadrų, neišlieka, ir joks maršrutizavimas to nesutvarkys. Programoms, priklausomoms nuo aptikimo, reikia pakaitinio mechanizmo, kurį reikia nuspręsti prieš perėjimą, o ne jo metu.

Šis sąrašas kartu yra ir priėmimo sąrašas. Kiekvienas įrašas, kurio negalite perkelti, tampa dokumentuota išimtimi arba priežastimi palikti nedidelį TAP segmentą vien tam darbo krūviui.

Sudarykite adresų ir grįžimo maršrutų planą

Pasirinkite klientų prefiksą, kuris nesidengia su LAN, senuoju tilto diapazonu ar bet kuriuo tinklu, kurį klientas jau pasiekia. Potinklio topologijos serveriui reikia fragmento, pavyzdžiui, dev tun, topology subnet ir server 10.78.0.0 255.255.255.0, bet tai tik fragmentas, o ne veikiantis profilis. Išlaikykite patvirtintą TLS, tapatybės, transporto ir prieigos politiką ir naudokite prefiksą, kurį patikrinote kaip laisvą.

Tada surašykite paskirties vietas, kurias klientai turi pasiekti, ir kas užtikrina grįžimo kelią. Serveriui reikia įjungto perdavimo ir leidžiamo tolesnio kelio. LAN maršrutizatoriams reikia maršruto atgal į naują prefiksą, arba schema turi naudoti šaltinio vertimą su tuo susijusiu matomumo nuostoliu. Klientui stumiamas maršrutas sukonfigūruoja klientą, o ne LAN atsakymo kelią.

Išbandykite atskirame klausytoje

Naująją tarnybą paleiskite šalia senosios, jos pačios prievade ir adresų diapazone, o ne pakeiskite vienintelį veikiantį įėjimo tašką. Bandomuosius profilius išduokite per esamą registracijos procesą, kad niekas neperkurtų CA dėl migracijos. Prijunkite vieną reprezentatyvų klientą, kai aktyvus tik bandomasis kelias, tada palyginkite priskirtus adresus, privatų DNS, sąrašo programas ir kelius, kurie turi likti užblokuoti.

Įtraukite prisijungimo iš naujo ir grįžtamojo srauto testą. Rankos paspaudimas, kuris baigiasi, nieko nesako apie tai, ar kita pusė gali atsakyti.

Perkelkite klientus grupėmis su atsukimu

Migruokite grupėmis, pakankamai mažomis, kad gedimas būtų palaikymo užduotis, o ne sutrikimas. Senąją tarnybą palikite veikiančią ir aprašytą, kol kiekvienos grupės tikrieji darbo procesai praeis, o atsukimą aprašykite kaip grįžimą prie ankstesnio profilio, o ne kaip perkūrimą. Kiekvienai grupei judant, atnaujinkite adresais pagrįstas ugniasienės taisykles, stebėjimą ir bet kokį serverio inicijuojamą prieigą prie naujo prefikso.

Grupės taip pat suteikia vietą atrasti programą, apie kurią niekas neužsiminė, kol senasis kelias dar egzistuoja palyginimui.

Atsisakykite tilto tik po priėmimo

TAP įrenginio pašalinimas yra paskutinis, o ne pirmas žingsnis. Prieš ką nors šalindami patikrinkite, ar tiltas dar perduoda serverio valdymo adresą, stebėjimo kelią ar nesusijusį darbo krūvį. Atsisakykite paleidimo priklausomybių, narystės tilte ir DHCP rezervacijų per jų savininkus, būtent tokia tvarka, su pastaba, kas buvo pašalinta.

Migracija baigta tada, kai maršrutizuota prieigos schema atitinka sąrašą, o ne tada, kai TAP sąsaja išnyksta iš ip link išvesties.