Ping ke rakan tunnel IPv6 anda gagal? Semak alamat ::

Satu hujung tunnel IPv6 anda mengeping hujung yang lain, dan hanya satu arah sahaja yang menjawab. Antara muka hidup, laluan kelihatan betul, dan tiada apa dalam log yang menjelaskannya. Alamat yang anda tetapkan ialah alamat anycast penghala subnet, yang sama sekali bukan alamat hos, dan pada pautan dua titik hujung ia mempunyai tepat satu sasaran penghantaran: penghantar. Tiada nilai tamat masa yang membaikinya, kerana alamat itu tidak melakukan apa yang anda sangka.

Gejala yang menunjuk ke alamat itu

Setiap hos pada pautan menjawab kecuali yang pengecam antara mukanya semuanya sifar. Paket yang dialamatkan ke bentuk itu menurut takrif dihantar kepada penghala dalam subnet, jadi pada tunnel titik-ke-titik ia kembali ke mesin yang menghantarnya. Dari hujung jauh ini dibaca sebagai rakan yang tidak dapat dicapai; dari hujung dekat sebagai kesunyian. Tukar kepada pengecam lain dari awalan yang sama dan gejalanya hilang tanpa perubahan lain, dan itulah pengesahan yang perlu diperoleh sebelum menyentuh laluan.

Pengecam semua-sifar dikhaskan sebagai anycast

RFC 4291 mengekalkan pengecam antara muka semua-sifar sebagai alamat anycast penghala subnet, jadi /64 seperti 2001:db8:4a::/64 tidak mengandungi hos yang boleh digunakan di 2001:db8:4a::. Tempahan itu berbaloi: pengumuman penghala dan penemuan jiran menuju ke bentuk itu, dan penghala menjawab bagi awalan yang dilayaninya. Menetapkan nilai itu kepada hujung tunnel memberi peranan penghala kepada daun, dan sebab itulah tiada apa yang kembali. Mana-mana pengecam lain dalam awalan berfungsi sebagai hos, jadi pembaikannya biasanya satu digit.

Anggap tempahan itu sebagai peranan yang anda tidak berhak memegang dari hujung tunnel, bukan sebagai keanehan untuk dielakkan dengan laluan.

Tetapkan alamat hos dan halakan awalan

Pilih ::1 dan ::2 untuk kedua-dua hujung, tambah satu dengan ip -6 addr add 2001:db8:4a::2/64 dev tun0, kemudian halakan awalan jauh dan bukannya cuba mengalamatkannya. Laluan untuk 2001:db8:4a::/64 melalui tunnel menjadikan sisi jauh boleh dicapai; alamat sahaja hanya mengkonfigurasi antara muka tempatan.

Untuk tunnel penuh ada langkah ketiga, laluan lalai untuk unicast global melalui peranti, iaitu setara IPv6 bagi menghantar segala-galanya ke dalam tunnel. Tertinggal langkah ini dan IPv6 terus menggunakan pautan fizikal sementara IPv4 bergerak di dalam tunnel, jadi hos membocorkan trafik yang anda sangka terlindung. Sahkan dengan ip -6 route get 2001:4860:4860::8888 dan baca peranti mana yang dinamakannya dan bukannya menganggap jawapannya.

Multicast ditolak sebelum penghalaan

Android mengesahkan alamat dan laluan untuk VpnService.Builder melalui LinkAddress, dan pembina itu menolak multicast secara terus. Beri ia awalan multicast sebagai laluan dan hasilnya ialah kegagalan parameter LinkAddress yang buruk dan bukan laluan, iaitu jawapan pengesahan dan bukan jawapan rangkaian. Penolakan itu sepadan dengan medium: peranti tun titik-ke-titik tiada multicast lapisan pautan, jadi laluan kumpulan di atasnya tiada model penghantaran untuk dipasang. Alamat kumpulan dicipta dan digunakan oleh tindanan itu sendiri dan bukannya dikonfigurasi secara manual.

Alamat IPv6 all-nodes dan solicited-node tertakluk pada peraturan yang sama. Antara muka membawanya kerana tindanan meletakkannya di sana, bukan kerana dasar memaksudkannya.

Apa yang boleh dibawa oleh tunnel sebagai gantinya

penemuan multicast merentas tunnel memerlukan lapisan yang memahami keahlian kumpulan: jambatan TAP yang membentangkan segmen Ethernet, geganti peringkat aplikasi atau protokol penghalaan yang diberitahu secara jelas ke rakan mana untuk mereplikasi. Tiada satu pun itu wujud dalam model VpnService, di mana aplikasi membaca dan menulis paket dan tiada panggilan yang menyertai kumpulan untuk tunnel. Sama ada tambah komponen yang memahami kumpulan atau keluarkan keperluan itu dari reka bentuk.

Unicast, sebaliknya, tidak memerlukan apa-apa tambahan melebihi alamat dan laluan di atas, sebab itulah tunnel biasanya dijangka membawanya dan kemudian disalahkan apabila protokol penemuan gagal.

Tiga pemeriksaan sebelum anda menetapkan apa-apa

Sahkan alamat itu bukan bentuk anycast, sahkan ia bukan multicast, dan sahkan awalannya dihalakan dan bukan sekadar ditetapkan kepada peranti. Kemudian hantar ujian anda ke destinasi yang merupakan hos sebenar, kerana ping yang dihalakan ke alamat anycast mengukur penghantar dan tidak memberitahu apa-apa tentang laluan. Simpan ketiga-tiga pemeriksaan itu dalam rekod perubahan supaya penggunaan berikutnya tidak menemukannya semula.

Laluan yang tidak pernah dipasang oleh platform tidak boleh dinyahpepijat dengan menunggu lebih lama, dan alamat yang tidak pernah menjadi hos tidak boleh dibaiki dengan ping yang lebih baik.