Den tunneladressa er ein motpart, ikkje eit subnett du kan bla gjennom
Maska på ei punkt-til-punkt-sambinding skildrar den fjerne enden, ikkje eit område med naboar. Les adressa til motparten før du avgjer at subnettet ser feil ut.
Klienten din koplar til og viser eit adressepar, eller éi adresse med ei 255.255.255.255 maske, og den første reaksjonen er at tenaren har levert noko øydelagt. Ingenting er øydelagt: eit tunnelgrensesnitt er ei punkt-til-punkt-sambinding, og maska skildrar den fjerne enden av nettopp denne eine sambindinga, ikkje eit område med naboar. Å lese paret som lokal og motpart forklarer den merkelege maska, vertsruta ved sida av og den manglande nabotabellen. Det same lesinga ikkje unnskuldar, er ein adresseplan som overlappar kontornettet.
Kvifor maska ser feil ut på ei tunnelsambinding
På eit Ethernet-grensesnitt seier ei adresse og ei maske to ting: denne verten eig adressa, og alt innanfor prefikset er ein direkte nabo. Kjernen leier ei rute på sambindinga ut frå desse to fakta og løyser deretter opp lenkjeadresser for naboane han meiner er til stades. Eit punkt-til-punkt-grensesnitt held på eigarskapen og slepp naboane, så den andre adressa på klientlinja er den fjerne enden og ikkje ein annan vert på eit delt segment. Det finst inga maskinvareadressering, ingen oppløysingstrafikk og ingen kringkastingsdomene å bli med i, og difor oppfører grensesnittet seg som eit røyr med nøyaktig éin destinasjon.
Det er også grunnen til at ei vertsrute ved sida av ei brei maske er normalt her og ikkje eit symptom. Rekkjevidde på denne sambindinga tyder éi adresse, og kjernen skriv ned nøyaktig det. Les dei to adressene saman før du avgjer at konfigurasjonen er feil, fordi kvar av dei åleine ser ut som ein feil.
To topologiar, to adresseformer
Den eldre punkt-til-punkt-topologien gir kvar klient ein liten blokk og brukar dei to midtre adressene, så maska ser ut som eit fragment av eit nettverk i staden for ein pool. Subnetttopologien deler ut ei adresse frå poolen med maska til poolen og kallar tunneladressa til tenaren motparten. Begge gir ei gyldig sambinding, og dei skil seg berre i kva adresser som blir viste i profilen og i maska ein brukar truleg vil setje spørsmålsteikn ved.
| 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 |
Uansett kva rad som passar klienten din, les motparten først, fordi han nemner den fjerne enden og dermed forklarer maska. Ein profil som blir kopiert mellom tenarar med ulike topologiar, vil vise feil form for sin nye heim, og det avviket blir lett forveksla med ein tenarfeil.
Når poolen og kontornettet krev dei same bitane
Fordi sambindinga er ruta, treng poolen eit prefiks som ikkje finst nokon stad blant nettverka tenaren kan nå. Del eitt, og klienten held éi einskild rute for eit område som tyder to stader, og ruta som vart installert sist avgjer kva stad som vinn. Feilen viser seg på klienten sjølv om avgjerda bak høyrer til adresseplanen. Det brukarane rapporterer, er at den lokale rutaren forsvinn når tunnelen kjem opp, eller at berre nokre få kontorvertar svarar.
Prefiks som berre ser like ut, er eit anna tilfelle, og å samanlikne oktettar med auget er ikkje ei prefikssamanlikning. Skriv opp begge og tel dei maskerte bitane: 192.168.4.0/24 mot 192.168.6.0/24 stemmer til bit 22 og divergerer ved bit 23, fordi den tredje oktetten blir lesen som 00000100 mot 00000110, så dei to nettverka er verkeleg åtskilde. Set 10.8.0.0/24 ved sida av eit anna 10.8.0.0/24 og alle 24 maskerte bitane stemmer, noko som tyder at éi rute ikkje kan uttrykkje begge stadene. Maskelengda avgjer kvar samanlikninga stoppar, og nettverket som vart installert sist, er det som tapar.
Kva ei ruta sambinding ikkje kan levere
Kringkasting og multicast reiser ikkje over ei ruta sambinding, og fleire kjende funksjonar er bygde på dei. Bla gjennom-lister, namngjevingsannonsar og tenesteoppdaging føreset alle eit delt segment, så ein filtenar kan svare på kvar førespurnad etter adresse og likevel aldri dukke opp i ei liste. Namneoppløysing som er avhengig av link-lokal kringkasting, feilar av same grunn, og inga profilendring endrar kva tunnelen kan bera. Om det tyder noko, er eit kravsspørsmål og ikkje eit rutingsspørsmål.
Ein klient som verkeleg treng dei leveransane, krev eit brua grensesnitt, som ber Ethernet-rammer og difor held på kringkastingsdomenet. Prisen er ei meir støyande sambinding, tapet av den reine adresseringa skildra ovanfor, og ei mykje større feilflate når løkker oppstår. Grunngje kravet før du byter, og føretrekk ein namneteneste som fungerer over ruta sambindingar når kravet berre gjeld namn.
Å lese grensesnittet før du redigerer profilen
Spør kjernen om kva han installerte, i staden for kva profilen ser ut til å seie. Adresseutdata viser motparten som forklarer maska, og ruteutdata viser om det finst ein veg til han. Å køyre begge mot tunnelininga tek eit augneblink og avgjer spørsmålet.
ip -4 addr show dev tun0
ip route show dev tun0
ip route get 10.8.0.1
Viss desse tre stemmer, gjer profilen det han vart konfigurert til, og det attverande problemet ligg ein annan stad. Bytt topologi berre av ein grunn som nemner ei manglande evne, fordi ei ukjend maske ikkje er det.