Ta adresa tunelu je protějšek, ne podsíť, kterou můžete procházet

Váš klient se připojí a zobrazí dvojici adres, nebo jednu adresu s maskou 255.255.255.255, a první reakce je, že server vydal něco rozbitého. Nic rozbité není: tunelové rozhraní je spoj bod-bod a maska popisuje vzdálený konec tohoto jediného spoje, nikoli rozsah sousedů. Čtení dvojice jako místní adresy a protějšku vysvětluje podivnou masku, routu na jeden host vedle ní i chybějící tabulku sousedů. Co stejné čtení neomlouvá, je plán adres, který se překrývá s kancelářskou sítí.

Proč maska na tunelovém spoji vypadá špatně

Na rozhraní Ethernet adresa a maska tvrdí dvě věci: tento host vlastní adresu a vše uvnitř prefixu je přímý soused. Jádro z těchto dvou faktů odvodí routu na spoji a poté překládá adresy spoje pro sousedy, které považuje za přítomné. Rozhraní bod-bod si vlastnictví ponechá a sousedy zahodí, takže druhá adresa na klientském řádku je vzdálený konec, ne další host ve sdíleném segmentu. Neexistuje hardwarové adresování, provoz překladu ani broadcastová doména, ke které by se dalo připojit, a proto se rozhraní chová jako trubka s přesně jedním cílem.

Proto je routa na jeden host vedle široké masky tady normální, ne příznak. Dostupnost na tomto spoji znamená jednu adresu a jádro zapisuje právě to. Přečtěte obě adresy společně než usoudíte, že je konfigurace špatná, protože každá sama vypadá jako chyba.

Dvě topologie, dva tvary adres

Starší topologie bod-bod dává každému klientovi malý blok a používá dvě prostřední adresy, takže maska vypadá jako zlomek sítě, ne jako fond. Topologie podsítě vydává adresu z fondu s maskou fondu a tunelovou adresu serveru nazývá protějškem. Obě vytvoří platný spoj a liší se jen tím, které adresy se objeví v profilu a jakou masku uživatel pravděpodobně zpochybní.

Ať vašemu klientovi odpovídá kterýkoli řádek, přečtěte nejdřív protějšek, protože pojmenovává vzdálený konec, a tím vysvětluje masku. Profil zkopírovaný mezi servery s různými topologiemi ukáže pro svůj nový domov špatný tvar a tento nesoulad se snadno zamění za závadu serveru.

Když si fond a kancelářská síť nárokují stejné bity

Protože je spoj routovaný, fond potřebuje prefix, který se nevyskytuje v žádné ze sítí, k nimž se server dostane. Sdílejte jeden a klient drží jedinou routu pro rozsah, který znamená dvě místa, a o tom, které místo vyhraje, rozhoduje naposledy nainstalovaná routa. Závada se projeví u klienta, i když rozhodnutí za ní patří plánu adres. Uživatelé hlásí, že místní router zmizí, když tunel naskočí, nebo že odpovídá jen část kancelářských hostů.

Prefixy, které jen vypadají podobně, jsou jiný případ, a porovnávat oktety od oka není porovnání prefixů. Vypište oba a spočítejte maskované bity: 192.168.4.0/24 proti 192.168.6.0/24 se shodují do bitu 22 a rozcházejí se na bitu 23, protože třetí oktet se čte 00000100 proti 00000110, takže ty dvě sítě jsou skutečně oddělené. Položte 10.8.0.0/24 vedle další 10.8.0.0/24 a všech 24 maskovaných bitů se shoduje, což znamená, že jedna routa nemůže vyjádřit obě místa. Délka masky rozhoduje, kde porovnání končí, a síť nainstalovaná druhá je ta, která prohrává.

Co routovaný spoj nedokáže doručit

Broadcast a multicast nepřecházejí přes routovaný spoj a řada známých funkcí je na nich postavená. Seznamy pro procházení, oznámení jmen a objevování služeb předpokládají sdílený segment, takže souborový server může odpovědět na každý požadavek podle adresy a přesto se nikdy v seznamu neobjeví. Překlad jmen závislý na broadcastu lokálního spoje selhává ze stejného důvodu a žádná úprava profilu nezmění, co tunel umí přenést. Zda na tom záleží, je otázka požadavků, ne routování.

Klient, který tyto dodávky skutečně potřebuje, vyžaduje mostové rozhraní, jež přenáší Ethernetové rámce, a proto zachovává broadcastovou doménu. Cenou je hlučnější spoj, ztráta čistého adresování popsaného výše a mnohem větší plocha poruch, jakmile se objeví smyčky. Zdůvodněte požadavek před přepnutím a dejte přednost jmenné službě, která funguje přes routované spoje, když se požadavek týká jen jmen.

Čtení rozhraní před úpravou profilu

Ptejte se jádra, co nainstalovalo, ne co profil zdánlivě říká. Výstup adres ukazuje protějšek, který vysvětluje masku, a výstup rout ukazuje, zda k němu vede cesta. Spuštění obou proti tunelovému zařízení zabere chvilku a otázku vyřeší.

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

Pokud se ty tři shodují, profil dělá to, pro co byl nakonfigurován, a zbývající problém je jinde. Měňte topologii jen z důvodu, který pojmenuje chybějící schopnost, protože neznámá maska taková není.