Bu tunel ünvanı qarşı tərəfdir, nəzərdən keçirə biləcəyiniz subnet deyil
Nöqtədən-nöqtəyə linkdə maska qonşular diapazonunu deyil, uzaq ucu təsvir edir. Subnetin səhv göründüyünə qərar verməzdən əvvəl qarşı tərəfin ünvanını oxuyun.
Klientiniz qoşulur və ünvan cütü, ya da bir ünvan 255.255.255.255 maskası ilə göstərir, və ilk reaksiya serverin nəyisə sınıq verdiyi olur. Heç nə sınıq deyil: tunel interfeysi nöqtədən-nöqtəyə linkdir və maska qonşular diapazonunu deyil, həmin bir linkin uzaq ucunu təsvir edir. Cütü yerli və qarşı tərəf kimi oxumaq qəribə maskanı, onun yanındakı tək host marşrutunu və olmayan qonşu cədvəlini izah edir. Eyni oxu bağışlamadığı şey ofis şəbəkəsi ilə üst-üstə düşən ünvan planıdır.
Maska niyə tunel linkində səhv görünür
Ethernet interfeysində ünvan və maska iki şeyi bildirir: bu host ünvana sahibdir və prefiks daxilindəki hər şey birbaşa qonşudur. Nüvə bu iki faktdan link üzərində marşrut çıxarır, sonra mövcud olduğunu güman etdiyi qonşular üçün link ünvanlarını həll edir. Nöqtədən-nöqtəyə interfeys sahibliyi saxlayır və qonşuları atır, buna görə klient sətrindəki ikinci ünvan ortaq seqmentdəki başqa host deyil, uzaq ucdur. Nə aparat ünvanlaması, nə həll trafiki, nə də qoşulacaq yayım domeni var; buna görə interfeys tam bir təyinatı olan boru kimi davranır.
Geniş maskanın yanında host marşrutunun burada simptom deyil, normal olmasının səbəbi də budur. Bu linkdə əlçatanlıq bir ünvan deməkdir və nüvə də məhz onu yazır. İki ünvanı birlikdə oxuyun konfiqurasiyanın səhv olduğuna qərar verməzdən əvvəl, çünki hər biri təkbaşına səhv kimi görünür.
İki topologiya, iki ünvan forması
Köhnə nöqtədən-nöqtəyə topologiyası hər klientə kiçik blok verir və iki orta ünvandan istifadə edir, buna görə maska hovuz deyil, şəbəkənin bir parçası kimi görünür. Subnet topologiyası hovuzdan hovuz maskası ilə ünvan paylayır və serverin tunel ünvanını qarşı tərəf adlandırır. Hər ikisi etibarlı link yaradır və onlar yalnız profildə hansı ünvanların görünməsi və istifadəçinin şübhə edəcəyi maska ilə fərqlənir.
| Topology | Client address shape | Peer | Route to expect |
|---|---|---|---|
| Point-to-point block per client | Two neighbouring addresses inside a small block | The far address of that block | A single host route on the tunnel device |
| Shared pool | One address carrying the pool mask | The server's tunnel address | A single host route on the tunnel device |
Hansı sətir klientinizə uyğun gəlirsə, əvvəlcə qarşı tərəfi oxuyun, çünki o, uzaq ucu adlandırır və buna görə maskanı izah edir. Fərqli topologiyalar işlədən serverlər arasında kopyalanan profil yeni evi üçün səhv forma göstərəcək və bu uyğunsuzluq asanlıqla server nasazlığı ilə səhv salınır.
Hovuz və ofis şəbəkəsi eyni bitləri tələb etdikdə
Link marşrutlaşdırıldığı üçün hovuza serverin çata bildiyi şəbəkələrin heç birində görünməyən prefiks lazımdır. Birini paylaşsanız, klient iki yer demək olan diapazon üçün tək marşrut saxlayır və hansı yerin qalib gəldiyini ən son quraşdırılmış marşrut həll edir. Nasazlıq klientdə görünür, halbuki arxasındakı qərar ünvan planına aiddir. İstifadəçilərin bildirdiyi, tunel qalxdıqda yerli marşrutizatorun yox olması, ya da yalnız bəzi ofis hostlarının cavab verməsidir.
Sadəcə oxşar görünən prefikslər başqa haldır və oktetləri gözlə müqayisə etmək prefiks müqayisəsi deyil. İkisini də yazın və maskalanmış bitləri sayın: 192.168.4.0/24 ilə 192.168.6.0/24 bit 22-yə qədər uyğundur və bit 23-də ayrılır, çünki üçüncü oktet 00000100 ilə 00000110 kimi oxunur, buna görə bu iki şəbəkə həqiqətən ayrıdır. 10.8.0.0/24 ünvanını başqa bir 10.8.0.0/24-in yanına qoyun və bütün 24 maskalanmış bit uyğun gəlir, yəni bir marşrut hər iki yeri ifadə edə bilməz. Maska uzunluğu müqayisənin harada dayandığını müəyyən edir və ikinci quraşdırılan şəbəkə uduzur.
Marşrutlaşdırılmış link nəyi çatdıra bilməz
Yayım və multicast marşrutlaşdırılmış linkdən keçmir və bir çox tanış funksiya onların üzərində qurulub. Siyahılama siyahıları, ad elanları və xidmət kəşfi ortaq seqmenti güman edir, buna görə fayl serveri hər sorğuya ünvanla cavab verə və yenə də heç vaxt siyahıda görünməyə bilər. Link-lokal yayımdan asılı ad həlli də eyni səbəbdən uğursuz olur və heç bir profil düzəlişi tunelin nə daşıya biləcəyini dəyişmir. Bunun vacib olub-olmadığı marşrutlaşdırma deyil, tələblər məsələsidir.
Həmin çatdırmalara həqiqətən ehtiyacı olan klient körpülənmiş interfeys tələb edir, o, Ethernet çərçivələrini daşıyır və buna görə yayım domenini saxlayır. Qiyməti daha səs-küylü link, yuxarıda təsvir olunan təmiz ünvanlamanın itkisi və döngələr yarandıqdan sonra qat-qat böyük nasazlıq səthidir. Keçiddən əvvəl tələbi əsaslandırın və tələb yalnız adlara aid olduqda marşrutlaşdırılmış linklər üzərində işləyən ad xidmətinə üstünlük verin.
Profili redaktə etməzdən əvvəl interfeysi oxumaq
Nüvədən profilin dediyi görünəni deyil, nəyi quraşdırdığını soruşun. Ünvan çıxışı maskanı izah edən qarşı tərəfi göstərir, marşrut çıxışı isə ona yol olub-olmadığını göstərir. Hər ikisini tunel interfeysinə qarşı işlətmək bir an çəkir və məsələni həll edir.
ip -4 addr show dev tun0
ip route show dev tun0
ip route get 10.8.0.1Bu üçü uyğun gəlirsə, profil konfiqurasiya edildiyi işi görür və qalan problem başqa yerdədir. Topologiyanı yalnız çatışmayan imkanı adlandıran bir səbəblə dəyişin, çünki tanış olmayan maska belə bir səbəb deyil.