Menambahkan IPv6 privat ke laboratorium OpenVPN, satu titik pemeriksaan setiap kali

Pertahankan transport luar di IPv4 dan perluas rencana dalam. Lima titik pemeriksaan: prefiks, helper, dorong rute, penerusan, dan uji dari sisi klien.

Anda sudah punya klien yang terhubung lewat IPv4 dan mencapai beban kerja IPv4 privat di belakang server. Tujuannya adalah mencapai beban kerja IPv6 privat melalui tunnel yang sama tanpa menyentuh transport luar. Urutan itu penting: jalur luar tetap IPv4, dan hanya rencana alamat dalam, rute klien, serta jalur balik dari server ke LAN yang berubah. Lima titik pemeriksaan, masing-masing dengan sesuatu yang konkret untuk dilihat sebelum melanjutkan.

Titik pemeriksaan satu: koneksi yang sudah bekerja

Hubungkan klien dan pastikan jalur IPv4 sebelum menambahkan apa pun. Tunnel yang berfungsi memberi Anda garis dasar yang memisahkan kesalahan IPv6 baru dari masalah konektivitas lama. Ini juga memberi tahu instans server mana yang sebenarnya Anda ubah.

Catat pool, topologi, dan rute yang didorong yang sudah Anda andalkan. Pekerjaan IPv6 memperluas konfigurasi itu; tidak menggantikannya.

Titik pemeriksaan dua: pilih prefiks dalam

Pilih ULA /48 untuk situs dan potong dua /64 darinya: satu untuk klien tunnel, satu untuk segmen LAN yang menampung beban kerja IPv6. Hasilkan ID global 40-bit alih-alih menyalin prefiks contoh, dan periksa kedua subnet terhadap setiap jaringan yang sudah dirutekan situs:

Outer transport: IPv4 OpenVPN UDP
IPv4 pool:       10.90.0.0/24
IPv6 VPN pool:   fd73:93bc:b6e9:77::/64
IPv6 LAN:        fd73:93bc:b6e9:60::/64
Server LAN IPv6: fd73:93bc:b6e9:60::1

Dua /64 independen mencegah pool klien terpotong dari segmen LAN, yang penting nanti saat Anda menulis rute balik. Nilai di atas adalah satu contoh yang sudah dikerjakan, bukan prefiks untuk dipakai ulang.

Titik pemeriksaan tiga: tambahkan helper dan dorong rute

Baca konfigurasi server saat ini sebelum menambahkan apa pun. Salinan kedua dari direktif yang sudah ada tidak menyatu dengan yang pertama, dan kesalahan yang muncul menyebut direktif itu, bukan IPv6. Dengan helper IPv4 yang ada, dua baris memperluasnya. Masing-masing menjawab pertanyaan berbeda:

server-ipv6 fd73:93bc:b6e9:77::/64
push "route-ipv6 fd73:93bc:b6e9:60::/64"

Yang pertama adalah helper praktis yang mengatur antarmuka dan pool klien. Yang kedua menyebut tujuan LAN yang harus dicapai klien. Memberi klien alamat IPv6 tidak memberi tahu jaringan apa yang ada di belakang server, jadi kedua baris diperlukan.

Helper tidak hidup berdampingan dengan pool IPv6 statis atau dengan nopool. Jika penerapan sengaja mengalokasikan alamat secara statis, pertahankan kebijakan itu dan rancang padanan IPv6 secara eksplisit alih-alih menghapus kebijakan agar cocok dengan contoh.

Titik pemeriksaan empat: penerusan dan rute balasan

Aktifkan penerusan IPv6 di server melalui pemilik konfigurasi sistem itu sendiri, bukan dengan penulisan runtime sekali pakai yang akan Anda lupakan. Bentuk runtime berguna untuk uji cepat. Konfigurasi permanen berada di berkas drop-in yang dibaca pemilik jaringan distribusi:

sysctl -w net.ipv6.conf.all.forwarding=1

Penerusan mengubah perilaku IPv6 host melampaui perutean paket. Host yang menerima pengumuman router sebagai klien berhenti melakukannya dengan cara yang sama begitu mulai meneruskan. Karena itu mesin yang uplink IPv6-nya bergantung pada RA memerlukan rencana eksplisit untuk uplink itu.

Lalu beri LAN rute kembali ke pool tunnel. Gateway IPv6 beban kerja adalah router LAN, bukan server VPN, jadi rute berada di router itu dan menunjuk ke alamat LAN server:

ip -6 route add fd73:93bc:b6e9:77::/64 via fd73:93bc:b6e9:60::1

Pertahankan tipe ICMPv6 yang dibutuhkan tautan, termasuk umpan balik MTU jalur. Aturan firewall IPv4 tidak berarti aturan IPv6, dan pemblokiran IPv6 menyeluruh merusak penemuan tetangga dengan cara yang tampak seperti kesalahan perutean.

Titik pemeriksaan lima: baca klien, lalu uji

Sambungkan ulang klien dan baca alamat yang benar-benar diterimanya alih-alih menyimpulkannya dari alamat helper server. Daftar antarmuka menunjukkan kedua keluarga pada perangkat yang sama:

ip -6 addr show tun0
ip -6 route get fd73:93bc:b6e9:60::20

Rute yang memilih tunnel membuktikan klien tahu ke mana mengirim paket. Itu tidak membuktikan server meneruskannya, router LAN punya rute balik, atau aplikasi diizinkan menjawab.

Uji aplikasi itu sendiri melalui setiap keluarga secara bergantian, lalu ulangi setelah menyambung ulang dan setelah host dinyalakan ulang. Rute atau sysctl yang hanya bertahan sampai reboot adalah uji, bukan rancangan.

Terbitkan catatan AAAA hanya setelah jalur IPv6 menjawab dari ujung ke ujung. DNS yang ditanyakan lewat IPv4 masih bisa mengembalikan alamat IPv6, jadi nama yang bisa diresolusi bukan bukti ada yang mendengarkan. Panduan RFC 4193 untuk ULA mencakup pembuatan ID global yang membuat prefiks ini milik Anda, bukan salinan.

Artikel terkait