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

Zamjena dev tap sa dev tun mijenja šta tunel nosi, a ne samo kako se zove. TAP interfejs predaje Ethernet okvire mostu, pa se klijenti ponašaju kao da su uključeni u kancelarijski svič. TUN interfejs nosi IP pakete, pa su klijentima potrebne rute, a suprotnoj strani put nazad. Klijenti, plan adresa i povratna ruta lokalne mreže moraju se preseliti s tom promjenom.

Migracija je redizajn mreže s priključenim tunelom, a redoslijed ispod ga čini povratnim.

Popišite šta zaista zavisi od Ethernet-a

Navođujte aplikacije, ne hostove. Utvrdite da li svaka koristi rutirane TCP ili UDP usluge, broadcast otkrivanje, DHCP s kancelarijske lokalne mreže, Ethernet protokol koji nije IP ili pretpostavku da su oba kraja u istoj podmreži. Običan IP pristup preživljava rutirani dizajn. Protokol koji traži sirove Ethernet okvire ne preživljava i nikakvo rutiranje ga neće osposobiti. Aplikacije zavisne od otkrivanja trebaju zamjenski mehanizam odlučen prije prelaska, a ne tokom njega.

Taj popis je ujedno i lista prihvatanja. Svaka stavka koju ne možete migrirati postaje dokumentovani izuzetak ili razlog da mali TAP segment ostane živ samo za taj radni teret.

Izradite plan adresa i povratnih ruta

Odaberite prefiks klijenata koji se ne preklapa s lokalnom mrežom, starim opsegom mosta ni mrežom do koje klijent već stiže.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 stizati i ko obezbjeđuje povratni put. Serveru je potrebno uključeno prosljeđivanje i dozvoljen put dalje. Ruteri lokalne mreže trebaju rutu nazad do novog prefiksa ili dizajn traži prevođenje izvora s cijenom vidljivosti koju to nosi. Ruta gurnuta u konfiguraciju klijenta podešava klijenta, a ne povratni put lokalne mreže.

Probno na odvojenom slušaocu

Podignite novu uslugu pored stare na njenom portu i njenom rasponu adresa, umjesto da zamijenite jedinu ulaznu tačku koja radi. Izdajte probne profile kroz postojeći proces upisa da niko ne pravi CA iznova zbog migracije. Povežite jednog reprezentativnog klijenta sa samo probnim putem aktivnim, pa uporedite dodijeljene adrese, privatni DNS, aplikacije s popisa i puteve koji trebaju ostati blokirani.

Uključite test ponovnog spajanja i povratnog saobraćaja. Završeno rukovanje ništa ne govori o tome može li suprotna strana odgovoriti.

Premještajte klijente u grupama s vraćanjem

Migrirajte u grupama dovoljno malim da kvar bude potpora, a ne ispad. Držite staru uslugu pokrenutom i dokumentovanom dok stvarni tokovi rada svake grupe ne prođu, a vraćanje zapišite kao povratak na prethodni profil, a ne kao ponovnu izgradnju. Ažurirajte firewall pravila zasnovana na adresama, nadzor i svaki pristup koji pokreće server za novi prefiks kako se grupe sele.

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

Umirovite most tek nakon prihvatanja

Uklanjanje TAP uređaja zadnji je korak, ne prvi. Provjerite nosi li most još adresu upravljanja servera, put nadzora ili nepovezan radni teret prije nego što bilo šta obrišete. Umirovite zavisnosti pri pokretanju, članstvo u mostu i DHCP rezervacije kroz njihove vlasnike, tim redom, uz zabilješku šta je uklonjeno.

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