IPv6 lewat tunnel OpenVPN: penelusuran router rumah

Laptop punya alamat IPv6, tunnel aktif di atas IPv4, tetapi setiap uji IPv6 gagal. Atau lebih buruk: uji berhasil dan trafik keluar lewat jalur ISP tanpa pernah masuk ke tunnel. Kedua hasil kembali ke satu keputusan yang hilang: tidak ada yang memberi router prefiks yang bisa dirutekan ke klien. Menelusuri jalur dari klien ke luar menemukan bagian mana yang hilang.

Mulai dari tempat klien berada

Periksa klien sebelum menyentuh server. ip -6 addr seharusnya menunjukkan alamat tunnel dari pool, dan ip -6 route seharusnya menunjukkan prefiks yang didorong dan mengarah ke perangkat tunnel. Saat alamatnya ada tetapi rutenya tidak, dorongan itu hilang atau klien mengabaikannya. Saat keduanya tidak ada, server tidak memberikan apa pun sama sekali.

Lalu periksa apa yang klien yakini tentang dunia luar. Rute default lewat tunnel mengklaim seluruh trafik IPv6, sedangkan rute untuk 2000::/3 hanya mengklaim unicast global. Keduanya bisa benar, dan keduanya menjawab pertanyaan berbeda soal kebocoran.

Klien tanpa rute default IPv6 sama sekali gagal di setiap uji publik padahal tunnelnya sendiri sehat sepenuhnya. Itu celah kebijakan, bukan tunnel rusak.

Periksa pool yang benar-benar bisa dirutekan server

Server hanya bisa memberikan alamat dari prefiks yang benar-benar ia kendalikan. Jika ISP mendelegasikan /56, sisakan satu /64 untuk tunnel dan biarkan sisanya untuk LAN. Bila ISP hanya menyerahkan satu /64 di WAN dan tidak merutekan apa pun lagi, biarkan prefiks LAN dan beri tunnel rentang lokal unik, sambil menerima bahwa klien tidak akan punya jalan keluar global.

Pool dan dorongan berjalan bersama. server-ipv6 2001:db8:80:10::/64 memberikan alamat, dan push "route-ipv6 2000::/3" memberi tahu klien apa yang harus dikirim ke tunnel. Mendorong 2000::/3 mencakup unicast global dan membiarkan rentang link-local serta multicast di luar tunnel.

Tulis prefiks yang dipilih ke catatan penerapan. Siapa pun yang mengubah penyerahan ISP berikutnya perlu tahu /64 mana yang sudah ditempati tunnel.

Nyalakan penerusan untuk keluarga kedua

Penerusan IPv4 tidak berarti penerusan IPv6. Setel net.ipv6.conf.all.forwarding=1 dan cerminkan semua yang sudah diizinkan kebijakan FORWARD IPv4. Pada router yang rantai FORWARD-nya membuang secara default, kumpulan aturan yang hilang terlihat persis seperti tunnel mati.

Jabat tangan berhasil, klien menerima alamat, dan tidak ada yang kembali. Tambahkan aturan untuk kedua arah dan untuk kaki WAN, karena tunnel yang mencapai LAN tetapi tidak internet gagal di uji ketiga. Setelah percobaan gagal, lihat penghitung rantai, karena aturan yang tidak pernah cocok adalah masalah berbeda dari aturan yang cocok lalu membuang.

ip6tables -A FORWARD -i br0 -o tun0 -j ACCEPT
ip6tables -A FORWARD -i tun0 -o br0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -i tun0 -o wan0 -j ACCEPT

Satu efek samping menangkap orang yang akhirnya menyalahkan tunnel. Mengaktifkan penerusan membuat kernel melewati konfigurasi alamat lewat Router Advertisement kecuali diberi tahu sebaliknya, dan rute default yang dipelajari begitu ikut hilang. Entah sematkan rute default eksplisit di antarmuka WAN, atau setel accept_ra ke 2 di sana dengan sengaja. Setelah salah satu perubahan, pastikan router masih punya jalur IPv6 yang bisa dipakai keluar sebelum menguji klien lagi.

Jawab penemuan tetangga saat hulu tidak merutekan

Peralatan hulu kadang memperlakukan /64 yang didelegasikan sebagai milik tautannya sendiri dan menolak merutekan subprefiks apa pun ke kotak VPN. Saat itu terjadi, sesuatu harus menjawab permintaan tetangga untuk setiap alamat klien satu per satu.

OpenVPN memaparkan alamat yang diberikan ke hook client-connect, sehingga entri bisa mengikuti pool sebenarnya alih-alih daftar yang dirawat manual. Hook menambahkan ip -6 neigh add proxy $ifconfig_pool_remote_ip6 dev eth0, dan hook client-disconnect yang cocok menghapusnya. Tanpa penghapusan itu, tabel proxy menua dan klien berikutnya bisa mewarisi entri untuk alamat yang tidak pernah ia terima. Pastikan keadaannya dengan ip -6 neigh show proxy.

Anggap proxying sebagai solusi sementara. Rute statis untuk /64 tunnel yang diarahkan ke router bertahan terhadap pergantian klien dan sama sekali tidak butuh hook shell berhak istimewa.

Ikuti jalur ke luar, satu hop demi satu

Uji ke luar dalam tiga langkah: pertama alamat tunnel router, lalu host LAN, dan ketiga tujuan publik lewat traceroute6. Pool dibuktikan langkah pertama, penerusan dan firewall LAN oleh langkah kedua, dan jalur balik lewat hulu oleh langkah ketiga. Setiap kegagalan mempersempit pencarian ke satu perangkat alih-alih membuka lagi seluruh desain.

Perhatikan MTU tunnel, karena router IPv6 di jalur tidak akan memfragmentasi untuk Anda. MTU terlalu besar muncul sebagai galat packet-too-big dan TLS yang macet alih-alih kegagalan bersih. Setel secara eksplisit dan uji dengan muatan mendekati batas.