IPv6 link-local tidak berfungsi melalui VPN: mengapa fe80 berhenti di pautan
Alamat fe80:: hanya bermakna pada satu pautan. Lihat mengapa VPN berpenghalaan tidak dapat membawanya, bagaimana kegagalan itu kelihatan, dan alamat mana yang patut digunakan sebaliknya.
Anda menghidupkan terowong, melakukan ping fe80::1 dengan terowong sebagai antara muka sumber, dan tiada apa yang kembali. Ini bukan peraturan firewall yang anda terlupa. Alamat link-local hanya bermakna pada satu pautan tempat ia terbentuk, dan VPN berpenghalaan bukanlah pautan itu. fe80::1 penghala jauh berada pada segmen LAN jauh; anda berada satu hop jauhnya pada segmen lain, dan IPv6 sama sekali tiada mekanisme untuk penghala memajukan paket link-local.
Awalan fe80 menerangkan skop, bukan julat
Link-local unicast ialah fe80::/10, dan sifat yang menentukan bukanlah nombor tetapi skop. Alamat itu sah hanya pada satu pautan, dan setiap antara muka membentuk satu daripada pengecamnya sendiri, sebab itulah dua mesin tidak berkaitan pada dua rangkaian tidak berkaitan boleh kedua-duanya menjawab fe80::1 tanpa sebarang pertembungan. Awalan itu pada dasarnya berkata “pada sesuatu pautan”; pautan itu sendiri datang daripada konteks.
Pada hos, konteks itu ialah zon, atau scope ID, yang anda tambah selepas tanda peratus: fe80::1%eth0 pada Linux, fe80::1%3 atau fe80::1%12 pada Windows dan dalam alat yang mendedahkan indeks antara muka. Kernel menyelesaikan alamat bersama indeks antara muka dan kemudian menghantar. Buang zon itu dan destinasi menjadi kabur, jadi tindanan tiada cara memilih segmen.
Mengapa terowong berpenghalaan tidak dapat menyampaikannya
VPN berpenghalaan ialah antara muka titik-ke-titik yang membawa alamatnya sendiri, biasanya /64 ruang IPv6 unique-local atau peribadi di dalam terowong. LAN jauh ialah pautan berasingan, dicapai oleh hujung terowong yang menghala dan memajukan bagi pihak anda. Itu dua segmen berbeza, jadi alamat daripada satu bukan destinasi sah pada yang lain.
Peraturan pemajuan itu jelas dalam standard, bukan keanehan klien anda: penghala tidak memajukan paket dengan sumber atau destinasi link-local. Itulah sebabnya paket mati walaupun jadual penghalaan kelihatan betul. Tambah laluan untuk fe80::/64 menuju terowong dan tindanan yang mematuhi sama ada menolaknya atau menerimanya lalu menggugurkan setiap paket yang sepadan: skop destinasi berkata “pautan ini sahaja”, dan antara muka keluar bukan pautan itu.
Penemuan jiran mengukuhkan sempadan yang sama. Hos menyelesaikan hop seterusnya link-local dengan permintaan jiran yang dihantar ke multicast berskop pautan dengan had hop 255, jadi penghala boleh menolak apa sahaja yang dimajukan. Menjadikannya berfungsi merentas terowong bermakna memproksi penemuan untuk segmen jauh, iaitu jambatan Layer 2 dengan topi berbeza.
Ada kegagalan kedua yang lebih senyap, dan ia memerangkap orang yang masih cuba memaksa laluan itu: zon. Zon apa pun yang anda taip secara setempat menamakan antara muka terowong, manakala alamat yang anda mahu terikat pada antara muka LAN jauh. Kedua-duanya tidak pernah sepadan, jadi paket tidak boleh dihalakan ke antara muka yang betul di hujung jauh.
Bagaimana kegagalan itu kelihatan dalam amalan
Output alat untuk kesilapan skop terbaca seperti ralat penghalaan atau firewall, dan itulah sebabnya orang menghabiskan sebelah petang pada lapisan yang salah.
| What you run | What you see | What it means |
|---|---|---|
| ping fe80::1 with no zone | Invalid argument on Linux, or a transmit failure on Windows | The stack cannot pick an interface for an ambiguous destination |
| ping -6 -I tun0 fe80::1 | Destination unreachable, or a silent timeout | The address is not on the tunnel link, so there is nothing on-link to answer |
| ssh user@fe80::1 after the tunnel is up | Hangs, then no route to host | The SYN never left the machine in a deliverable form; the server logs nothing |
| ip -6 neigh show dev tun0 | Empty table | No neighbor entry can exist for a link-local host that is not on this link |
| fe80::/64 inside AllowedIPs or route-ipv6 | Config accepted, traffic still dropped | The tunnel carried the packet; the receiving stack refused to forward it |
Baris ketiga paling banyak membuang masa, kerana klien ssh tanpa output kelihatan seperti masalah perkhidmatan yang mendengar. Jika anda ada apa-apa cara untuk masuk, semak bahagian jauh dan pastikan sama ada sshd terikat pada semua alamat atau hanya satu.
Gunakan alamat yang memang dimaksudkan untuk dihalakan
Untuk apa sahaja yang perlu anda capai melalui terowong, gunakan alamat yang diberikan kepada perkhidmatan untuk tujuan itu: alamat unicast global, atau alamat unique-local daripada fc00::/7, julat yang dikhaskan khusus untuk kes dalaman ini. Pastikan pendengar benar-benar mengikatnya, dan sahkan laluan balik serta mana-mana peraturan firewall hos.
Lihat hos jauh daripada meneka. ip -6 addr show menyenaraikan alamat yang wujud, dan ss -6 -ltn menyenaraikan apa yang didengar oleh daemon. Perkhidmatan yang terikat hanya pada fe80:: boleh dicapai hanya dari segmennya sendiri, yang biasanya merupakan lalai yang tiada siapa pilih dengan sengaja dan boleh diubah dengan persetujuan pentadbir.
Apabila perkhidmatan itu benar-benar tidak boleh diikat semula, naikkan jambatan ke lapisan aplikasi dan bukan lapisan rangkaian. Geganti pada hos jauh yang mendengar pada alamat boleh dihalakan dan bersambung ke alamat link-local menyelesaikan masalah tanpa melanjutkan mana-mana segmen:
socat TCP6-LISTEN:8080,bind=[fd00:1:2::10] TCP6:[fe80::1%eth0]:80Di sini zon berada di sebelah yang betul, pada hos yang benar-benar mempunyai eth0 pada pautan itu. Klien anda bercakap dengan fd00:1:2::10, yang dihalakan secara normal, dan geganti melakukan hop link-local secara setempat. Helah yang sama berkesan untuk UI web sesuatu perkakas atau BMC lama yang hanya mengiklankan alamat link-local.
Apabila penjambatan benar-benar jawapannya, dan apa yang perlu diperiksa
Sesetengah penggunaan memang memerlukan satu segmen dikongsi: peranti yang hanya bercakap penemuan link-local, perkakas yang bergantung pada multicast, makmal yang menghasilkan semula LAN rata. Itu masalah Layer 2 dan ia memerlukan jawapan Layer 2, seperti peranti tap yang dijambatkan ke antara muka jauh atau produk klien dengan mod jambatan yang jelas. Ia mengenakan trafik broadcast dan multicast yang melintasi terowong serta penemuan jiran yang mesti berfungsi dari hujung ke hujung.
Jangan hampiri ini dengan menambah fe80::/64 pada profil berpenghalaan. Itu menghasilkan keadaan terburuk: konfigurasi kelihatan siap, jadual penghalaan menunjukkan entri, dan setiap paket masih digugurkan di suatu tempat antara dua tindanan yang kedua-duanya berkelakuan betul.
Sahkan dengan antara muka, bukan dengan ping. ip -6 addr show tun0 memberitahu sama ada pautan terowong membentuk alamat link-local sendiri, dan ip -6 route get fe80::1%tun0 memberitahu apa yang kernel sebenarnya akan lakukan dengan destinasi berskop. Apabila kernel berkata destinasi tidak dapat dicapai pada antara muka itu, tiada tetapan terowong akan mengubahnya, dan inilah masanya berhenti menyunting profil.
Urutan pendek yang menyelesaikan persoalan:
- Baca alamat pada hos jauh dan perhatikan sama ada ia fe80:: atau awalan boleh dihalakan.
- Jika ia fe80::, ikat semula perkhidmatan, geganti pada hos itu, atau jambatkan segmen itu; jika ia boleh dihalakan, betulkan laluan, firewall atau alamat ikatan.
- Semak semula zon setiap kali anda menguji semula, kerana arahan yang disalin biasanya mengekalkan antara muka yang salah.