OpenVPN pāreja no TAP uz TUN: migrācijas secība, kas darbojas

Ja dev tap tiek aizstāts ar dev tun, mainās tas, ko tunelis pārsūta, nevis tikai tā nosaukums. TAP saskarne nodod Ethernet kadrus tiltam, tāpēc klienti uzvedas tā, it kā būtu pievienoti biroja komutatoram. TUN saskarne pārsūta IP paketes, tāpēc klientiem vajag maršrutus, bet otrajai pusei — ceļu atpakaļ. Klienti, adrešu plāns un LAN atgriešanās maršruts visiem jāmainās kopā ar šo izmaiņu.

Migrācija ir tīkla pārprojektēšana ar pievienotu tuneli, un tālāk dotā secība ļauj to veikt atgriezeniski.

Uzskaitiet, kas patiešām ir atkarīgs no Ethernet

Uzskaitiet lietojumprogrammas, nevis resursdatorus. Nosakiet, vai katra no tām izmanto maršrutētus TCP vai UDP pakalpojumus, apraides atklāšanu, DHCP no biroja LAN, Ethernet protokolu, kas nav IP, vai pieņēmumu, ka abi gali atrodas vienā apakštīklā. Parastā IP piekļuve maršrutētā shēmā saglabājas. Protokols, kuram vajag neapstrādātus Ethernet kadrus, nesaglabājas, un nekāds maršrutēšanas apjoms to nelīdzēs. Lietojumprogrammām, kas atkarīgas no atklāšanas, vajag aizstājēju mehānismu, kas izlemts pirms pārejas, nevis tās laikā.

Šis uzskaitījums ir arī pieņemšanas saraksts. Katrs ieraksts, ko nevarat pārcelt, kļūst par dokumentētu izņēmumu vai par iemeslu paturēt nelielu TAP segmentu tikai šim darba apjomam.

Izveidojiet adrešu un atgriešanās maršrutu plānu

Izvēlieties klientu prefiksu, kas nepārklājas ar LAN, veco tilta diapazonu vai jebkuru tīklu, ko klients jau sasniedz. Apakštīkla topoloģijas serverim vajag fragmentu, piemēram, dev tun, topology subnet un server 10.78.0.0 255.255.255.0, bet tas ir fragments, nevis strādājošs profils. Saglabājiet ap to apstiprināto TLS, identitātes, transporta un piekļuves politiku un izmantojiet prefiksu, kuru esat pārbaudījis kā brīvu.

Pēc tam pierakstiet galamērķus, kas klientiem jāsasniedz, un to, kas nodrošina atgriešanās ceļu. Serverim jābūt iespējotam pārsūtīšanai un atļautam tālākam ceļam. LAN maršrutētājiem vajag maršrutu atpakaļ uz jauno prefiksu, vai arī shēmai jāizmanto avota tulkošana ar to saistīto pārskatāmības zudumu. Klientam nosūtītais maršruts konfigurē klientu, nevis LAN atbildes ceļu.

Pilotējiet atsevišķā klausītājā

Jauno servisu novietojiet blakus vecajam savā portā un savā adrešu diapazonā, nevis aizstājiet vienīgo strādājošo ieejas punktu. Pilota profilus izsniedziet ar esošo reģistrācijas procesu, lai neviens nepārbūvētu CA migrācijas dēļ. Pievienojiet vienu reprezentatīvu klientu, kad aktīvs ir tikai pilota ceļš, pēc tam salīdziniet piešķirtās adreses, privāto DNS, saraksta lietojumprogrammas un ceļus, kuriem jāpaliek bloķētiem.

Iekļaujiet atkārtotas pievienošanās un atgriešanās trafika testu. Rokasspiediens, kas pabeidzas, neko nepasaka par to, vai otrā puse var atbildēt.

Pārvietojiet klientus grupās ar atritināšanu

Migrējiet grupās, kas ir pietiekami mazas, lai kļūme būtu atbalsta uzdevums, nevis pārtraukums. Turiet veco servisu darbojošos un dokumentētu, līdz katras grupas reālie darbplūsmas iztur, un atritināšanu pierakstiet kā atgriešanos pie iepriekšējā profila, nevis pārbūvi. Kad katra grupa pārvietojas, atjauniniet uz adresēm balstītos ugunsmūra noteikumus, uzraudzību un jebkuru servera iniciētu piekļuvi jaunajam prefiksam.

Grupas arī dod vietu, kur atklāt lietojumprogrammu, par kuru neviens nav minējis, kamēr vecais ceļš vēl pastāv salīdzināšanai.

Atsakieties no tilta tikai pēc pieņemšanas

TAP ierīces noņemšana ir pēdējais solis, nevis pirmais. Pirms kaut ko dzēst pārbaudiet, vai tilts vēl pārsūta servera pārvaldības adresi, uzraudzības ceļu vai nesaistītu darba apjomu. Atsakieties no startēšanas atkarībām, dalības tiltā un DHCP rezervācijām pie to īpašniekiem, tieši šādā secībā, ar piezīmi par to, kas tika noņemts.

Migrācija ir pabeigta, kad maršrutētā piekļuves shēma atbilst sarakstam, nevis tad, kad TAP saskarne pazūd no ip link izvades.