Kalimi i OpenVPN nga TAP në TUN: një rend migrimi që funksionon

Zëvendësimi i dev tap me dev tun ndryshon atë që transporton tuneli, jo vetëm emrin e tij. Një ndërfaqe TAP i dorëzon kuadrot Ethernet një ure, prandaj klientët sillen sikur të ishin të lidhur me komutatorin e zyrës. Një ndërfaqe TUN transporton paketa IP, prandaj klientët kanë nevojë për rrugë dhe ana tjetër ka nevojë për një rrugë kthimi. Klientët, plani i adresave dhe rruga e kthimit të LAN-it duhet të lëvizin të gjitha me atë ndryshim.

Migrimi është një ridizenjim i rrjetit me një tunel të bashkangjitur, dhe rendi më poshtë e mban atë të kthyeshëm.

Inventarizo çfarë varet vërtet nga Ethernet

Listo aplikacionet, jo hostet. Përcakto nëse secili përdor shërbime TCP ose UDP të rrugëtuara, zbulim përmes transmetimit, DHCP nga LAN-i i zyrës, një protokoll Ethernet që nuk është IP, ose supozimin se të dy skajet janë në të njëjtën nënrrjet. Qasja e zakonshme IP i mbijeton një dizajni të rrugëtuar. Një protokoll që kërkon kuadro Ethernet të papërpunuara nuk i mbijeton, dhe asnjë sasi rrugëtimi nuk e bën atë të funksionojë. Aplikacionet që varen nga zbulimi kanë nevojë për një mekanizëm zëvendësues të vendosur para kalimit, jo gjatë tij.

Ai inventar është njëkohësisht lista e pranimit. Çdo zë që nuk mund ta migrosh bëhet një përjashtim i dokumentuar ose një arsye për të mbajtur gjallë një segment të vogël TAP vetëm për atë ngarkesë pune.

Ndërto planin e adresave dhe rrugëve të kthimit

Zgjidh një prefiks klientësh që nuk mbivendoset me LAN-in, me gamën e vjetër të urës ose me çdo rrjet që një klient e arrin tashmë. Një server me topologji nënrrjeti ka nevojë për një fragment si dev tun, topology subnet dhe server 10.78.0.0 255.255.255.0, por ky është fragment, jo profil funksional. Mbaj përreth politikën e miratuar të TLS, identitetit, transportit dhe qasjes, dhe përdor një prefiks që e ke verifikuar si të lirë.

Pastaj shkruaj destinacionet që klientët duhet të arrijnë dhe kush siguron rrugën e kthimit. Serveri ka nevojë për përcjellje të aktivizuar dhe një rrugë të lejuar përpara. Routerat e LAN-it kanë nevojë për një rrugë kthimi drejt prefiksit të ri, ose dizajni ka nevojë për përkthim burimi me koston e dukshmërisë që kjo nënkupton. Një rrugë e shtyrë te klienti konfiguron klientin, jo rrugën e përgjigjes të LAN-it.

Provo në një dëgjues të veçantë

Vendos shërbimin e ri pranë atij të vjetër në portin dhe gamën e adresave të vetë, në vend që të zëvendësosh pikën e vetme të hyrjes që funksionon. Lësho profile pilot përmes procesit ekzistues të regjistrimit që askush të mos rindërtojë CA-në për një migrim. Lidh një klient përfaqësues me vetëm rrugën pilot aktive, pastaj krahaso adresat e caktuara, DNS-in privat, aplikacionet nga inventari dhe rrugët që duhet të mbeten të bllokuara.

Përfshi një test rilidhjeje dhe trafiku kthimi. Një shtrëngim duar që përfundon nuk thotë asgjë për atë nëse ana tjetër mund të përgjigjet.

Lëviz klientët në grupe me rikthim

Migro në grupe mjaft të vogla që një dështim të jetë detyrë mbështetjeje dhe jo ndërprerje. Mbaj shërbimin e vjetër në punë dhe të dokumentuar derisa rrjedhat reale të punës të secilit grup të kalojnë, dhe rikthimin shkruaje si një kalim përsëri në profilin e mëparshëm, jo si rindërtim. Ndërsa çdo grup lëviz, përditëso rregullat e firewall-it të bazuara në adresa, monitorimin dhe çdo qasje të nisur nga serveri për prefiksin e ri.

Grupet gjithashtu të japin një vend për të zbuluar aplikacionin që askush nuk e përmendi, ndërsa rruga e vjetër ekziston ende për krahasim.

Tërhiq urën vetëm pas pranimit

Heqja e pajisjes TAP është hapi i fundit, jo i pari. Kontrollo nëse ura ende transporton adresën e menaxhimit të serverit, një rrugë monitorimi ose një ngarkesë pune të palidhur përpara se të fshish diçka. Tërhiq varësitë e nisjes, anëtarësimin në urë dhe rezervimet DHCP përmes pronarëve të tyre, në atë rend, me një shënim për atë që u hoq.

Migrimi përfundon kur modeli i qasjes së rrugëtuar funksionon për inventarin, jo kur një ndërfaqe TAP zhduket nga dalja e ip link.