Merutekan IPv6 antara dua situs melalui VPN yang sudah ada

WAN yang hanya IPv4 tetap bisa membawa IPv6 internal. Telusuri selector, rute kernel, forwarding, dan prefiks balik yang diam-diam membuang balasan.

Saat Anda menambahkan prefiks IPv6 ke tunnel situs-ke-situs, paket tidak bergerak seperti yang disarankan diagram. Gateway lokal mengambil seluruh paket IPv6, mengenkripsinya, dan menaruh header IP luar di depannya yang keluarga alamatnya ditentukan oleh alamat endpoint, bukan oleh isi di dalamnya. Gateway jauh melepas header luar itu dan meneruskan paket asli ke LAN-nya, tempat paket itu kembali menjadi paket IPv6 biasa. Tunnel luar dan lalu lintas dalam adalah dua percakapan terpisah yang hanya berbagi kunci, pasangan endpoint, dan tidak ada lagi.

Dua header, dua keluarga alamat

Dalam mode tunnel IPsec, paket IPv6 dalam menjadi muatan di belakang header ESP. Header luar yang membawa paket ESP itu bisa IPv4 atau IPv6, dan mengikuti local_addrs dan remote_addrs. WireGuard melakukan hal yang sama dengan lebih sedikit upacara: paket dalam adalah muatan datagram UDP ke endpoint peer. Keduanya membiarkan header dalam tidak tersentuh, itulah sebabnya sisi jauh bisa merutekannya setelah dekapsulasi.

Jalur antara situs hanya melihat UDP 4500 saat IPsec memakai NAT traversal, atau UDP 51820 untuk listener WireGuard bawaan. Setiap router di sana bisa hanya IPv4 dan lalu lintas IPv6 tetap menyeberang, karena tidak pernah muncul sebagai paket IPv6 di jalur itu. Itu memberi pemisahan pertama yang bersih: tcpdump -ni eth0 udp port 51820 menunjukkan jalur terenkripsi, tcpdump -ni wg0 ip6 menunjukkan lalu lintas dalam. Rekaman luar yang ramai dengan rekaman dalam yang sunyi berarti kernel tidak memasukkan IPv6 ke tunnel; itu perutean atau kebijakan, bukan status tautan.

Gateway juga menurunkan Hop Limit dalam saat meneruskan, sehingga endpoint dihitung sebagai router di jalur IPv6. Jumlah hop luar dan Hop Limit dalam bergerak secara independen, dan paket yang mati di gateway jauh mati dalam penerusan, bukan dalam enkripsi.

Selector dan AllowedIPs adalah daftar izin

IKEv2 menegosiasikan prefiks dalam mana yang boleh dibawa child SA. Pada strongSwan 5.9 dan yang lebih baru, menuliskannya di swanctl.conf tampak seperti ini:

children {
  net6 {
    local_ts  = 2001:db8:aa::/48
    remote_ts = 2001:db8:bb::/48
    mode = tunnel
    esp_proposals = aes256gcm16-prfsha384-ecp384
    start_action = trap
  }
}

Hilangkan local_ts dan remote_ts dan strongSwan menurunkannya dari subnet antarmuka yang dipilihnya. Pada host dual-stack, jalan pintas itu sering menghasilkan pasangan hanya IPv4: SA naik dan IPv6 ditolak sebelum mencapai kode ESP. Menuliskan kedua prefiks membuat SA layak membawanya, dan start_action = trap menaikkannya pada paket pertama yang cocok.

WireGuard punya satu daftar yang melakukan dua tugas. Di blok peer, AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48 adalah rute yang dipasang saat mengirim sekaligus filter yang diterapkan saat menerima: paket terdekripsi yang sumber dalamnya jatuh di luar daftar peer itu akan dibuang diam-diam. wg-quick menambahkan rute per entri, jadi blok peer di bawah tidak memerlukan perintah ip -6 route terpisah.

[Interface]
Address = 2001:db8:aa:ff::1/64, fd00:aa:ff::1/64
ListenPort = 51820

[Peer]
PublicKey = <site-b-public-key>
Endpoint = 203.0.113.20:51820
AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48

Kedua daftar harus bercermin: situs B menerima prefiks situs A sebagai selector jauh dan merutekannya kembali, dan tunnel hanya bekerja bila kedua arah sepakat. Daftar asimetris memberi gejala yang paling banyak menghabiskan waktu — handshake yang sehat, penghitung bergerak di satu sisi, dan ping dari A ke B yang berhasil sementara tidak ada pun dari B yang mencapai A.

Penerusan, rute, dan prefiks balik

Linux tidak meneruskan IPv6 sampai Anda menyuruhnya, dan pengaturannya per namespace, bukan per antarmuka:

sysctl -w net.ipv6.conf.all.forwarding=1
ip -6 route add 2001:db8:bb::/48 dev wg0
ip -6 route get 2001:db8:bb::10 from 2001:db8:aa::10

Baris kedua itulah yang orang lupakan pada desain berbasis rute. IPsec berbasis kebijakan memasang kebijakan XFRM yang cocok dengan prefiks, tetapi penyiapan berbasis rute dengan vti6 atau WireGuard membutuhkan rute IPv6 sungguhan yang menunjuk ke perangkat itu. Simpan sysctl di bawah /etc/sysctl.d/; kalau tidak, reboot diam-diam mengembalikan penerusan ke mati.

Penerusan punya efek samping yang perlu diketahui: kernel lalu mengabaikan router advertisement kecuali net.ipv6.conf.<wan>.accept_ra bernilai 2, sehingga gateway yang alamat WAN-nya datang lewat SLAAC bisa kehilangan rute bawaannya begitu Anda mengaktifkan penerusan. Setel accept_ra = 2 pada antarmuka itu di berkas yang sama dan rutenya bertahan. Inti situs B juga harus mempelajari 2001:db8:aa::/48 dari gateway tunnel, lewat rute statis atau protokol perutean di atas tunnel, kalau tidak balasannya mati di dalam jaringan B sendiri.

Pemeriksaan empat langkah yang melokalisasi patahnya

Bekerjalah dalam urutan ini dan berhenti pada langkah pertama yang gagal, karena setiap langkah berikutnya bergantung pada langkah sebelumnya.

  1. Selector: swanctl --list-sas seharusnya menunjukkan pasangan prefiks IPv6 pada child SA, atau wg show wg0 allowed-ips prefiks jauh dengan latest-handshakes yang baru.
  2. Rute kernel: ip -6 route get 2001:db8:bb::10 harus menjawab dengan perangkat tunnel, bukan antarmuka WAN.
  3. Rekaman dalam: tcpdump -ni wg0 ip6 saat melakukan ping antar host LAN sungguhan. Paket yang keluar tetapi tidak ada yang kembali menunjuk ke rute atau firewall B; tidak ada paket sama sekali menunjuk balik ke langkah 1 atau 2.
  4. Tujuan: pada host B, ss -6 -ltn memastikan layanan mendengarkan di IPv6, dan penghitung firewall lokal menunjukkan apakah paket diterima atau dibuang.

MTU masuk di putaran yang sama. Router IPv6 tidak memfragmentasi, jadi paket yang kebesaran dibuang dan Packet Too Big kembali ke pengirim. Jika handshake dan ping kecil bekerja tetapi transfer berkas macet, kecilkan muatan sampai lolos: ping -6 -s 1400 -c 3 2001:db8:bb::10. Antarmuka WireGuard bawaannya ber-MTU 1420 byte dan IPsec di atas IPv4 memotong lebih banyak, jadi menyetel MTU dalam lebih baik daripada berharap penemuan MTU jalur lewat firewall yang membuang ICMPv6.

Mode kegagalan yang tampak seperti masalah firewall

Yang paling umum bukan firewall sama sekali: layanan mengikat ke 0.0.0.0 alih-alih ::, catatan AAAA ada, dan klien mendapat penolakan cepat lewat IPv6 yang disembunyikan browser dual-stack dengan mundur ke IPv4. Jika hanya sebagian aplikasi gagal, periksa keluarga pendengaran sebelum menyentuh set aturan.

Yang kedua adalah penyaringan ICMPv6. Neighbor Discovery dan Packet Too Big adalah bagian operasi normal, bukan diagnostik, dan kebijakan yang membuang semua ICMPv6 menghasilkan tunnel yang tersambung, terautentikasi, lalu macet pada apa pun yang lebih besar dari paket kecil. Izinkan tipe yang menjadi sandaran jalur dan biarkan penghitung menyala agar pembuangan terlihat.

Yang ketiga adalah prefiks yang ditambahkan ke tunnel tetapi tidak pernah ke rencana alamat situs yang memilikinya, sehingga tidak ada router yang mengumumkannya dan tidak ada host yang bisa menjawab darinya. Mulailah dengan satu prefiks dan satu pasangan host, buktikan kedua arah dengan empat langkah, lalu tambahkan sisanya; prefiks rusak tetap satu baris dalam konfigurasi alih-alih desain ulang. Satu-satunya referensi resmi yang layak dibiarkan terbuka adalah RFC 8200, yang mendefinisikan header yang dibawa tunnel.

Artikel terkait