Prestavitev OpenVPN s TAP na TUN: vrstni red migracije, ki deluje

Zamenjava dev tap z dev tun spremeni, kaj tunel prenaša, ne le njegovo ime. Vmesnik TAP predaja Ethernetove okvire mostu, zato se odjemalci obnašajo, kot da so priključeni na pisarniško stikalo. Vmesnik TUN prenaša pakete IP, zato odjemalci potrebujejo poti, druga stran pa pot nazaj. Odjemalci, načrt naslovov in povratna pot LAN-a se morajo premakniti skupaj s to spremembo.

Migracija je prenova omrežja s pripetim tunelom, spodnji vrstni red pa jo ohranja povratno.

Popišite, kaj je v resnici odvisno od Etherneta

Naštejte aplikacije, ne gostiteljev. Ugotovite, ali vsaka uporablja usmerjene storitve TCP ali UDP, odkrivanje z razpošiljanjem, DHCP iz pisarniškega LAN-a, protokol Ethernet, ki ni IP, ali predpostavko, da sta oba konca v istem podomrežju. Običajen dostop IP preživi usmerjeno zasnovo. Protokol, ki potrebuje surove Ethernetove okvire, ne preživi, in nobena količina usmerjanja tega ne popravi. Aplikacije, odvisne od odkrivanja, potrebujejo nadomestni mehanizem, odločen pred prehodom, ne med njim.

Ta popis je hkrati sprejemni seznam. Vsak vnos, ki ga ne morete prestaviti, postane dokumentirana izjema ali razlog, da majhen segment TAP ostane živ samo za to delovno obremenitev.

Sestavite načrt naslovov in povratnih poti

Izberite predpono odjemalcev, ki se ne prekriva z LAN-om, starim obsegom mostu ali omrežjem, ki ga odjemalec že doseže. Strežnik s topologijo podomrežja potrebuje odlomek, kot so dev tun, topology subnet in server 10.78.0.0 255.255.255.0, vendar je to odlomek in ne delujoč profil. Okoli njega ohranite odobreno politiko TLS, identitete, prevoza in dostopa ter uporabite predpono, ki ste jo preverili kot prosto.

Nato zapišite cilje, ki jih morajo odjemalci doseči, in kdo zagotavlja povratno pot. Strežnik potrebuje omogočeno posredovanje in dovoljeno pot naprej. Usmerjevalniki LAN potrebujejo pot nazaj do nove predpone, ali pa zasnova potrebuje preprevajanje vira s stroškom vidnosti, ki ga to prinaša. Pot, potisnjena odjemalcu, nastavi odjemalca, ne povratne poti LAN-a.

Preizkusite na ločenem poslušalcu

Novo storitev postavite ob staro na lastnih vratih in v lastnem obsegu naslovov, namesto da bi zamenjali edino delujočo vstopno točko. Pilotne profile izdajajte prek obstoječega postopka registracije, da nihče ne obnovi CA zaradi migracije. Povežite enega reprezentativnega odjemalca z aktivno samo pilotno potjo, nato primerjajte dodeljene naslove, zasebni DNS, aplikacije s popisa in poti, ki morajo ostati blokirane.

Vključite preizkus ponovnega povezovanja in povratnega prometa. Rokanje, ki se konča, ne pove nič o tem, ali lahko druga stran odgovori.

Premaknite odjemalce v skupinah z vrnitvijo

Migrirajte v skupinah, ki so dovolj majhne, da je okvara opravilo podpore in ne izpad. Staro storitev pustite delujočo in dokumentirano, dokler ne minejo resnični delovni tokovi vsake skupine, vrnitev pa zapišite kot preklop nazaj na prejšnji profil, ne kot ponovno gradnjo. Ko se vsaka skupina premika, posodobite pravila požarnega zidu, ki temeljijo na naslovih, spremljanje in vsak dostop, ki ga sproži strežnik, za novo predpono.

Skupine vam dajo tudi prostor, kjer odkrijete aplikacijo, ki je nihče ni omenil, medtem ko stara pot še obstaja za primerjavo.

Most umaknite šele po sprejemu

Odstranitev naprave TAP je zadnji korak, ne prvi. Preden karkoli izbrišete, preverite, ali most še nosi upravljalni naslov strežnika, pot spremljanja ali nepovezano delovno obremenitev. Umaknite zagonske odvisnosti, članstvo v mostu in rezervacije DHCP prek njihovih lastnikov, v tem vrstnem redu, z opombo o tem, kaj je bilo odstranjeno.

Migracija je končana, ko usmerjeni model dostopa deluje za popis, ne ko vmesnik TAP izgine iz izhoda ip link.