IPv6 yerli keçid ünvanı VPN üzərində işləmir: fe80 niyə keçiddə dayanır

Tuneli qaldırır, mənbə interfeysi kimi tuneli göstərib fe80::1 ünvanına ping göndərir və cavab almırsınız. Bu, unutduğunuz qoruyucu divar qaydası deyil. Yerli keçid ünvanı yalnız formalaşdığı tək keçiddə məna daşıyır və yönləndirilən VPN həmin keçid deyil. Uzaq marşrutlaşdırıcının fe80::1 ünvanı uzaq LAN seqmentində yaşayır; siz isə bir atlama uzaqlıqda, başqa seqmentdəsiniz və IPv6-da marşrutlaşdırıcının yerli keçid paketlərini ümumiyyətlə yönləndirməsi üçün heç bir mexanizm yoxdur.

fe80 prefiksi aralığı deyil, əhatəni təsvir edir

Yerli keçid unikastı fe80::/10-dur və təyinedici xassə rəqəm deyil, əhatədir. Ünvan yalnız bir keçiddə etibarlıdır və hər interfeys onu öz identifikatorundan yaradır; buna görə bir-biri ilə əlaqəsiz iki şəbəkədəki əlaqəsiz iki maşın heç bir toqquşma olmadan eyni fe80::1 ünvanına cavab verə bilər. Prefiks mahiyyətcə “hansısa keçiddə” deməkdir; keçidin özü isə kontekstdən gəlir.

Hostda bu kontekst zonadır və ya faiz işarəsindən sonra əlavə etdiyiniz əhatə ID-sidir: Linuxda fe80::1%eth0, Windowsda və interfeys indekslərini göstərən alətlərdə fe80::1%3 və ya fe80::1%12. Nüvə ünvanı interfeys indeksi ilə birlikdə həll edir və sonra göndərir. Zonanı atsanız, təyinat qeyri-müəyyən olur və yığının seqment seçmək üçün heç bir yolu qalmır.

Yönləndirilən tunel niyə onu çatdıra bilmir

Yönləndirilən VPN öz ünvanlarını daşıyan nöqtədən-nöqtəyə interfeysdir, adətən tunelin içində unikal-yerli və ya özəl IPv6 fəzasının /64-ü. Uzaq LAN ayrı keçiddir və tunel son nöqtəsinin sizin adınıza yönləndirməsi və ötürməsi ilə əldə edilir. Bunlar iki fərqli seqmentdir, ona görə birinin ünvanı digərində etibarlı təyinat deyil.

Ötürmə qaydası müştərinizin qəribəliyi deyil, standartda açıq şəkildə yazılıb: marşrutlaşdırıcılar yerli keçid mənbəli və ya təyinatlı paketləri ötürmür. Buna görə marşrut cədvəli düzgün görünsə də paket məhv olur. Tunelə fe80::/64 üçün marşrut əlavə edin: standarta uyğun yığın ya onu rədd edir, ya qəbul edib hər uyğun paketi atır: təyinat əhatəsi “yalnız bu keçid” deyir və çıxış interfeysi həmin keçid deyil.

Qonşu kəşfi də eyni sərhədi gücləndirir. Hostlar yerli keçid növbəti atlamalarını 255 atlama limiti ilə keçid əhatəli multicast-a göndərilən qonşu sorğusu ilə həll edir, beləliklə marşrutlaşdırıcılar ötürülən hər şeyi rədd edə bilər. Bunun tunel üzərindən işləməsi uzaq seqment üçün kəşfin proksiləşdirilməsi deməkdir ki, bu da başqa papaq geyinmiş Layer 2 körpüsüdür.

Daha səssiz ikinci nasazlıq var və marşrutu zorla qurmağa çalışanları çaşdırır: zona. Lokal olaraq yazdığınız zona tunel interfeysini adlandırır, istədiyiniz ünvan isə uzaq LAN interfeysinə bağlıdır. İkisi heç vaxt uyğun gəlmir, ona görə paket uzaq tərəfdə düzgün interfeysə yönəldilə bilmir.

Nasazlıq praktikada necə görünür

Əhatə səhvi üçün alət çıxışı marşrut və ya qoruyucu divar xətası kimi oxunur; insanların bütün günü səhv qatda keçirməsinin səbəbi də elə budur.

Üçüncü sətir ən çox vaxt itirir, çünki çıxışı olmayan ssh müştərisi dinləmə xidmətinin problemi kimi görünür. Əgər içəri girmək üçün hər hansı yolunuz varsa, uzaq tərəfə baxın və sshd-nin bütün ünvanlara, yoxsa yalnız birinə bağlandığını yoxlayın.

Yönləndirilmək üçün nəzərdə tutulmuş ünvandan istifadə edin

Tunel vasitəsilə çatmalı olduğunuz hər şey üçün xidmətə bu məqsədlə verilmiş ünvandan istifadə edin: qlobal unikast ünvanı və ya fc00::/7-dən olan unikal-yerli ünvan, yəni məhz bu daxili hal üçün ayrılmış aralıqdan. Dinləyicinin həqiqətən onu bağladığını, qayıdış yolunu və host qoruyucu divar qaydasını yoxlayın.

Təxmin etmək əvəzinə uzaq hosta baxın. ip -6 addr show mövcud ünvanları, ss -6 -ltn isə demonun nəyi dinlədiyini göstərir. Yalnız fe80::-a bağlı xidmət yalnız öz seqmentindən əlçatandır; bu, adətən heç kimin qəsdən seçmədiyi standart haldır və administratorun razılığı ilə dəyişdirilə bilər.

Xidməti həqiqətən yenidən bağlamaq mümkün olmayanda, körpünü şəbəkə qatından tətbiq qatına qaldırın. Uzaq hostda yönləndirilə bilən ünvanda dinləyən və yerli keçid ünvanına qoşulan bir ötürücü, heç bir seqmenti genişlətmədən problemi həll edir:

socat TCP6-LISTEN:8080,bind=[fd00:1:2::10] TCP6:[fe80::1%eth0]:80

Burada zona düzgün tərəfdədir, həmin keçiddə həqiqətən eth0 olan hostda. Müştəriniz normal yönləndirilən fd00:1:2::10 ilə danışır və ötürücü yerli keçid atlamasını yerli edir. Eyni hiylə yalnız yerli keçid ünvanı elan edən cihaz veb interfeysi və ya köhnə BMC üçün də işləyir.

Körpü həqiqətən cavab olanda və nəyi yoxlamaq lazımdır

Bəzi yerləşdirmələr həqiqətən bir ümumi seqmentə ehtiyac duyur: yalnız yerli keçid kəşfi ilə danışan cihaz, multicastdan asılı olan cihaz, düz LAN-ı təkrarlayan laboratoriya. Bu, Layer 2 problemidir və Layer 2 cavabı tələb edir, məsələn uzaq interfeysə körpülənmiş tap cihazı və ya açıq körpü rejimi olan müştəri məhsulu. Bu, sizə tuneldən keçən yayım və multicast trafiki, üstəlik başdan-başa işləməli olan qonşu kəşfi bahasına başa gəlir.

Bunu yönləndirilən profilə fe80::/64 əlavə etməklə təxminən etməyə çalışmayın. Bu, mümkün olan ən pis vəziyyəti yaradır: konfiqurasiya bitmiş görünür, marşrut cədvəli giriş göstərir və hər paket hələ də hər ikisi düzgün davranan iki yığın arasında haradasa atılır.

Ping ilə deyil, interfeyslə yoxlayın. ip -6 addr show tun0 sizə tunel keçidinin öz yerli keçid ünvanını yaradıb-yaratmadığını, ip -6 route get fe80::1%tun0 isə nüvənin əhatəli təyinatla həqiqətən nə edəcəyini deyir. Nüvə həmin interfeysdə təyinatın əlçatmaz olduğunu deyəndə, heç bir tunel ayarı bunu dəyişməyəcək və profili redaktə etməyi dayandırmağın vaxtıdır.

Sualı həll edən qısa ardıcıllıq:

• Uzaq hostdakı ünvanı oxuyun və onun fe80:: yoxsa yönləndirilə bilən prefiks olduğunu qeyd edin.
• Əgər fe80::-dırsa, xidməti yenidən bağlayın, həmin hostda ötürücü qurun və ya seqmenti körpüləyin; yönləndirilə biləndirsə, marşrutu, qoruyucu divarı və ya bağlama ünvanını düzəldin.
• Hər dəfə yenidən sınaqdan keçirəndə zonanı yenidən yoxlayın, çünki kopyalanmış əmr adətən səhv interfeysi saxlayır.

Mənbələr: RFC 4291, IPv6 ünvanlaşdırma arxitekturası.