IPv6 qonşu aşkarlaması marşrutlaşdırılmış VPN vasitəsilə niyə işləmir

IPv6 qonşu aşkarlaması bir keçidə aiddir və marşrutlaşdırılmış tunel iki keçid arasında sərhəddir. Bu bir cümlə ünvanla cavab verən və başqa heç nə ilə tapılmayan uzaq host barədə demək olar ki, bütün məlumatları izah edir. Tuneli yoxlamazdan əvvəl sınaqdan keçirdiyiniz ünvanın əhatə dairəsini yoxlayın. Keçid-lokal ünvan yalnız öz keçidində məna daşıyır və tələb olunan qovşaq multicast qrupu da eyni şəkildə məhdudlaşdırılır. Heç biri marşrutlaşdırıcıdan keçmir, buna görə qlobal ünvana ping uğurlu ola bilər, halbuki eyni host üçün aşkarlama işləmir.

Əhatə dairəsi konfiqurasiyadan əvvəl gəlir

Qonşu sorğusu və reklamı 255 hop limiti daşıyır və dizayn üzrə yönləndirilmir. Tunelinizlə uzaq LAN arasındakı marşrutlaşdırıcı IPv6 paketlərini yönləndirir və qonşu mesajlarını onun adından ötürmür. Beləliklə, tunel interfeysindəki qonşu keşi yalnız həmsöhbəti və az başqa şey saxlayır; bu, düzəldilməli qüsur deyil, düzgün davranışdır.

fe80:: kimi keçid-lokal ünvan da zona ilə məhdudlaşır və eyni mətn fərqli keçiddə fərqli hostu bildirə bilər. Onu tunelin o biri tərəfindən sınamaq ünvanın qeyri-müəyyən olmasından başqa heç nə sübut etmir.

Tələ keçiddə olma fərziyyəsidir

Prefiksin keçiddə olduğuna inanan host paketi marşrutlaşdırıcısına vermək əvəzinə qonşu sorğusu göndərir və bura uzaq sahəyə marşrutlaşdırılmış /64 də daxildir. Belə prefiks keçiddə olan kimi gəldikdə, host yerli keçiddən başqa yerdə yaşayan hostu soruşur və heç nə cavab vermir. Uzaq hosta daha kiçik bir şey marşrutlaşdırın və ya prefiksi onun adından cavab verəcək marşrutlaşdırıcıda sonlandırın.

Tək xidmət üçün /128 ən az təəccübləndirən həlldir və qeyri-müəyyənliyi tamamilə aradan qaldırır. Qonşu aşkarlaması spesifikasiyası mesaj dəstini və bunu həll edən keçiddə olma bayrağını təsvir edir.

Körpü qaydaları qəsdən dəyişir

Tunel Ethernet çərçivələrini daşıdıqda, uzaq və yerli seqmentlər bir keçidə çevrilir, multicast hər iki tərəfə çatır və qonşu aşkarlaması kommutatorda olduğu kimi davranır. Nəticələr də onunla gəlir: yayım və multicast seli, körpü boyunca dublikat ünvan aşkarlaması və görməməli olan seqmentə sızan marşrutlaşdırıcı reklamları. Nasazlıq domeni də artıq iki sahəni əhatə edir. Bunların heç biri körpüyə qarşı arqument deyil və hər biri körpünü təsadüfən deyil, qəsdən qurmaq üçün səbəbdir.

Aşkarlamanı görünən etmək üçün profili TUN-dan TAP-a keçirmək əməliyyatların yanlış sırasıdır. Server, müştəri və ünvanlama planı razılaşmalıdır və mobil müştərilər ümumiyyətlə TAP interfeysi təklif etmir, buna görə belə dizayn noutbukda işləyir, telefonda isə uğursuz olur. Qonşu proksiləri və ötürücüləri öz tələbləri olan ayrı mexanizmlərdir və onlar tətbiqin parametrlərinə deyil, şəbəkə administratorunun sənədləşdirilmiş quruluşuna aiddir.

Tətbiqin istifadə etdiyi ünvanla sınayın

Marşrutu ip -6 route get ilə təsdiqləyin, qonşu qeydini ip -6 neigh ilə yoxlayın, sonra xidməti marşrutlaşdırılmış yol üzərindən təsdiqləyin. DNS və qayıdış yolu ayrı yoxlamalardır və sağlam qonşu qeydi onların heç birini sübut etmir.

Tətbiq keçid-lokal və ya aşkarlamaya əsaslanan təyinatda israrlıdırsa, bu tənzimləmə məşqi deyil, dizayn söhbətidir, çünki heç bir müştəri parametri keçidlə məhdud mexanizmi marşrutlaşdırıcı üzərindən işlək etmir.

Hansı dizayna sahib olduğunuzu yazın

Hadisədən əvvəl marşrutlaşdırılmış və ya körpülü olduğunu qeyd edin, çünki iki yerləşdirmə bu suallara fərqli cavab verir və növbə mühəndisi bunu profildən çıxarmamalıdır.

Mesaj dəstini bir dəfə oxumaq keçid əhatəsi xassəsini VPN xətası kimi izah etmək istəyini aradan qaldırır; bu, bu sahədə ən bahalı səhv diaqnozdur.