VPN üzərindən 169.254: ünvan heç vaxt marşrutlaşdırıla bilməzdi
Link-local təyinat tunelə çatmadan atılır, ona görə marşrut əlavə etmək yalnız nasazlığı genişləndirir. Subneti düzəltmək və körpü qurmaq arasında seçim edin.
Marşrutu əlavə edirsiniz, tunel qalxır, amma qarşı tərəfə ping yenə də “network unreachable” əvəzinə tam itki ilə ölür. Bu fərq vacibdir, çünki diqqəti marşrut cədvəlindən ünvanın özünə yönəldir. 169.254 təyinatı link-local-dır və onun əhatəsi dizayn gereyi ilk hopda bitir, səhv konfiqurasiya üzündən deyil.
Sonrakı qərar dardır və açıq şəkildə verilməlidir: server tərəfindəki subneti təmir etmək, yoxsa Layer 2 seqmentini genişləndirib ünvanı yenidən lokal mənaca mənalı etmək. Qalan hər şey, daha geniş marşrut əlavə etmək də daxil olmaqla, eyni nasazlığı daha çox təyinat üzərinə yaymaqdan başqa bir şey deyil.
Ünvan marşrutsuz deyil, marşrutlaşdırıla bilməzdir
IPv4 link-local ünvanları daha yaxşısı cavab vermədikdə özləri təyin edilir; Windows-dakı avtomatik özəl ünvanlama davranışının mənbəyi budur və digər sistemlərdə də buna bərabər ehtiyat variant var. Aralıq hər linkdə eyni vaxtda istifadə olunur və bunun işləməsinin səbəbi məhz budur: eyni seqmentdəki iki host heç bir əlaqələndirmə olmadan danışa bilər.
Elə bu xassə üzündən marşrutlaşdırıcı bu paketləri şəbəkələr arasında yönləndirməməlidir. Link-local təyinatına ünvanlanmış paketi qəbul edib başqa interfeysdən çıxarmaq qeyri-müəyyənlik yaradar, çünki göndərənin “lokal”ı ilə alanın “lokal”ı ayrı yerlərdir. Göndərənin hansını nəzərdə tutduğunu həll edəcək heç bir axtarış yoxdur. Yönləndirmə burada administratorun aça biləcəyi siyasət seçimi deyil; ünvan sinfi bunu istisna edir.
Buna görə də 169.254.1.10 ünvanını tunel vasitəsilə əlçatan kimi quran şlüz kerneldən ünvan formatının qadağan etdiyi bir şeyi etməsini xahiş edir. Paket uzaq hosta çatmadan çox əvvəl atılır və marşrutun heç bir dəqiqliyi bu nəticəni dəyişmir.
Tunel əhatə problemini niyə görünən edir
TUN interfeysi iki peer arasında IP paketləri daşıyır və arxasında ortaq seqment yoxdur. Nə yayım, nə qarşı tərəf üçün ARP, nə də link-local təyinatını link qatı ünvanına çevirə biləcək qonşu kəşfi var. Yönləndirməyə icazə verilsə belə, hansı peerin cavab verməli olduğunu öyrənmək üçün müştərinin yolu yoxdur.
Nə axtaracağınızı bildikdən sonra simptomlar dəqiq üst-üstə düşür. Marşrut cədvəldə var, ping əlçatmaz şəbəkə əvəzinə tam itki bildirir və qonşu cədvəli təyinat üçün natamam və ya uğursuz giriş göstərir. Tuneldə götürülən capture paketin çıxdığını göstərir, bu da insanları ünvan sinfinə deyil, uzaq ucuna baxmağa yönəldir.
Windows-da eyni kökdən olan ikinci, əlaqəsiz görünən simptom var: yalnız link-local ünvanı qalan adapterin istifadə oluna bilən şlüzü yoxdur, ona görə şəbəkə identifikasiyası bağlantını təsnif edə bilmir və firewall profili public üzərinə düşür. Tunel səbəb deyil; ünvan səbəbdir.
Üç sualla qərar verin
Subneti təmir etməklə linki körpüləmək arasındakı seçim üç şərtdən asılıdır və onlardan hər hansı biri konfiqurasiya faylını açmadan əvvəl qərarı verə bilər.
| Question | If yes | If no |
|---|---|---|
| Can the far-side host be given a routable address? | Change the host or fix DHCP and route normally | Continue to the next question |
| Does the device accept a static address at all? | Assign one from the site's real prefix | Bridging is the only remaining option |
| Can you accept broadcast crossing the tunnel? | A bridge is viable for a small segment | Replace the device or accept no remote access |
Əksər hallar birinci sualda dayanır. Link-local ünvan göstərən host adətən DHCP-nin cavab vermədiyini, kabelin və ya VLAN-ın səhv olduğunu, ya da kiminsə ünvanı əl ilə yazdığını bildirir. Bunu təmir etmək hər hansı tunel işindən ucuzdur və problemi bu bir müştəri üçün deyil, bütün gələcək müştərilər üçün aradan qaldırır. O, həm də saytda işləyən DHCP aralığı qoyur, hansı ki əslində istədiyiniz şeydir.
Nəyisə fərz etməzdən əvvəl server tərəfini yoxlayın. Hostda ip addr show və ip route, müştəridə isə arp -n və ya route print -4 işə salın ki, prefiksin ümumiyyətlə mövcud olduğunu, yoxsa yalnız köhnəlmiş girişin bunu iddia etdiyini görəsiniz.
Körpü doğru cavab olduqda nəyə başa gəlir
Fiziki adapteri TAP adapteri ilə körpüləmək uzaq müştərini yerli yayım domeninin bir hissəsi edir. Sonra yayım və qonşu kəşfi işləyir, link-local ünvan yenidən mənalı olur, çünki müştəri həqiqətən həmin linkə lokaldır.
Xərclər realdır və kimsə razılaşmadan əvvəl göstərilməlidir. Yayım trafiki tuneldən keçir, müştəri yalnız ehtiyac duyduğu xidmətlərə deyil, hər məqsəd üçün yerli seqmentə açılır və server artıq paketləri marşrutlaşdırmaq əvəzinə kadrları yönləndirməlidir. Bu, laboratoriya stendi və ya marşrutlaşdırıla bilən konfiqurasiya yolu olmayan cihaz üçün münasib güzəştdir, uzaq giriş üçün isə pis standartdır.
Körpü qurduqda hər iki yarım tələb olunur: serverdə körpü və müştəri profilində hansı təyinatların qarşı tərəfdə olduğunu bildirən marşrut. Tək körpü müştərini təxminlə buraxır, tək marşrut isə ünvan sinfini düzəldə bilmir.