Ping ke peer tunnel IPv6 Anda gagal? Periksa alamat ::

Satu ujung tunnel IPv6 Anda mem-ping ujung lain, dan hanya satu arah yang pernah menjawab. Antarmuka aktif, rute terlihat benar, dan tidak ada apa pun di log yang menjelaskannya. Alamat yang Anda tetapkan adalah alamat anycast router subnet, yang sama sekali bukan alamat host, dan pada tautan dua titik akhir ia punya tepat satu tujuan pengiriman: pengirim. Tidak ada nilai timeout yang memperbaikinya, karena alamat itu tidak melakukan apa yang Anda kira.

Gejala yang menunjuk ke alamat itu

Setiap host di tautan menjawab kecuali yang pengenal antarmukanya semua nol. Paket yang dialamatkan ke bentuk itu menurut definisi dikirimkan ke router di subnet, jadi pada tunnel titik-ke-titik ia kembali ke mesin yang mengirimnya. Dari ujung jauh ini terbaca sebagai peer yang tak terjangkau; dari ujung dekat terbaca sebagai kesunyian. Ganti dengan pengenal lain dari prefiks yang sama dan gejalanya hilang tanpa perubahan lain, dan itulah konfirmasi yang harus didapat sebelum menyentuh rute.

Pengenal semua-nol dicadangkan sebagai anycast

RFC 4291 menyimpan pengenal antarmuka semua-nol sebagai alamat anycast router subnet, jadi /64 seperti 2001:db8:4a::/64 tidak berisi host yang dapat dipakai di 2001:db8:4a::. Pencadangan itu pantas: pengumuman router dan penemuan tetangga mengalamatkan bentuk itu, dan router menjawab untuk prefiks yang dilayaninya. Menetapkan nilai itu ke ujung tunnel memberi peran router kepada daun, dan itulah sebabnya tidak ada yang kembali. Pengenal lain di prefiks itu bekerja sebagai host, jadi perbaikannya biasanya satu digit.

Perlakukan pencadangan itu sebagai peran yang tidak berhak Anda ambil dari ujung tunnel, bukan sebagai keanehan untuk diakali dengan rute.

Tetapkan alamat host dan rutekan prefiks

Pilih ::1 dan ::2 untuk kedua ujung, tambahkan satu dengan ip -6 addr add 2001:db8:4a::2/64 dev tun0, lalu rutekan prefiks jauh alih-alih mencoba mengalamatkannya. Rute untuk 2001:db8:4a::/64 keluar tunnel membuat sisi jauh dapat dijangkau; alamatnya saja hanya membuat antarmuka lokal terkonfigurasi.

Untuk tunnel penuh ada langkah ketiga, rute bawaan untuk unicast global melalui perangkat, yaitu padanan IPv6 dari mengirim semuanya ke tunnel. Lewatkan ini dan IPv6 tetap memakai tautan fisik sementara IPv4 berjalan di dalam tunnel, jadi host membocorkan tepat lalu lintas yang Anda yakini sudah tercakup. Konfirmasikan dengan ip -6 route get 2001:4860:4860::8888 dan baca perangkat mana yang disebutnya alih-alih menganggap jawabannya.

Multicast ditolak sebelum perutean

Android memvalidasi alamat dan rute untuk VpnService.Builder melalui LinkAddress, dan konstruktor itu menolak multicast mentah-mentah. Beri ia prefiks multicast sebagai rute dan hasilnya adalah kegagalan parameter LinkAddress yang buruk alih-alih rute, yang merupakan jawaban validasi dan bukan jawaban jaringan. Penolakan itu sesuai dengan mediumnya: perangkat tun titik-ke-titik tidak punya multicast lapisan tautan, jadi rute grup di atasnya tidak punya model pengiriman untuk dipasang. Alamat grup dibuat dan dikonsumsi oleh stack itu sendiri alih-alih dikonfigurasi dengan tangan.

Alamat IPv6 all-nodes dan solicited-node tunduk pada aturan yang sama. Antarmuka membawanya karena stack menaruhnya di sana, bukan karena kebijakan memaksudkannya.

Apa yang bisa dibawa tunnel sebagai gantinya

penemuan multicast melintasi tunnel memerlukan lapisan yang memahami keanggotaan grup: jembatan TAP yang menghadirkan segmen Ethernet, relai tingkat aplikasi, atau protokol perutean yang diberi tahu secara eksplisit ke peer mana harus mereplikasi. Tidak ada satu pun dari itu di model VpnService, tempat aplikasi membaca dan menulis paket dan tidak punya panggilan yang bergabung ke grup untuk tunnel. Entah tambahkan komponen yang memahami grup atau hapus persyaratan itu dari desain.

Unicast, sebaliknya, tidak memerlukan apa pun tambahan di luar alamat dan rute di atas, itulah sebabnya tunnel biasanya diharapkan membawanya lalu disalahkan ketika protokol penemuan gagal.

Tiga pemeriksaan sebelum Anda menetapkan apa pun

Pastikan alamat itu bukan bentuk anycast, pastikan itu bukan multicast, dan pastikan prefiksnya dirutekan dan bukan sekadar ditetapkan ke perangkat. Lalu kirim uji Anda ke tujuan yang merupakan host sungguhan, karena ping yang diarahkan ke alamat anycast mengukur pengirim dan tidak mengatakan apa pun tentang jalurnya. Simpan ketiga pemeriksaan itu di catatan perubahan agar penerapan berikutnya tidak menemukannya lagi.

Rute yang tidak pernah dipasang platform tidak dapat didebug dengan menunggu lebih lama, dan alamat yang tidak pernah menjadi host tidak dapat diperbaiki dengan ping yang lebih baik.