Mengapa penemuan jiran IPv6 gagal merentas VPN yang dihalakan

Penemuan jiran IPv6 tergolong dalam satu pautan, dan terowong yang dihalakan ialah sempadan antara dua pautan. Satu ayat itu menjelaskan hampir setiap laporan tentang hos jauh yang menjawab melalui alamat dan tidak dapat ditemui dengan apa-apa cara lain. Semak skop alamat yang anda uji sebelum menyemak terowong. Alamat setempat-pautan hanya bermakna pada pautannya sendiri, dan kumpulan multicast nod yang diminta dihadkan dengan cara yang sama. Kedua-duanya tidak melintasi penghala, sebab itu ping ke alamat global boleh berjaya sementara penemuan untuk hos yang sama gagal.

Skop mendahului konfigurasi

Permintaan dan pengumuman jiran membawa had lompatan 255 dan tidak dimajukan, mengikut reka bentuk. Penghala antara terowong anda dan LAN jauh memajukan paket IPv6 dan tidak menyampaikan semula mesej jiran bagi pihaknya. Jadi cache jiran pada antara muka terowong mengandungi rakan dan sedikit sahaja, yang merupakan tingkah laku betul dan bukan kecacatan untuk dibaiki.

Alamat setempat-pautan seperti entri fe80:: juga terhad kepada zon, dan teks yang sama boleh menamakan hos lain pada pautan lain. Menguji satu daripadanya dari sebelah sana terowong tidak membuktikan apa-apa kecuali alamat itu kabur.

Perangkapnya ialah andaian bahawa awalan berada pada pautan

Hos yang percaya sesuatu awalan berada pada pautan menghantar permintaan jiran dan bukannya menyerahkan paket kepada penghalanya, dan itu termasuk /64 yang dihalakan ke tapak jauh. Apabila awalan sedemikian tiba sebagai berada pada pautan, hos itu bertanya kepada pautan setempat tentang hos yang tinggal di tempat lain, dan tiada apa yang menjawab. Halakan sesuatu yang lebih kecil ke hos jauh, atau tamatkan awalan pada penghala yang akan menjawab bagi pihaknya.

/128 untuk satu perkhidmatan ialah susunan yang paling tidak mengejutkan, dan ia menghapuskan kekaburan sepenuhnya. Spesifikasi penemuan jiran menerangkan set mesej dan bendera di-pautan yang menentukannya.

Penjambatan mengubah peraturan dengan sengaja

Apabila terowong membawa bingkai Ethernet, segmen jauh dan setempat menjadi satu pautan, multicast sampai ke kedua-dua belah, dan penemuan jiran berkelakuan seperti pada suis. Akibatnya datang bersama: banjir siaran dan multicast, pengesanan alamat pendua merentas jambatan, dan pengumuman penghala yang meresap ke segmen yang tidak sepatutnya melihatnya. Domain kegagalan kini merangkumi dua tapak juga. Tiada satu pun daripada itu menyokong penghujahan menentang penjambatan, dan setiap perkara ialah sebab untuk menjambatkan dengan sengaja dan bukan secara kebetulan.

Menukar profil daripada TUN kepada TAP supaya penemuan muncul ialah urutan operasi yang salah. Pelayan, klien dan pelan pengalamatan semuanya mesti bersetuju, dan klien mudah alih tidak menawarkan antara muka TAP langsung, jadi reka bentuk sedemikian berfungsi pada komputer riba dan gagal pada telefon. Proksi dan geganti jiran ialah mekanisme berasingan dengan keperluan sendiri, dan ia tergolong dalam susunan terdokumentasi pentadbir rangkaian dan bukan tetapan sesebuah aplikasi.

Uji dengan alamat yang digunakan oleh aplikasi

Sahkan laluan dengan ip -6 route get, periksa entri jiran dengan ip -6 neigh, kemudian sahkan perkhidmatan melalui laluan yang dihalakan. DNS dan laluan pulang ialah pemeriksaan berasingan, dan entri jiran yang sihat tidak membuktikan kedua-duanya.

Jika aplikasi berkeras pada destinasi setempat-pautan atau berasaskan penemuan, itu perbualan reka bentuk dan bukan latihan penalaan, kerana tiada tetapan klien menjadikan mekanisme terhad-pautan berfungsi merentas penghala.

Catatkan reka bentuk mana yang anda ada

Catatkan sama ada ia dihalakan atau dijambatkan sebelum insiden, kerana kedua-dua penggunaan menjawab soalan ini secara berbeza dan jurutera bertugas tidak sepatutnya menyimpulkannya daripada profil.

Membaca set mesej sekali menghilangkan godaan untuk menjelaskan sifat skop-pautan sebagai pepijat VPN, yang merupakan diagnosis salah paling mahal dalam bidang ini.