Egress IPv6 mati setelah OpenVPN dimulai ulang: periksa kepemilikan prefiks
IPv6 mati setelah terowongan dibuat ulang. Tentukan siapa pemilik prefiks yang didelegasikan, alamat klien, dan rute balik sebelum memulai ulang apa pun.
IPv6 berhenti meneruskan lalu lintas saat OpenVPN dimulai ulang, dan IPv4 tetap berfungsi. Antarmuka terowongan dibuat ulang, dan hal lain yang mengelola status IPv6-nya kehilangan alamat atau kehilangan rute yang membuat prefiks dapat dijangkau. Ada tiga bagian status yang terpisah, dan masing-masing punya pemilik berbeda: prefiks yang didelegasikan penyedia dan masa hidupnya, alamat yang diberikan ke klien VPN, dan rute hulu yang mengirim prefiks klien itu kembali ke server. Identifikasi pemilik masing-masing sebelum menyentuh daemon mana pun, karena memulai ulang yang salah menyembunyikan masalah selama sehari dan mengembalikannya pada koneksi berikutnya.
Tiga bagian status IPv6, tiga pemilik
| State | Typical owner | What breaks when it is wrong |
|---|---|---|
| Delegated prefix and lifetime | Upstream router or provider via DHCPv6-PD | Clients keep addresses that the upstream no longer routes |
| Client addresses inside the tunnel | OpenVPN server config or a delegation daemon | No global address, or an address outside the routed prefix |
| Return route for the client prefix | Upstream router, or the server's own routing table | Outbound works, replies never arrive |
Alamat dengan cakupan global di dalam terowongan tidak cukup dengan sendirinya. Router hulu tetap harus mengirim prefiks itu kembali ke server VPN, dan mereka tidak akan melakukannya hanya karena server kebetulan memiliki alamat darinya.
Itulah sebabnya menyalin /64 publik ke kumpulan terowongan berisiko. Prefiks yang dirutekan ke server bukan hal yang sama dengan prefiks yang dianggap on-link oleh sisi hulu, dan penemuan tetangga tidak akan mengisi celah itu.
Baca status server sebelum mengubah apa pun
Ambil status dua kali, sekali saat IPv6 berfungsi dan sekali setelah mulai ulang, lalu bandingkan. Tampilan hanya-baca sudah cukup, dan tidak memakan biaya selama jendela pemeliharaan:
ip -6 addr show
ip -6 route show table all
ip -6 rule show
sysctl net.ipv6.conf.all.forwardingCari tiga perbedaan spesifik: rute yang hilang, alamat yang berpindah ke masa hidup usang atau tidak valid, dan prefiks yang berubah setelah delegasi ulang sementara konfigurasi VPN masih mengumumkan yang lama.
Jika alamat hilang tetapi prefiks tidak berubah, daemon yang menetapkannya berhenti mengelola antarmuka. Jika prefiks berubah tetapi alamatnya tidak, konfigurasi klien sudah usang. Kedua kegagalan tampak identik dari peramban dan tidak punya kesamaan apa pun.
Putuskan apakah dhcpcd harus mengelola terowongan
dhcpcd dapat menemukan antarmuka dan mendelegasikan sebagian prefiks DHCPv6 ke antarmuka hilir, dan konfigurasinya dapat menyebut target delegasi secara eksplisit. Tanpa target eksplisit, perilaku terdokumentasinya dapat melibatkan antarmuka lain, dan begitulah terowongan berakhir dengan alamat yang tidak direncanakan siapa pun.
Dua syarat seharusnya mendorong Anda menyerahkan pengalamatan statis terowongan kepada OpenVPN: server mendorong alamat tetap dalam konfigurasinya, dan nama terowongan berubah saat menyambung ulang. Jika keduanya berlaku, kecualikan terowongan dari daemon delegasi dengan sengaja, disertai komentar yang menyebut alasannya.
Jika delegasi ke terowongan justru disengaja, terapkan penanganan perubahan prefiks. Itu berarti bereaksi saat prefiks yang didelegasikan atau masa hidupnya berubah, memperbarui prefiks klien yang diumumkan server, dan menambahkan rute itu lagi. Mengecualikan antarmuka dalam rancangan itu menghapus satu-satunya komponen yang mengetahui prefiks baru.
Memulai ulang dhcpcd mungkin tampak memperbaiki keadaan karena membuat ulang status, tetapi juga memperbarui atau menarik konfigurasi untuk antarmuka yang tidak Anda pikirkan. Pemulihan itu tidak menjadikannya keharusan setelah setiap mulai ulang VPN. Itu juga mengatur ulang penghitung yang Anda pakai sebagai bukti. Utamakan muat ulang tertarget pada antarmuka yang benar-benar Anda ubah.
Validasi IPv6 secara terpisah dari NAT IPv4
Pastikan penerusan aktif dan rute hulu menunjuk ke prefiks klien yang sebenarnya, lalu buat koneksi IPv6 baru yang diizinkan. Periksa juga tabel rute IPv6 milik klien, karena klien yang menampilkan alamat publik tidak membuktikan bahwa permintaannya memakai terowongan.
Penyamaran IPv4 menyelesaikan masalah lain: jalur balik untuk sumber privat. Itu tidak melakukan apa pun untuk prefiks IPv6 yang dicabut, dan menambahkannya tidak akan mengembalikan IPv6.
Tutup dengan catatan kepemilikan: komponen mana yang mendelegasikan prefiks, mana yang menetapkan alamat klien, mana yang memegang rute balik, dan apa yang terjadi pada masing-masing saat menyambung ulang. Empat baris di runbook menyelamatkan orang berikutnya dari memulai ulang tiga daemon untuk menemukan yang benar-benar penting.