Movado de OpenVPN de TAP al TUN: migrada ordo kiu funkcias

Anstataŭigi dev tap per dev tun ŝanĝas tion, kion portas la tunelo, ne nur ĝian nomon. TAP-interfaco transdonas Ethernet-kadrojn al ponto, do klientoj kondutas kvazaŭ ili estus ŝtopitaj en la oficejan komutilon. TUN-interfaco portas IP-pakaĵojn, do klientoj bezonas itinerojn kaj la alia flanko bezonas reenan vojon. La klientoj, la adresa plano kaj la reena itinero de la loka reto ĉiuj devas moviĝi kun tiu ŝanĝo.

La migrado estas redesegno kun tunelo alkroĉita, kaj la ordo sube tenas ĝin renversebla.

Inventaru, kio vere dependas de Ethernet

Listigu la aplikaĵojn, ne la gastigantojn. Determinu ĉu ĉiu uzas itineritajn TCP- aŭ UDP-servojn, dissendan malkovron, DHCP el la oficeja loka reto, ne-IP Ethernet-protokolon aŭ supozon ke ambaŭ finoj estas en la sama subreto. Ordinara IP-aliro postvivas itineritan dezajnon. Protokolo kiu bezonas krudajn Ethernet-kadrojn ne, kaj neniu kvanto da itinerado igos ĝin funkcii. Aplikaĵoj dependaj de malkovro bezonas anstataŭan mekanismon deciditan antaŭ la transiro, ne dum ĝi.

Tiu inventaro estas ankaŭ la akcepta listo. Ĉiu ero kiun vi ne povas migri fariĝas dokumentita escepto aŭ kialo teni malgrandan TAP-segmenton viva nur por tiu laborŝarĝo.

Konstruu la planon de adresoj kaj reenaj itineroj

Elektu klientan prefikson kiu ne interkovras la lokan reton, la malnovan pontan gamon aŭ ajnan reton kiun kliento jam atingas.dev tun, topology subnet kaj server 10.78.0.0 255.255.255.0, sed tio estas fragmento, ne funkcianta profilo. Konservu ĉirkaŭ ĝi la aprobitan TLS-, identec-, transportan kaj alirpolitikon, kaj uzu prefikson kiun vi kontrolis kiel libera.

Poste notu la celojn kiujn klientoj devas atingi kaj kiu provizas la reenan vojon. La servilo bezonas ŝaltitan plusendadon kaj permesitan pluan vojon. La LAN-itineroj bezonas itineron reen al la nova prefikso, aŭ la dezajno bezonas fontan tradukadon kun la videbleca kosto kiun tio implicas. Itinero puŝita al la klienta agordo agordas la klienton, ne la respondan vojon de la loka reto.

Testu per aparta aŭskultanto

Starigu la novan servon apud la malnova sur propra pordo kaj propra adresaro, anstataŭ anstataŭigi la solan funkciantan enirpunkton. Eldonu testajn profilojn tra la ekzistanta aliĝprocezo por ke neniu rekonstruu la CA pro migrado. Konektu unu reprezentan klienton kun nur la testa vojo aktiva, poste komparu atribuitajn adresojn, privatan DNS, la aplikaĵojn el la inventaro kaj la vojojn kiuj devas resti blokitaj.

Inkluzivu rekonektan kaj reentrafikan teston. Manpremo kiu kompletiĝas diras nenion pri tio ĉu la alia flanko povas respondi.

Movi klientojn en grupoj kun restarigo

Migru en grupoj sufiĉe malgrandaj ke malsukceso estu subtena tasko, ne interrompo. Tenu la malnovan servon funkcianta kaj dokumentita ĝis la veraj laborfluoj de ĉiu grupo pasas, kaj skribu la restarigon kiel ŝaltadon reen al la antaŭa profilo, ne kiel rekonstruon. Ĝisdatigu adresbazitajn fajroŝirmilajn regulojn, monitoradon kaj ajnan servil-iniciatan aliron por la nova prefikso dum ĉiu grupo moviĝas.

Grupoj ankaŭ donas al vi lokon malkovri la aplikaĵon kiun neniu menciis, dum la malnova vojo ankoraŭ ekzistas por kompari.

Malmunu la ponton nur post akcepto

Forigi la TAP-aparaton estas la lasta paŝo, ne la unua. Kontrolu ĉu la ponto ankoraŭ portas la administran adreson de la servilo, monitoradan vojon aŭ ne rilatan laborŝarĝon antaŭ ol forigi ion ajn. Malmuntu startajn dependecojn, pontan membrecon kaj DHCP-rezervojn tra iliaj posedantoj, en tiu ordo, kun noto pri tio kio estis forigita.

La migrado finiĝas kiam la itinerita alirmodelo funkcias por la inventaro, ne kiam TAP-interfaco malaperas el la eligo de ip link.