Menghalakan IPv6 antara dua tapak melalui VPN sedia ada

WAN yang hanya IPv4 masih boleh membawa IPv6 dalaman. Jejaki pemilih, laluan kernel, penghantaran dan awalan pulangan yang membuang balasan secara senyap.

Apabila anda menambah awalan IPv6 pada terowong tapak-ke-tapak, paket tidak bergerak seperti yang dicadangkan rajah. Gerbang tempatan mengambil seluruh paket IPv6, menyulitkannya dan meletakkan pengepala IP luar di hadapannya yang keluarga alamatnya ditentukan oleh alamat hujung, bukan oleh apa yang ada di dalam. Gerbang jauh membuang pengepala luar itu dan meneruskan paket asal ke LAN-nya, tempat ia kembali menjadi paket IPv6 biasa. Terowong luar dan trafik dalam ialah dua perbualan berasingan yang berkongsi kunci, pasangan hujung dan tiada apa-apa lagi.

Dua pengepala, dua keluarga alamat

Dalam mod terowong IPsec, paket IPv6 dalam menjadi muatan di belakang pengepala ESP. Pengepala luar yang membawa paket ESP itu boleh jadi IPv4 atau IPv6, dan ia mengikut local_addrs dan remote_addrs. WireGuard melakukan perkara sama dengan kurang upacara: paket dalam ialah muatan datagram UDP ke hujung rakan. Kedua-duanya membiarkan pengepala dalam tidak disentuh, sebab itulah bahagian jauh boleh menghalakannya selepas penyahsulitan.

Laluan antara tapak hanya melihat UDP 4500 apabila IPsec menggunakan NAT traversal, atau UDP 51820 untuk pendengar WireGuard lalai. Mana-mana penghala di laluan itu boleh jadi hanya IPv4 dan trafik IPv6 tetap menyeberang, kerana ia tidak pernah muncul sebagai paket IPv6 pada laluan itu. Itu memberi pemisahan pertama yang bersih: tcpdump -ni eth0 udp port 51820 menunjukkan laluan tersulit, tcpdump -ni wg0 ip6 menunjukkan trafik dalam. Tangkapan luar yang sibuk dengan tangkapan dalam yang senyap bermakna kernel tidak meletakkan IPv6 ke dalam terowong; itu penghalakan atau dasar, bukan keadaan pautan.

Gerbang juga mengurangkan Hop Limit dalam semasa meneruskan, jadi hujung dikira sebagai penghala pada laluan IPv6. Kiraan hop luar dan Hop Limit dalam bergerak secara berasingan, dan paket yang mati di gerbang jauh mati dalam penghantaran, bukan penyulitan.

Pemilih dan AllowedIPs ialah senarai kebenaran

IKEv2 merundingkan awalan dalam mana yang boleh dibawa child SA. Pada strongSwan 5.9 dan lebih baru, menulisnya dalam swanctl.conf kelihatan 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
  }
}

Tinggalkan local_ts dan remote_ts dan strongSwan memperolehnya daripada subnet antara muka yang dipilihnya. Pada hos dual-stack, jalan pintas itu sering menghasilkan pasangan hanya IPv4: SA naik dan IPv6 ditolak sebelum ia sampai ke kod ESP. Menulis kedua-dua awalan menjadikan SA layak membawanya, dan start_action = trap menaikkannya pada paket pertama yang sepadan.

WireGuard mempunyai satu senarai yang melakukan dua tugas. Dalam blok rakan, AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48 ialah laluan yang dipasang semasa menghantar dan juga penapis yang digunakan semasa menerima: paket nyahsulit yang sumber dalamnya jatuh di luar senarai rakan itu dibuang secara senyap. wg-quick menambah laluan bagi setiap entri, jadi blok rakan di bawah tidak memerlukan arahan ip -6 route berasingan.

[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-dua senarai mesti dicerminkan: tapak B menerima awalan tapak A sebagai pemilih jauh dan menghalakannya balik, dan terowong hanya berfungsi apabila kedua-dua arah bersetuju. Senarai tidak simetri memberi gejala yang paling banyak membuang masa — jabat tangan yang sihat, pembilang bergerak di satu pihak, dan ping dari A ke B yang berjaya sedangkan tiada apa-apa dari B sampai ke A.

Penghantaran, laluan dan awalan pulangan

Linux tidak menghantar IPv6 sehingga anda menyuruhnya, dan tetapan itu per namespace bukan per antara muka:

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 lupa dalam reka bentuk berasaskan laluan. IPsec berasaskan dasar memasang dasar XFRM yang sepadan dengan awalan, tetapi persediaan berasaskan laluan dengan vti6 atau WireGuard memerlukan laluan IPv6 sebenar yang menunjuk ke peranti itu. Kekalkan sysctl di bawah /etc/sysctl.d/; jika tidak, but semula mengembalikan penghantaran kepada mati secara senyap.

Penghantaran mempunyai kesan sampingan yang perlu diketahui: kernel kemudian mengabaikan pengumuman penghala melainkan net.ipv6.conf.<wan>.accept_ra ialah 2, jadi gerbang yang alamat WAN-nya tiba melalui SLAAC boleh kehilangan laluan lalainya sebaik anda mengaktifkan penghantaran. Tetapkan accept_ra = 2 pada antara muka itu dalam fail yang sama dan laluan itu kekal. Teras tapak B juga mesti mempelajari 2001:db8:aa::/48 daripada gerbang terowong, melalui laluan statik atau protokol penghalakan di atas terowong, jika tidak balasan mati di dalam rangkaian B sendiri.

Semakan empat langkah yang menyetempatkan kerosakan

Bekerja dalam urutan ini dan berhenti pada langkah pertama yang gagal, kerana setiap langkah kemudian bergantung pada yang sebelumnya.

  1. Pemilih: swanctl --list-sas sepatutnya menunjukkan pasangan awalan IPv6 pada child SA, atau wg show wg0 allowed-ips awalan jauh dengan latest-handshakes terkini.
  2. Laluan kernel: ip -6 route get 2001:db8:bb::10 mesti menjawab dengan peranti terowong, bukan antara muka WAN.
  3. Tangkapan dalam: tcpdump -ni wg0 ip6 semasa melakukan ping antara hos LAN sebenar. Paket yang keluar tetapi tiada yang kembali menunjuk ke laluan atau tembok api B; tiada paket langsung menunjuk balik ke langkah 1 atau 2.
  4. Destinasi: pada hos B, ss -6 -ltn mengesahkan perkhidmatan mendengar pada IPv6, dan pembilang tembok api tempatan menunjukkan sama ada paket diterima atau dibuang.

MTU masuk dalam pusingan yang sama. Penghala IPv6 tidak memecah, jadi paket terlalu besar dibuang dan Packet Too Big kembali kepada penghantar. Jika jabat tangan dan ping kecil berfungsi tetapi pemindahan fail tersekat, kecilkan muatan sehingga ia lalu: ping -6 -s 1400 -c 3 2001:db8:bb::10. Antara muka WireGuard lalai mempunyai MTU 1420 bait dan IPsec di atas IPv4 memotong lebih banyak, jadi menetapkan MTU dalam lebih baik daripada berharap penemuan MTU laluan melalui tembok api yang membuang ICMPv6.

Mod kegagalan yang kelihatan seperti masalah tembok api

Yang paling biasa bukan tembok api sama sekali: perkhidmatan mengikat pada 0.0.0.0 dan bukan ::, rekod AAAA wujud, dan klien menerima penolakan pantas melalui IPv6 yang disembunyikan pelayar dual-stack dengan kembali ke IPv4. Jika hanya sesetengah aplikasi gagal, periksa keluarga pendengaran sebelum menyentuh set peraturan.

Yang kedua ialah penapisan ICMPv6. Neighbor Discovery dan Packet Too Big ialah bahagian operasi biasa, bukan diagnostik, dan dasar yang membuang semua ICMPv6 menghasilkan terowong yang bersambung, mengesahkan diri dan kemudian tersekat pada apa-apa yang lebih besar daripada paket kecil. Benarkan jenis yang menjadi sandaran laluan dan biarkan pembilang hidup supaya pembuangan kelihatan.

Yang ketiga ialah awalan yang ditambah pada terowong tetapi tidak pernah pada pelan alamat tapak yang memilikinya, jadi tiada penghala mengumumkannya dan tiada hos boleh menjawab daripadanya. Mulakan dengan satu awalan dan satu pasangan hos, buktikan kedua-dua arah dengan empat langkah, kemudian tambah selebihnya; awalan rosak kekal satu baris dalam konfigurasi dan bukannya reka bentuk semula. Satu-satunya rujukan rasmi yang berbaloi dibiarkan terbuka ialah RFC 8200, yang mentakrifkan pengepala yang dibawa terowong.

Artikel berkaitan