Premještanje OpenVPN-a s TAP na TUN: redoslijed migracije koji funkcioniše

Zamjena dev tap s dev tun mijenja šta tunel prenosi, ne samo kako se zove. TAP interfejs predaje Ethernet okvire mostu, pa se klijenti ponašaju kao da su priključeni na kancelarijski svič. TUN interfejs prenosi IP pakete, pa klijentima trebaju rute, a drugoj strani treba put nazad. Klijenti, plan adresa i povratna ruta LAN-a moraju se preseliti zajedno s tom promjenom.

Migracija je redizajn mreže sa pridruženim tunelom, a redoslijed ispod čini je reverzibilnom.

Popišite šta zaista zavisi od Etherneta

Navedite aplikacije, ne hostove. Utvrdite da li svaka koristi rutirane TCP ili UDP usluge, otkrivanje putem broadcasta, DHCP sa kancelarijskog LAN-a, Ethernet protokol koji nije IP, ili pretpostavku da su oba kraja u istoj podmreži. Običan IP pristup preživljava rutirani dizajn. Protokol kojem trebaju sirovi Ethernet okviri ne preživljava, i nikakva količina rutiranja to neće popraviti. Aplikacijama zavisnim od otkrivanja treba zamjenski mehanizam odlučen prije prelaska, a ne tokom njega.

Taj popis je ujedno i lista prihvatanja. Svaka stavka koju ne možete premjestiti postaje dokumentovani izuzetak ili razlog da se mali TAP segment zadrži samo za to radno opterećenje.

Napravite plan adresa i povratnih ruta

Izaberite prefiks klijenata koji se ne preklapa s LAN-om, starim opsegom mosta ili bilo kojom mrežom do koje klijent već dolazi. Server s topologijom podmreže treba fragment kao dev tun, topology subnet i server 10.78.0.0 255.255.255.0, ali to je fragment, a ne radni profil. Zadržite oko njega odobrenu TLS, identitetsku, transportnu i pristupnu politiku i koristite prefiks koji ste provjerili kao slobodan.

Zatim zapišite odredišta do kojih klijenti moraju doći i ko obezbjeđuje povratni put. Serveru treba omogućeno prosljeđivanje i dozvoljen dalji put. LAN ruterima treba ruta nazad ka novom prefiksu, ili dizajnu treba prevođenje izvora s troškom vidljivosti koji to podrazumijeva. Ruta gurnuta klijentu konfiguriše klijenta, a ne povratni put LAN-a.

Testirajte na odvojenom slušaocu

Podignite novu uslugu pored stare na njenom sopstvenom portu i u njenom sopstvenom opsegu adresa, umjesto da zamijenite jedinu ulaznu tačku koja radi. Izdajte probne profile kroz postojeći proces registracije da niko ne bi ponovo gradio CA zbog migracije. Povežite jednog reprezentativnog klijenta sa aktivnim samo probnim putem, pa uporedite dodijeljene adrese, privatni DNS, aplikacije s popisa i puteve koji treba da ostanu blokirani.

Uključite test ponovnog povezivanja i povratnog saobraćaja. Rukovanje koje se završi ništa ne govori o tome može li druga strana odgovoriti.

Premještajte klijente u grupama s vraćanjem

Migrirajte u grupama dovoljno malim da kvar bude zadatak podrške, a ne prekid. Držite staru uslugu u radu i dokumentovanu dok stvarni radni tokovi svake grupe ne prođu, a vraćanje zapišite kao prelazak na prethodni profil, a ne kao ponovnu izgradnju. Kako se svaka grupa premješta, ažurirajte pravila firewall-a zasnovana na adresama, nadzor i svaki pristup koji inicira server za novi prefiks.

Grupe vam daju i mjesto da otkrijete aplikaciju koju niko nije spomenuo, dok stari put još postoji za poređenje.

Povucite most tek poslije prihvatanja

Uklanjanje TAP uređaja je posljednji korak, a ne prvi. Provjerite da li most još prenosi adresu upravljanja servera, put nadzora ili nepovezano radno opterećenje prije nego što bilo šta obrišete. Povucite zavisnosti pokretanja, članstvo u mostu i DHCP rezervacije kroz njihove vlasnike, tim redom, s napomenom šta je uklonjeno.

Migracija je završena kada rutirani model pristupa radi za popis, a ne kada TAP interfejs nestane iz izlaza ip link.