Az OpenVPN átállítása TAP-ról TUN-ra: egy működő migrációs sorrend
A TAP kereteket, a TUN csomagokat visz: az ügyfelek, a címek és a visszautak együtt mozdulnak. Készítsen leltárt a függőségekről, próbálja ki az új szolgáltatást, majd vonja ki a hidat.
A dev tap helyére dev tun állítása megváltoztatja, mit visz az alagút, nem csak a nevét. A TAP interfész Ethernet-kereteket ad át egy hídnak, ezért az ügyfelek úgy viselkednek, mintha az irodai kapcsolóba lennének dugva. A TUN interfész IP-csomagokat visz, ezért az ügyfeleknek útvonalakra van szükségük, a túloldalnak pedig visszaútra. Az ügyfeleknek, a címtervnek és a LAN visszautjának mind együtt kell mozdulnia ezzel a változással.
A migráció egy alagúttal kiegészített hálózati újratervezés, és az alábbi sorrend visszafordíthatóvá teszi.
Készítsen leltárt arról, mi függ valójában az Ethernettől
Az alkalmazásokat listázza, nem a gazdagépeket. Határozza meg, hogy mindegyik használ-e útvonalválasztott TCP- vagy UDP-szolgáltatásokat, sugárzásos felderítést, DHCP-t az irodai LAN-ról, nem IP-alapú Ethernet-protokollt, vagy azt feltételezi-e, hogy mindkét vég ugyanabban az alhálózatban van. A szokásos IP-hozzáférés túléli az útvonalválasztott kialakítást. A nyers Ethernet-kereteket igénylő protokoll nem, és semmilyen mértékű útválasztás nem teszi működőképessé. A felderítéstől függő alkalmazásoknak a váltás előtt eldöntött helyettesítő mechanizmusra van szükségük, nem a váltás közben.
Ez a leltár egyben az elfogadási lista is. Minden tétel, amelyet nem tud migrálni, dokumentált kivétellé válik, vagy okká arra, hogy egy kis TAP-szegmenst életben tartson kizárólag arra a terhelésre.
Építse fel a cím- és visszaút-tervet
Válasszon olyan ügyfél-előtagot, amely nem fedi át a LAN-t, a híd régi tartományát vagy bármely hálózatot, amelyet az ügyfél már elér.dev tun, topology subnet és server 10.78.0.0 255.255.255.0, de ez egy részlet, nem működő profil. Tartsa körülötte a jóváhagyott TLS-, identitás-, átviteli és hozzáférési szabályzatot, és olyan előtagot használjon, amelyet szabadnak ellenőrzött.
Ezután írja le azokat a célokat, amelyeket az ügyfeleknek el kell érniük, és hogy ki biztosítja a visszautat. A kiszolgálónak bekapcsolt továbbításra és engedélyezett továbbvezető útra van szüksége. A LAN-útválasztóknak útvonalra van szükségük az új előtag felé, vagy a terv forrásfordítást igényel az ezzel járó láthatósági költséggel. Az ügyfél konfigurációjába tolt útvonal az ügyfelet állítja be, nem a LAN válaszútját.
Próbálja ki külön figyelőn
Állítsa fel az új szolgáltatást a régi mellé a saját portján és saját címterületén, ahelyett hogy lecserélné az egyetlen működő belépési pontot. A kísérleti profilokat a meglévő regisztrációs folyamaton keresztül adja ki, hogy senki ne építse újra a CA-t egy migráció miatt. Csatlakoztasson egy reprezentatív ügyfelet úgy, hogy csak a kísérleti útvonal aktív, majd hasonlítsa össze a kiosztott címeket, a privát DNS-t, a leltár alkalmazásait és azokat az útvonalakat, amelyeknek blokkolva kell maradniuk.
Tartalmazzon újracsatlakozási és visszaforgalmi tesztet. Egy befejeződő kézfogás semmit sem mond arról, hogy a túloldal tud-e válaszolni.
Mozgassa az ügyfeleket csoportokban, visszaállítással
Olyan csoportokban migráljon, amelyek elég kicsik ahhoz, hogy egy hiba támogatási feladat legyen, ne kiesés. Tartsa a régi szolgáltatást futva és dokumentálva, amíg minden csoport valódi munkafolyamatai át nem mennek, és a visszaállítást az előző profilra való visszaváltásként írja le, nem újraépítésként. Csoportonként frissítse a címalapú tűzfal-szabályokat, a monitorozást és minden kiszolgáló által indított hozzáférést az új előtaghoz.
A csoportok helyet adnak arra is, hogy felfedezze az alkalmazást, amelyet senki nem említett, miközben a régi útvonal még létezik az összehasonlításhoz.
Csak elfogadás után vonja ki a hidat
A TAP-eszköz eltávolítása az utolsó lépés, nem az első. Ellenőrizze, hogy a híd még viszi-e a kiszolgáló kezelési címét, egy monitorozási útvonalat vagy egy kapcsolódó terhelést, mielőtt bármit törölne. Vonja ki az indítási függőségeket, a hídtagságot és a DHCP-foglalásokat a tulajdonosaikon keresztül, ebben a sorrendben, megjegyezve, mi lett eltávolítva.
A migráció akkor kész, amikor az útvonalválasztott hozzáférési modell működik a leltárhoz, nem amikor egy TAP interfész eltűnik a következő kimenetéből: ip link.