Memindahkan OpenVPN dari TAP ke TUN: urutan migrasi yang berhasil

Mengganti dev tap dengan dev tun mengubah apa yang dibawa terowongan, bukan hanya namanya. Antarmuka TAP menyerahkan frame Ethernet ke bridge, sehingga klien berperilaku seolah tercolok ke switch kantor. Antarmuka TUN membawa paket IP, sehingga klien memerlukan rute dan sisi seberang memerlukan jalur balik. Klien, rencana alamat, dan rute balik LAN semuanya harus berpindah bersama perubahan itu.

Migrasi ini adalah desain ulang jaringan dengan terowongan menempel, dan urutan di bawah menjaganya bisa dibalik.

Inventarisasi apa yang benar-benar bergantung pada Ethernet

Daftar aplikasinya, bukan host-nya. Tentukan apakah masing-masing memakai layanan TCP atau UDP yang dirutekan, penemuan lewat siaran, DHCP dari LAN kantor, protokol Ethernet non-IP, atau asumsi bahwa kedua ujung berada di subnet yang sama. Akses IP biasa bertahan pada desain yang dirutekan. Protokol yang memerlukan frame Ethernet mentah tidak, dan tidak ada jumlah perutean yang akan membuatnya berfungsi. Aplikasi yang bergantung pada penemuan memerlukan mekanisme pengganti yang diputuskan sebelum pemindahan, bukan saat berlangsung.

Inventaris itu juga daftar penerimaan. Setiap entri yang tidak dapat Anda migrasikan menjadi pengecualian terdokumentasi atau alasan untuk mempertahankan segmen TAP kecil hanya bagi beban kerja itu.

Bangun rencana alamat dan rute balik

Pilih prefiks klien yang tidak tumpang tindih dengan LAN, rentang bridge lama, atau jaringan mana pun yang sudah dijangkau klien.dev tun, topology subnet dan server 10.78.0.0 255.255.255.0, tetapi itu fragmen, bukan profil yang berfungsi. Pertahankan kebijakan TLS, identitas, transportasi, dan akses yang disetujui di sekitarnya, dan gunakan prefiks yang telah Anda pastikan bebas.

Lalu catat tujuan yang harus dicapai klien dan siapa yang menyediakan jalur balik. Server memerlukan penerusan aktif dan jalur terus yang diizinkan. Router LAN memerlukan rute balik ke prefiks baru, atau desain memerlukan penerjemahan sumber dengan biaya visibilitas yang menyertainya. Rute yang didorong ke konfigurasi klien mengonfigurasi klien, bukan jalur balasan LAN.

Uji coba pada listener terpisah

Dirikan layanan baru di samping yang lama pada port dan rentang alamatnya sendiri, alih-alih mengganti satu-satunya titik masuk yang berfungsi. Terbitkan profil uji coba melalui proses pendaftaran yang ada agar tidak ada yang membangun ulang CA demi migrasi. Hubungkan satu klien perwakilan dengan hanya jalur uji coba aktif, lalu bandingkan alamat yang diberikan, DNS privat, aplikasi dari inventaris, dan jalur yang seharusnya tetap diblokir.

Sertakan uji sambung ulang dan lalu lintas balik. Jabat tangan yang selesai tidak mengatakan apa pun tentang apakah sisi seberang dapat menjawab.

Pindahkan klien dalam kelompok dengan rollback

Migrasikan dalam kelompok yang cukup kecil sehingga kegagalan menjadi tugas dukungan, bukan pemadaman. Biarkan layanan lama berjalan dan terdokumentasi sampai alur kerja nyata setiap kelompok lolos, dan tulis rollback sebagai kembali ke profil sebelumnya, bukan pembangunan ulang. Perbarui aturan firewall berbasis alamat, pemantauan, dan akses apa pun yang diprakarsai server untuk prefiks baru saat setiap kelompok berpindah.

Kelompok juga memberi Anda tempat menemukan aplikasi yang tidak disebutkan siapa pun, sementara jalur lama masih ada untuk dibandingkan.

Pensiunkan bridge hanya setelah penerimaan

Melepas perangkat TAP adalah langkah terakhir, bukan yang pertama. Periksa apakah bridge masih membawa alamat manajemen server, jalur pemantauan, atau beban kerja yang tidak terkait sebelum menghapus apa pun. Pensiunkan dependensi startup, keanggotaan bridge, dan reservasi DHCP melalui pemiliknya, dalam urutan itu, dengan catatan tentang apa yang dilepas.

Migrasi selesai ketika model akses yang dirutekan berfungsi bagi inventaris, bukan ketika antarmuka TAP hilang dari keluaran ip link.