Tá adresa tunela je partner, nie podsieť, ktorú si môžete prezerať
Maska na spoji bod-bod opisuje vzdialený koniec, nie rozsah susedov. Prečítajte si adresu partnera, kým usúdite, že podsieť vyzerá zle.
Váš klient sa pripojí a zobrazí dvojicu adries, alebo jednu adresu s 255.255.255.255 maskou, a prvou reakciou je, že server vydal niečo pokazené. Nič nie je pokazené: tunelové rozhranie je spoj bod-bod a maska opisuje vzdialený koniec tohto jediného spoja, nie rozsah susedov. Čítanie dvojice ako lokálnej adresy a partnera vysvetľuje zvláštnu masku, trasu na jeden host vedľa nej aj chýbajúcu tabuľku susedov. Čo to isté čítanie neospravedlňuje, je plán adries, ktorý sa prekrýva s kancelárskou sieťou.
Prečo maska na tunelovom spoji vyzerá zle
Na rozhraní Ethernet adresa a maska tvrdia dve veci: tento host vlastní adresu a všetko vnútri prefixu je priamy sused. Jadro z týchto dvoch faktov odvodí trasu na spoji a potom prekladá adresy spoja pre susedov, ktorých považuje za prítomných. Rozhranie bod-bod si vlastníctvo ponechá a susedov zahodí, takže druhá adresa v klientskom riadku je vzdialený koniec, nie ďalší host v zdieľanom segmente. Neexistuje hardvérové adresovanie, prevádzka prekladu ani broadcastová doména, ku ktorej sa pripojiť, a preto sa rozhranie správa ako rúra s presne jedným cieľom.
Preto je trasa na jeden host vedľa širokej masky tu normálna, nie príznak. Dostupnosť na tomto spoji znamená jednu adresu a jadro zapisuje práve to. Prečítajte obe adresy spolu skôr, než usúdite, že konfigurácia je zlá, pretože každá sama vyzerá ako chyba.
Dve topológie, dva tvary adresy
Staršia topológia bod-bod dáva každému klientovi malý blok a používa dve stredné adresy, takže maska vyzerá ako zlomok siete, nie ako fond. Topológia podsiete vydáva adresu z fondu s maskou fondu a tunelovú adresu servera nazýva partnerom. Obe vytvoria platný spoj a líšia sa len tým, ktoré adresy sa objavia v profile a akú masku používateľ pravdepodobne spochybní.
| 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 |
Nech klientovi zodpovedá ktorýkoľvek riadok, prečítajte najprv partnera, pretože pomenúva vzdialený koniec, a tým vysvetľuje masku. Profil skopírovaný medzi servermi s rôznymi topológiami ukáže pre svoj nový domov nesprávny tvar a tento nesúlad sa ľahko zamení za poruchu servera.
Keď si fond a kancelárska sieť nárokujú rovnaké bity
Keďže spoj je rutovaný, fond potrebuje prefix, ktorý sa nevyskytuje v žiadnej zo sietí, ku ktorým sa server dostane. Zdieľajte jeden a klient drží jedinú trasu pre rozsah, ktorý znamená dve miesta, a o tom, ktoré miesto vyhrá, rozhoduje naposledy nainštalovaná trasa. Porucha sa prejaví u klienta, hoci rozhodnutie za ňou patrí plánu adries. Používatelia hlásia, že miestny router zmizne, keď tunel naskočí, alebo že odpovedá len časť kancelárskych hostov.
Prefixy, ktoré len vyzerajú podobne, sú iný prípad, a porovnávať oktety od oka nie je porovnanie prefixov. Vypíšte oba a spočítajte maskované bity: 192.168.4.0/24 proti 192.168.6.0/24 sa zhodujú do bitu 22 a rozchádzajú sa na bite 23, pretože tretí oktet sa číta ako 00000100 proti 00000110, takže tie dve siete sú skutočne oddelené. Položte 10.8.0.0/24 vedľa ďalšej 10.8.0.0/24 a všetkých 24 maskovaných bitov sa zhoduje, čo znamená, že jedna trasa nemôže vyjadriť obe miesta. Dĺžka masky rozhoduje, kde porovnanie končí, a sieť nainštalovaná druhá je tá, ktorá prehráva.
Čo rutovaný spoj nedokáže doručiť
Broadcast a multicast neprechádzajú cez rutovaný spoj a viacero známych funkcií je na nich postavených. Zoznamy na prehliadanie, oznámenia mien a objavovanie služieb predpokladajú zdieľaný segment, takže súborový server môže odpovedať na každú požiadavku podľa adresy a napriek tomu sa nikdy neobjaví v zozname. Preklad mien závislý od broadcastu lokálneho spoja zlyháva z rovnakého dôvodu a žiadna úprava profilu nemení, čo tunel dokáže preniesť. Či na tom záleží, je otázka požiadaviek, nie rutovania.
Klient, ktorý tieto dodávky naozaj potrebuje, vyžaduje mostové rozhranie, ktoré prenáša Ethernetové rámce, a preto zachováva broadcastovú doménu. Cenou je hlučnejší spoj, strata čistého adresovania opísaného vyššie a oveľa väčšia plocha porúch, keď sa objavia slučky. Zdôvodnite požiadavku pred prepnutím a uprednostnite mennú službu, ktorá funguje cez rutované spoje, keď sa požiadavka týka len mien.
Čítanie rozhrania pred úpravou profilu
Spýtajte sa jadra, čo nainštalovalo, nie čo profil zjavne hovorí. Výstup adries ukazuje partnera, ktorý vysvetľuje masku, a výstup trás ukazuje, či k nemu vedie cesta. Spustenie oboch proti tunelovému zariadeniu zaberie chvíľu a otázku vyrieši.
ip -4 addr show dev tun0
ip route show dev tun0
ip route get 10.8.0.1
Ak sa tie tri zhodujú, profil robí to, na čo bol nakonfigurovaný, a zvyšný problém je inde. Meňte topológiu len z dôvodu, ktorý pomenuje chýbajúcu schopnosť, pretože neznáma maska taká nie je.