OpenVPN:n siirto TAP:sta TUN:iin: toimiva migraatiojärjestys

Vaihto dev tap:stä dev tun:ksi muuttaa sitä, mitä tunneli kuljettaa, ei vain sen nimeä. TAP-rajapinta luovuttaa Ethernet-kehykset sillalle, joten asiakkaat käyttäytyvät kuin ne olisi kytketty toimiston kytkimeen. TUN-rajapinta kuljettaa IP-paketteja, joten asiakkaat tarvitsevat reittejä ja vastapuoli tarvitsee paluupolun. Asiakkaiden, osoitesuunnitelman ja lähiverkon paluureitin on kaikkien siirryttävä tämän muutoksen mukana.

Migraatio on verkon uudelleensuunnittelu, johon on liitetty tunneli, ja alla oleva järjestys pitää sen peruttavana.

Inventoi, mikä todella riippuu Ethernetistä

Listaa sovellukset, älä isäntiä. Selvitä, käyttääkö kukin reititettyjä TCP- tai UDP-palveluja, lähetyspohjaista löytämistä, toimiston lähiverkon DHCP:tä, muuta kuin IP-pohjaista Ethernet-protokollaa vai oletusta siitä, että molemmat päät ovat samassa aliverkossa. Tavallinen IP-pääsy kestää reititetyn suunnittelun. Protokolla, joka tarvitsee raakoja Ethernet-kehyksiä, ei kestä, eikä mikään määrä reititystä saa sitä toimimaan. Löytämisestä riippuvat sovellukset tarvitsevat korvaavan mekanismin, joka päätetään ennen siirtymää, ei sen aikana.

Tuo inventointi on myös hyväksymislista. Jokaisesta merkinnästä, jota et voi migroida, tulee dokumentoitu poikkeus tai syy pitää pieni TAP-segmentti elossa vain kyseistä kuormaa varten.

Rakenna osoite- ja paluureittisuunnitelma

Valitse asiakasetuliite, joka ei mene päällekkäin lähiverkon, vanhan sillan alueen tai minkään verkon kanssa, johon asiakas jo pääsee.dev tun, topology subnet ja server 10.78.0.0 255.255.255.0, mutta se on katkelma, ei toimiva profiili. Pidä sen ympärillä hyväksytty TLS-, identiteetti-, kuljetus- ja käyttöoikeuskäytäntö ja käytä etuliitettä, jonka olet varmistanut vapaaksi.

Kirjoita sitten ylös kohteet, joihin asiakkaiden on päästävä, ja kuka tarjoaa paluupolun. Palvelin tarvitsee käytössä olevan edelleenlähetyksen ja sallitun polun eteenpäin. Lähiverkon reitittimet tarvitsevat reitin takaisin uuteen etuliitteeseen, tai suunnittelu tarvitsee lähdeosoitteen käännöksen ja sen mukanaan tuoman näkyvyyskustannuksen. Asiakkaan kokoonpanoon työnnetty reitti konfiguroi asiakkaan, ei lähiverkon vastauspolkua.

Kokeile erillisellä kuuntelijalla

Nosta uusi palvelu vanhan viereen omalle portilleen ja omalle osoitealueelleen sen sijaan, että korvaisit ainoan toimivan sisääntulokohdan. Myönnä kokeiluprofiilit olemassa olevan rekisteröintiprosessin kautta, jotta kukaan ei rakenna CA:ta uudelleen migraation takia. Yhdistä yksi edustava asiakas niin, että vain kokeilupolku on aktiivinen, ja vertaa sitten jaettuja osoitteita, yksityistä DNS:ää, inventoinnin sovelluksia ja polkuja, joiden pitäisi pysyä estettyinä.

Sisällytä uudelleenyhdistämis- ja paluuliikennetesti. Valmistuva kättely ei kerro mitään siitä, voiko vastapuoli vastata.

Siirrä asiakkaita ryhmissä ja pidä peruutusmahdollisuus

Migroi ryhmissä, jotka ovat tarpeeksi pieniä, jotta vika on tukitehtävä eikä katkos. Pidä vanha palvelu käynnissä ja dokumentoituna, kunnes jokaisen ryhmän todelliset työnkulut menevät läpi, ja kirjoita peruutus paluuna edelliseen profiiliin, ei uudelleenrakennuksena. Päivitä osoiteperusteiset palomuurisäännöt, valvonta ja kaikki palvelimen aloittama pääsy uudelle etuliitteelle sitä mukaa kun kukin ryhmä siirtyy.

Ryhmät antavat myös paikan löytää sovellus, jota kukaan ei maininnut, kun vanha polku on vielä olemassa vertailua varten.

Poista silta käytöstä vasta hyväksynnän jälkeen

TAP-laitteen poistaminen on viimeinen vaihe, ei ensimmäinen. Tarkista, kuljettaako silta yhä palvelimen hallintaosoitetta, valvontapolkua tai siihen liittymätöntä kuormaa, ennen kuin poistat mitään. Poista käynnistyksen riippuvuudet, sillan jäsenyys ja DHCP-varaukset niiden omistajien kautta tässä järjestyksessä ja kirjaa, mitä poistettiin.

Migraatio on valmis, kun reititetty käyttömalli toimii inventoinnille, ei silloin, kun TAP-rajapinta katoaa komennon ip link tulosteesta.