Mengapa penemuan tetangga IPv6 gagal melalui VPN yang dirutekan

Penemuan tetangga IPv6 milik sebuah tautan, dan terowongan yang dirutekan adalah batas antara dua tautan. Satu kalimat itu menjelaskan hampir setiap laporan tentang host jauh yang menjawab lewat alamat dan tidak dapat ditemukan dengan cara lain. Periksa cakupan alamat yang Anda uji sebelum memeriksa terowongan. Alamat lokal-tautan hanya bermakna pada tautannya sendiri, dan grup multicast node yang diminta dibatasi dengan cara yang sama. Keduanya tidak melintasi perute, sehingga ping ke alamat global bisa berhasil sementara penemuan untuk host yang sama gagal.

Cakupan datang sebelum konfigurasi

Permintaan dan pengumuman tetangga membawa batas lompatan 255 dan tidak diteruskan, menurut desain. Perute antara terowongan Anda dan LAN jauh meneruskan paket IPv6 dan tidak meneruskan pesan tetangga atas namanya. Jadi cache tetangga pada antarmuka terowongan berisi pasangan dan sedikit lagi, yang merupakan perilaku benar dan bukan cacat yang harus diperbaiki.

Alamat lokal-tautan seperti entri fe80:: juga dibatasi zona, dan teks yang sama dapat menunjuk host lain pada tautan lain. Menguji salah satunya dari sisi lain terowongan tidak membuktikan apa pun kecuali bahwa alamat itu ambigu.

Jebakannya adalah asumsi bahwa prefiks ada di tautan

Host yang percaya bahwa sebuah prefiks ada di tautan mengirim permintaan tetangga alih-alih menyerahkan paket ke perutenya, dan itu mencakup /64 yang dirutekan ke situs jauh. Ketika prefiks seperti itu tiba sebagai ada di tautan, host menanyakan tautan lokal tentang host yang tinggal di tempat lain, dan tidak ada yang menjawab. Rutekan sesuatu yang lebih kecil ke host jauh, atau akhiri prefiks di perute yang akan menjawab untuknya.

/128 untuk satu layanan adalah pengaturan yang paling tidak mengejutkan, dan itu menghapus ambiguitas sepenuhnya. Spesifikasi penemuan tetangga menjelaskan kumpulan pesan dan bendera ada-di-tautan yang memutuskannya.

Penjembatanan mengubah aturan dengan sengaja

Ketika terowongan membawa bingkai Ethernet, segmen jauh dan lokal menjadi satu tautan, multicast mencapai kedua sisi, dan penemuan tetangga berperilaku seperti pada switch. Konsekuensinya ikut datang: banjir broadcast dan multicast, deteksi alamat duplikat di seluruh jembatan, dan pengumuman perute yang merembes ke segmen yang seharusnya tidak melihatnya. Domain kegagalan kini juga mencakup dua situs. Tidak satu pun dari itu menentang penjembatanan, dan setiap poin adalah alasan untuk menjembatani dengan sengaja, bukan secara kebetulan.

Mengubah profil dari TUN ke TAP agar penemuan muncul adalah urutan operasi yang salah. Server, klien, dan rencana pengalamatan harus sepakat, dan klien seluler sama sekali tidak menawarkan antarmuka TAP, sehingga desain seperti itu berfungsi di laptop dan gagal di ponsel. Proksi dan relai tetangga adalah mekanisme terpisah dengan persyaratan sendiri, dan itu termasuk pengaturan terdokumentasi administrator jaringan, bukan pengaturan aplikasi.

Uji dengan alamat yang dipakai aplikasi

Konfirmasi rute dengan ip -6 route get, periksa entri tetangga dengan ip -6 neigh, lalu konfirmasi layanan melalui jalur yang dirutekan. DNS dan jalur kembali adalah pemeriksaan terpisah, dan entri tetangga yang sehat tidak membuktikan keduanya.

Jika aplikasi bersikeras pada tujuan lokal-tautan atau berbasis penemuan, itu percakapan desain dan bukan latihan penyetelan, karena tidak ada pengaturan klien yang membuat mekanisme terbatas tautan bekerja melintasi perute.

Catat desain mana yang Anda miliki

Catat apakah dirutekan atau dijembatani sebelum insiden, karena kedua penerapan menjawab pertanyaan ini secara berbeda dan insinyur jaga tidak seharusnya menyimpulkannya dari profil.

Membaca kumpulan pesan sekali menghilangkan godaan menjelaskan sifat cakupan tautan sebagai bug VPN, yang merupakan diagnosis salah termahal di bidang ini.