Acea adresă de tunel este un partener, nu o subrețea pe care o poți răsfoi

Clientul tău se conectează și afișează o pereche de adrese, sau o singură adresă cu o 255.255.255.255 mască, iar prima reacție este că serverul a livrat ceva stricat. Nimic nu este stricat: o interfață tunelată este o legătură punct la punct, iar masca descrie capătul îndepărtat al acelei singure legături, nu un interval de vecini. Citirea perechii ca locală și partener explică masca ciudată, ruta către un singur host de lângă ea și tabela de vecini lipsă. Ce nu scuză aceeași citire este un plan de adrese care se suprapune peste rețeaua biroului.

De ce masca pare greșită pe o legătură de tunel

Pe o interfață Ethernet, o adresă și o mască afirmă două lucruri: acest host deține adresa, iar tot ce se află în prefix este un vecin direct. Nucleul derivă o rută pe legătură din aceste două fapte și apoi rezolvă adresele de legătură pentru vecinii pe care îi consideră prezenți. O interfață punct la punct păstrează proprietatea și renunță la vecini, așa că a doua adresă din linia clientului este capătul îndepărtat și nu un alt host într-un segment partajat. Nu există adresare hardware, trafic de rezolvare și nici un domeniu de difuzare la care să te alături, motiv pentru care interfața se comportă ca o conductă cu exact un singur destinatar.

De aceea o rută către un singur host lângă o mască largă este normală aici și nu un simptom. Accesibilitatea pe această legătură înseamnă o singură adresă, iar nucleul notează exact asta. Citește cele două adrese împreună înainte de a decide că configurația este greșită, pentru că fiecare singură pare o eroare.

Două topologii, două forme de adresă

Topologia punct la punct mai veche oferă fiecărui client un bloc mic și folosește cele două adrese din mijloc, așa că masca pare un fragment dintr-o rețea și nu un bazin. Topologia de subrețea oferă o adresă din bazin cu masca bazinului și numește adresa de tunel a serverului partenerul. Ambele produc o legătură validă și diferă doar prin adresele care apar în profil și prin masca pe care un utilizator o va pune probabil sub semnul întrebării.

Orice rând s-ar potrivi clientului tău, citește mai întâi partenerul, pentru că numește capătul îndepărtat și astfel explică masca. Un profil copiat între servere care folosesc topologii diferite va arăta forma greșită pentru noua sa casă, iar acea nepotrivire este ușor de confundat cu o defecțiune a serverului.

Când bazinul și rețeaua biroului revendică aceiași biți

Deoarece legătura este rutată, bazinul are nevoie de un prefix care nu apare nicăieri printre rețelele pe care serverul le poate atinge. Împarte unul și clientul ține o singură rută pentru un interval care înseamnă două locuri, iar ruta instalată ultima decide care loc câștigă. Defecțiunea se manifestă la client, deși decizia din spate aparține planului de adrese. Ce raportează utilizatorii este că routerul local dispare când tunelul urcă, sau că doar unii hosturi de birou răspund.

Prefixele care doar seamănă între ele sunt alt caz, iar compararea octeților din ochi nu este o comparație de prefixe. Scrie-le pe amândouă și numără biții mascați: 192.168.4.0/24 față de 192.168.6.0/24 se potrivesc până la bitul 22 și diverge la bitul 23, pentru că al treilea octet se citește ca 00000100 față de 00000110, deci acele două rețele sunt cu adevărat separate. Pune 10.8.0.0/24 lângă alt 10.8.0.0/24 și toți cei 24 de biți mascați se potrivesc, ceea ce înseamnă că o rută nu poate exprima ambele locuri. Lungimea măștii decide unde se oprește comparația, iar rețeaua instalată a doua este cea care pierde.

Ce nu poate livra o legătură rutată

Difuzarea și multicast nu călătoresc printr-o legătură rutată, iar mai multe funcții cunoscute se bazează pe ele. Listele de răsfoire, anunțurile de nume și descoperirea serviciilor presupun toate un segment partajat, așa că un server de fișiere poate răspunde fiecărei cereri după adresă și totuși să nu apară niciodată într-o listă. Rezolvarea numelor care depinde de difuzarea locală a legăturii eșuează din același motiv, iar nicio editare a profilului nu schimbă ce poate transporta tunelul. Dacă asta contează este o chestiune de cerințe, nu de rutare.

Un client care are într-adevăr nevoie de acele livrări cere o interfață punte, care transportă cadre Ethernet și deci păstrează domeniul de difuzare. Prețul este o legătură mai zgomotoasă, pierderea adresării curate descrise mai sus și o suprafață de defecțiune mult mai mare odată ce apar bucle. Justifică cerința înainte de a schimba și preferă un serviciu de nume care funcționează peste legături rutate când cerința se referă doar la nume.

Citirea interfeței înainte de a edita profilul

Întreabă nucleul ce a instalat, nu ce pare să spună profilul. Ieșirea adreselor arată partenerul care explică masca, iar ieșirea rutelor arată dacă există o cale către el. Rularea ambelor împotriva dispozitivului de tunel durează o clipă și lămurește întrebarea.

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

Dacă aceste trei se potrivesc, profilul face ceea ce a fost configurat să facă, iar problema rămasă este în altă parte. Schimbă topologia doar dintr-un motiv care numește o capacitate lipsă, pentru că o mască necunoscută nu este unul.