Ilipat ang OpenVPN mula TAP patungong TUN: isang pagkakasunod-sunod ng migrasyon na gumagana

Ang pagpapalit ng dev tap ng dev tun ay nagbabago ng dinadala ng tunel, hindi lang ng pangalan nito. Ang interface ng TAP ay naghahatid ng mga frame ng Ethernet sa isang bridge, kaya kumikilos ang mga kliyente na parang nakasaksak sa switch ng opisina. Ang interface ng TUN ay nagdadala ng mga packet ng IP, kaya kailangan ng mga kliyente ng ruta at kailangan ng kabilang dulo ng daang pabalik. Ang mga kliyente, plano ng address at rutang pabalik ng LAN ay dapat lumipat kasama ng pagbabagong iyon.

Ang migrasyon ay isang muling pagdidisenyo ng network na may nakakabit na tunel, at pinapanatili ng pagkakasunod-sunod sa ibaba na ito ay maibalik.

Iimbentaryo kung ano talaga ang umaasa sa Ethernet

Ilista ang mga aplikasyon, hindi ang mga host. Tukuyin kung ang bawat isa ay gumagamit ng niruruta na serbisyong TCP o UDP, pagtuklas sa pamamagitan ng broadcast, DHCP mula sa LAN ng opisina, protokol ng Ethernet na hindi IP, o palagay na ang dalawang dulo ay nasa iisang subnet. Ang karaniwang pag-access sa IP ay nakakaligtas sa nirurutang disenyo. Ang protokol na nangangailangan ng hilaw na frame ng Ethernet ay hindi nakakaligtas, at walang dami ng routing ang makakagawa nitong gumana. Ang mga aplikasyong umaasa sa pagtuklas ay nangangailangan ng kapalit na mekanismong napagpasyahan bago ang paglipat, hindi habang ito ay nangyayari.

Ang imbentaryong iyon ay listahan din ng pagtanggap. Ang bawat entry na hindi mo mailipat ay nagiging dokumentadong eksepsiyon o dahilan upang panatilihing buhay ang maliit na segment ng TAP para lamang sa gawaing iyon.

Buuin ang plano ng address at rutang pabalik

Pumili ng prefix ng kliyente na hindi sumasapaw sa LAN, sa lumang saklaw ng bridge o sa anumang network na naaabot na ng kliyente. Ang server na may topolohiyang subnet ay nangangailangan ng fragment tulad ng dev tun, topology subnet at server 10.78.0.0 255.255.255.0, ngunit fragment lamang iyon, hindi gumaganang profile. Panatilihin ang aprubadong patakaran sa TLS, pagkakakilanlan, transport at pag-access sa paligid nito, at gumamit ng prefix na na-verify mong walang gamit.

Pagkatapos, isulat ang mga destinasyong kailangang maabot ng mga kliyente at kung sino ang nagbibigay ng daang pabalik. Kailangan ng server ng naka-enable na forwarding at pinapayagang daan pasulong. Kailangan ng mga router ng LAN ng rutang pabalik sa bagong prefix, o kailangan ng disenyo ng pagsasalin ng pinagmulan kasama ang halaga sa visibility na idinudulot nito. Ang rutang itinutulak sa kliyente ay nagko-configure sa kliyente, hindi sa daang sagot ng LAN.

Subukan sa hiwalay na listener

Itayo ang bagong serbisyo sa tabi ng luma sa sarili nitong port at sariling saklaw ng address, sa halip na palitan ang nag-iisang entry point na gumagana. Maglabas ng mga pilot profile sa pamamagitan ng umiiral na proseso ng enrollment upang walang magtayong muli ng CA para sa migrasyon. Ikonekta ang isang kinatawang kliyente na ang aktibo lamang ay ang pilot path, pagkatapos ay ihambing ang mga inilaang address, pribadong DNS, mga aplikasyon mula sa imbentaryo at ang mga daang dapat manatiling naka-block.

Isama ang pagsubok sa muling pagkonekta at trapikong pabalik. Ang handshake na natatapos ay walang sinasabi kung makakasagot ba ang kabilang dulo.

Ilipat ang mga kliyente nang grupo-grupo na may rollback

Mag-migrate nang grupo-grupo na sapat ang liit upang ang pagkabigo ay gawaing suporta at hindi outage. Panatilihing tumatakbo at dokumentado ang lumang serbisyo hanggang pumasa ang tunay na workflow ng bawat grupo, at isulat ang rollback bilang paglipat pabalik sa dating profile, hindi bilang muling pagtatayo. I-update ang mga patakaran ng firewall na nakabatay sa address, monitoring at anumang pag-access na sinisimulan ng server para sa bagong prefix habang lumilipat ang bawat grupo.

Binibigyan ka rin ng mga grupo ng lugar upang matuklasan ang aplikasyong walang binanggit, habang umiiral pa ang lumang daan para paghambingan.

Alisin ang bridge pagkatapos lamang ng pagtanggap

Ang pagtanggal ng device na TAP ay huling hakbang, hindi una. Suriin kung dinadala pa ng bridge ang address ng pamamahala ng server, daan ng monitoring o walang kaugnayang workload bago magbura ng anuman. Alisin ang mga dependency sa pagsisimula, pagiging miyembro ng bridge at mga reserbasyon ng DHCP sa pamamagitan ng kanilang mga may-ari, sa ayos na iyon, may tala kung ano ang tinanggal.

Tapos na ang migrasyon kapag gumana para sa imbentaryo ang nirurutang modelo ng pag-access, hindi kapag nawala ang interface ng TAP mula sa output ng ip link.