OpenVPN von TAP auf TUN umstellen: eine Migrationsreihenfolge, die funktioniert
TAP trägt Frames, TUN Pakete: Clients, Adressen und Rückwege ziehen alle mit. Erfassen Sie die Abhängigkeiten, pilotieren Sie den neuen Dienst und nehmen Sie dann die Bridge außer Betrieb.
Der Wechsel von dev tap zu dev tun ändert, was der Tunnel trägt, nicht nur seinen Namen. Eine TAP-Schnittstelle übergibt Ethernet-Frames an eine Bridge, sodass sich Clients verhalten, als wären sie am Büro-Switch angeschlossen. Eine TUN-Schnittstelle trägt IP-Pakete, sodass Clients Routen brauchen und die Gegenseite einen Rückweg. Die Clients, der Adressplan und die Rückroute des LAN müssen alle mit dieser Änderung umziehen.
Die Migration ist ein Netzwerk-Redesign mit angehängtem Tunnel, und die Reihenfolge unten hält sie umkehrbar.
Erfassen Sie, was tatsächlich von Ethernet abhängt
Listen Sie die Anwendungen auf, nicht die Hosts. Bestimmen Sie, ob jede geroutete TCP- oder UDP-Dienste, Broadcast-Erkennung, DHCP aus dem Büro-LAN, ein Ethernet-Protokoll ohne IP oder die Annahme nutzt, dass beide Enden im selben Subnetz liegen. Gewöhnlicher IP-Zugriff übersteht ein geroutetes Design. Ein Protokoll, das rohe Ethernet-Frames braucht, nicht, und keine Menge Routing wird es zum Laufen bringen. Erkennungsabhängige Anwendungen brauchen einen Ersatzmechanismus, der vor dem Umstieg entschieden wird, nicht währenddessen.
Diese Erfassung ist auch die Abnahmeliste. Jeder Eintrag, den Sie nicht migrieren können, wird zu einer dokumentierten Ausnahme oder zu einem Grund, ein kleines TAP-Segment allein für diese Arbeitslast am Leben zu halten.
Bauen Sie den Adress- und Rückroute-Plan
Wählen Sie ein Client-Präfix, das sich nicht mit dem LAN, dem alten Bridge-Bereich oder einem Netz überschneidet, das ein Client bereits erreicht.dev tun, topology subnet und server 10.78.0.0 255.255.255.0, aber das ist ein Fragment und kein funktionierendes Profil. Behalten Sie die genehmigte TLS-, Identitäts-, Transport- und Zugriffsrichtlinie darum herum und verwenden Sie ein Präfix, das Sie als frei geprüft haben.
Notieren Sie dann die Ziele, die Clients erreichen müssen, und wer den Rückweg bereitstellt. Der Server braucht aktivierte Weiterleitung und einen erlaubten Weg nach vorn. LAN-Router brauchen eine Route zurück zum neuen Präfix, oder das Design braucht Quellübersetzung mit den Sichtbarkeitskosten, die das mit sich bringt. Eine Route, die in die Client-Konfiguration geschoben wird, konfiguriert den Client, nicht den Antwortweg des LAN.
Pilot auf einem separaten Listener
Stellen Sie den neuen Dienst neben den alten auf einem eigenen Port und einem eigenen Adressbereich auf, statt den einzigen funktionierenden Einstiegspunkt zu ersetzen. Geben Sie Pilotprofile über den bestehenden Registrierungsprozess aus, damit niemand für eine Migration die CA neu baut. Verbinden Sie einen repräsentativen Client mit nur dem Pilotpfad aktiv und vergleichen Sie dann zugewiesene Adressen, privates DNS, die Anwendungen aus der Erfassung und die Pfade, die gesperrt bleiben sollen.
Schließen Sie einen Wiederverbindungs- und einen Rückverkehrstest ein. Ein abgeschlossener Handshake sagt nichts darüber aus, ob die Gegenseite antworten kann.
Verschieben Sie Clients in Gruppen mit Rollback
Migrieren Sie in Gruppen, die klein genug sind, dass ein Fehler eine Supportaufgabe und kein Ausfall ist. Lassen Sie den alten Dienst laufen und dokumentiert, bis die echten Arbeitsabläufe jeder Gruppe bestehen, und schreiben Sie das Rollback als Rückschalten auf das vorherige Profil, nicht als Neuaufbau. Aktualisieren Sie adressbasierte Firewall-Regeln, Monitoring und jeden serverinitiierten Zugriff für das neue Präfix, während jede Gruppe umzieht.
Gruppen geben Ihnen außerdem einen Ort, an dem Sie die Anwendung entdecken, die niemand erwähnt hat, während der alte Pfad noch zum Vergleich existiert.
Nehmen Sie die Bridge erst nach der Abnahme außer Betrieb
Das Entfernen des TAP-Geräts ist der letzte Schritt, nicht der erste. Prüfen Sie, ob die Bridge noch die Verwaltungsadresse des Servers, einen Überwachungspfad oder eine unabhängige Arbeitslast trägt, bevor Sie etwas löschen. Nehmen Sie Startabhängigkeiten, Bridge-Mitgliedschaft und DHCP-Reservierungen über ihre Eigentümer außer Betrieb, in dieser Reihenfolge, mit einer Notiz darüber, was entfernt wurde.
Die Migration ist fertig, wenn das geroutete Zugriffsmodell für die Erfassung funktioniert, nicht wenn eine TAP-Schnittstelle aus der Ausgabe von ip link verschwindet.