Az az alagútcím egy partner, nem böngészhető alhálózat

Az ügyfél csatlakozik, és egy címpárt mutat, vagy egyetlen címet 255.255.255.255 maszkkal, és az első reakció, hogy a kiszolgáló valami töröttet adott. Semmi sem törött: az alagút-interfész pont-pont kapcsolat, és a maszk ennek az egy kapcsolatnak a távoli végét írja le, nem a szomszédok tartományát. A pár helyi címként és partnerként való olvasása megmagyarázza a furcsa maszkot, a mellette lévő egygazdás útvonalat és a hiányzó szomszédtáblát. Amit ugyanez az olvasat nem ment fel, az az irodai hálózattal átfedő címterv.

Miért tűnik hibásnak a maszk alagút-kapcsolaton

Ethernet-interfészen a cím és a maszk két dolgot állít: ez a gazdagép birtokolja a címet, és minden, ami az előtagon belül van, közvetlen szomszéd. A kernel ebből a két tényből származtatja a kapcsolat útvonalát, majd feloldja a kapcsolat címeit azokhoz a szomszédokhoz, amelyeket jelenlévőnek hisz. A pont-pont interfész megtartja a tulajdonjogot és elveti a szomszédokat, ezért az ügyfélsor második címe a távoli vég, nem pedig egy másik gazdagép egy megosztott szegmensen. Nincs hardveres címzés, nincs feloldási forgalom és nincs hirdetési tartomány, amihez csatlakozni lehetne, ezért az interfész pontosan egy célállomással rendelkező csőként viselkedik.

Ezért is normális itt egy egygazdás útvonal egy széles maszk mellett, és nem tünet. Az elérhetőség ezen a kapcsolaton egy címet jelent, és a kernel pontosan ezt írja le. Olvassa a két címet együtt mielőtt úgy döntene, hogy a konfiguráció hibás, mert mindegyik önmagában hibának látszik.

Két topológia, két címforma

A régebbi pont-pont topológia minden ügyfélnek kis blokkot ad, és a két középső címet használja, ezért a maszk egy hálózat töredékének tűnik, nem pedig egy készletnek. Az alhálózati topológia a készletből ad címet a készlet maszkjával, és a kiszolgáló alagút-címét nevezi partnernek. Mindkettő érvényes kapcsolatot hoz létre, és csak abban különböznek, mely címek jelennek meg a profilban, és milyen maszkot fog a felhasználó valószínűleg megkérdőjelezni.

Bármelyik sor is illik az ügyféléhez, először a partnert olvassa, mert az nevezi meg a távoli véget, és ezért magyarázza a maszkot. A különböző topológiájú kiszolgálók között másolt profil rossz formát mutat új otthonához, és ezt az eltérést könnyű kiszolgálóhibának nézni.

Amikor a készlet és az irodai hálózat ugyanazokat a biteket igényli

Mivel a kapcsolat útvonalválasztott, a készletnek olyan előtagra van szüksége, amely a kiszolgáló által elérhető hálózatok egyikében sem fordul elő. Osszon meg egyet, és az ügyfél egyetlen útvonalat tart egy tartományhoz, amely két helyet jelent, és hogy melyik hely nyer, azt a legutóbb telepített útvonal dönti el. A hiba az ügyfélen jelenik meg, pedig a mögötte lévő döntés a címtervhez tartozik. A felhasználók azt jelentik, hogy a helyi útválasztó eltűnik, amikor az alagút felmegy, vagy hogy csak néhány irodai gazdagép válaszol.

A csak hasonlónak látszó előtagok más eset, és az oktettek szemrevételezéses összehasonlítása nem előtag-összehasonlítás. Írja fel mindkettőt, és számolja meg a maszkolt biteket: 192.168.4.0/24 szemben 192.168.6.0/24 a 22-es bitig egyeznek, és a 23-as bitnél elválnak, mert a harmadik oktett így olvasandó: 00000100 szemben 00000110, tehát az a két hálózat valóban különálló. Tegye 10.8.0.0/24 mellé egy másik 10.8.0.0/24 értéket, és mind a 24 maszkolt bit egyezik, ami azt jelenti, hogy egy útvonal nem tudja kifejezni mindkét helyet. A maszk hossza dönti el, hol áll meg az összehasonlítás, és a másodikként telepített hálózat az, amelyik veszít.

Mit nem tud szállítani egy útvonalválasztott kapcsolat

A hirdetés és a multicast nem halad át útvonalválasztott kapcsolaton, és több ismert funkció ezekre épül. A böngészési listák, a névbejelentések és a szolgáltatásfelderítés mind megosztott szegmenst feltételeznek, ezért egy fájlkiszolgáló minden kérésre válaszolhat cím szerint, és mégsem jelenik meg soha egy listán. A kapcsolat helyi hirdetésétől függő névfeloldás ugyanezen okból hiúsul meg, és semmilyen profil szerkesztése nem változtat azon, mit képes az alagút szállítani. Hogy ez számít-e, követelménykérdés, nem útvonalválasztási kérdés.

Az az ügyfél, amelynek valóban szüksége van ezekre a szállításokra, áthidalt interfészt igényel, amely Ethernet-kereteket szállít, és ezért megtartja a hirdetési tartományt. Az ár a zajosabb kapcsolat, a fent leírt tiszta címzés elvesztése és sokkal nagyobb hiba felület, amint hurkok jelennek meg. Indokolja meg a követelményt a váltás előtt, és részesítse előnyben az útvonalválasztott kapcsolatokon működő névszolgáltatást, ha a követelmény csak a nevekről szól.

Az interfész olvasása a profil szerkesztése előtt

Kérdezze meg a kernelt, mit telepített, ne azt, amit a profil mondani látszik. A címkimenet mutatja a partnert, amely megmagyarázza a maszkot, az útvonalkimenet pedig azt, hogy létezik-e út hozzá. Mindkettő futtatása az alagút-eszköz ellen egy pillanatot vesz igénybe, és eldönti a kérdést.

ip -4 addr show dev tun0
ip route show dev tun0
ip route get 10.8.0.1

Ha ez a három egyezik, a profil azt teszi, amire konfigurálták, és a fennmaradó probléma máshol van. Csak olyan okból változtasson topológiát, amely megnevez egy hiányzó képességet, mert az ismeretlen maszk nem ilyen.