Að flytja OpenVPN frá TAP yfir á TUN: flutningsröð sem virkar

Að skipta dev tap út fyrir dev tun breytir því sem göngin bera, ekki bara nafninu. TAP-viðmót afhendir Ethernet-ramma til brúar, svo biðlar hegða sér eins og þeir séu tengdir í skipti skrifstofunnar. TUN-viðmót ber IP-pakka, svo biðlar þurfa leiðir og hin hliðin þarf afturleið. Biðlarnir, heimilisfangaskráin og afturleið LANsins verða öll að fylgja þeirri breytingu.

Flutningurinn er endurhönnun nettengs með göngum við hlið, og röðin hér að neðan heldur henni afturkræfri.

Gerðu skrá yfir hvað raunverulega er háð Ethernet

Skráðu forritin, ekki vélarnar. Ákvarðaðu hvort hvert þeirra notar beinaðar TCP- eða UDP-þjónustur, uppgötvun með útvarpi, DHCP frá LAN skrifstofunnar, Ethernet-samskiptareglur sem ekki eru IP, eða þá forsendu að báðir endar séu í sama undirneti. Venjulegur IP-aðgangur lifir beinaða hönnun af. Samskiptareglur sem þurfa hráa Ethernet-ramma gera það ekki, og engin beining mun láta þær virka. Forrit sem byggja á uppgötvun þurfa varameðferð sem ákvörðuð er fyrir yfirfærsluna, ekki á meðan.

Sú skrá er líka samþykkislistinn. Hver færsla sem þú getur ekki flutt verður skjalfest undantekning eða ástæða til að halda litlum TAP-hluta lifandi eingöngu fyrir þá vinnslu.

Byggðu heimilisfanga- og afturleiðaráætlunina

Veldu forskeyti biðla sem skarast ekki við LANið, gamla svið brúarinnar eða neitt net sem biðill nær þegar til.dev tun, topology subnet og server 10.78.0.0 255.255.255.0, en það er brot, ekki virk prófíll. Hafðu samþykktu TLS-, auðkenningar-, flutnings- og aðgangstefnuna í kringum það og notaðu forskeyti sem þú hefur staðfest að sé laust.

Skrifaðu svo niður áfangastaðina sem biðlar verða að ná til og hver útvegar afturleiðina. Þjónninn þarf virka framsendingu og leyfða leið áfram. LAN-beinar þurfa leið til baka að nýja forskeytinu, eða hönnunin þarf upprunatúlkun með þeim sýnileikakostnaði sem það hefur í för með sér. Leið sem ýtt er inn í stillingar biðilsins stillir biðilinn, ekki svarleið LANsins.

Prófaðu á aðskildum hlustara

Reistu nýju þjónustuna við hlið þeirrar gömlu á eigin gátt og eigin heimilisfangasviði, í stað þess að skipta út eina virka innganginum. Gefðu út prufuprófíla um núverandi skráningarferli svo enginn endurbyggir CA fyrir flutning. Tengdu einn dæmigerðan biðil með aðeins prufuleiðina virka og berðu svo saman úthlutuð heimilisföng, einkadns, forritin úr skránni og leiðirnar sem eiga að vera lokaðar.

Láttu fylgja prófun á endurtengingu og afturumferð. Handaband sem klárast segir ekkert um hvort hin hliðin geti svarað.

Flyttu biðla í hópum með afturköllun

Flyttu í hópum sem eru nógu litlir til að bilun sé stuðningsverkefni en ekki niðurfall. Haltu gömlu þjónustunni gangandi og skjalfestri þar til raunveruleg vinnuferli hvers hóps standast, og skrifaðu afturköllunina sem skipti aftur í fyrri prófíl en ekki endurbyggingu. Uppfærðu eldveggjarreglur byggðar á heimilisföngum, vöktun og allan aðgang sem þjónninn hefur frumkvæði að fyrir nýja forskeytið eftir því sem hver hópur flyst.

Hópar gefa þér líka stað til að uppgötva forritið sem enginn nefndi, á meðan gamla leiðin er enn til samanburðar.

Settu brúna úr notkun aðeins eftir samþykki

Að fjarlægja TAP-tækið er síðasta skrefið, ekki það fyrsta. Athugaðu hvort brúin beri enn stjórnheimilisfang þjónsins, vöktunarleið eða ótengda vinnslu áður en þú eyðir nokkru. Settu upphafsháð, aðild að brúnni og DHCP-frátektir úr notkun í gegnum eigendur þeirra, í þeirri röð, með athugasemd um hvað var fjarlægt.

Flutningnum er lokið þegar beinaða aðgangslíkanið virkar fyrir skrána, ekki þegar TAP-viðmót hverfur úr úttaki ip link.