Klienten din kobler til og viser et adressepar, eller én adresse med en 255.255.255.255 maske, og den første reaksjonen er at serveren har levert noe ødelagt. Ingenting er ødelagt: et tunnelgrensesnitt er en punkt-til-punkt-forbindelse, og masken beskriver den fjerne enden av nettopp denne ene forbindelsen, ikke et område med naboer. Å lese paret som lokal og motpart forklarer den merkelige masken, vertsruten ved siden av og den manglende nabotabellen. Det samme lesningen ikke unnskylder, er en adresseplan som overlapper kontornettet.

Hvorfor masken ser feil ut på en tunnelforbindelse

På et Ethernet-grensesnitt sier en adresse og en maske to ting: denne verten eier adressen, og alt innenfor prefikset er en direkte nabo. Kjernen utleder en rute på forbindelsen fra disse to fakta og løser deretter opp lenkeadresser for naboene den mener er til stede. Et punkt-til-punkt-grensesnitt beholder eierskapet og dropper naboene, så den andre adressen på klientlinjen er den fjerne enden og ikke en annen vert på et delt segment. Det finnes ingen maskinvareadressering, ingen oppløsningstrafikk og ingen kringkastingsdomene å bli med i, og derfor oppfører grensesnittet seg som et rør med nøyaktig én destinasjon.

Det er også grunnen til at en vertsrute ved siden av en bred maske er normalt her og ikke et symptom. Rekkevidde på denne forbindelsen betyr én adresse, og kjernen skriver ned nøyaktig det. Les de to adressene sammen før du bestemmer deg for at konfigurasjonen er feil, fordi hver av dem alene ser ut som en feil.

To topologier, to adresseformer

Den eldre punkt-til-punkt-topologien gir hver klient en liten blokk og bruker de to midterste adressene, så masken ser ut som et fragment av et nettverk i stedet for en pool. Subnettopologien deler ut en adresse fra poolen med poolens maske og kaller serverens tunneladresse for motparten. Begge gir en gyldig forbindelse, og de skiller seg bare i hvilke adresser som vises i profilen og i masken en bruker sannsynligvis vil sette spørsmålstegn ved.

TopologyClient address shapePeerRoute to expect
Point-to-point block per clientTwo neighbouring addresses inside a small blockThe far address of that blockA single host route on the tunnel device
Shared poolOne address carrying the pool maskThe server's tunnel addressA single host route on the tunnel device

Uansett hvilken rad som passer klienten din, les motparten først, fordi den navngir den fjerne enden og dermed forklarer masken. En profil som kopieres mellom servere med forskjellige topologier, vil vise feil form for sitt nye hjem, og det avviket forveksles lett med en serverfeil.

Når poolen og kontornettet krever de samme bitene

Fordi forbindelsen er rutet, trenger poolen et prefiks som ikke finnes noe sted blant nettverkene serveren kan nå. Del ett, og klienten holder én enkelt rute for et område som betyr to steder, og ruten som ble installert sist avgjør hvilket sted som vinner. Feilen viser seg på klienten selv om beslutningen bak hører til adresseplanen. Det brukerne rapporterer, er at den lokale ruteren forsvinner når tunnelen kommer opp, eller at bare noen få kontorverter svarer.

Prefikser som bare ser like ut, er et annet tilfelle, og å sammenligne oktetter med øyet er ikke en prefikssammenligning. Skriv opp begge og tell de maskerte bitene: 192.168.4.0/24 mot 192.168.6.0/24 stemmer til bit 22 og divergerer ved bit 23, fordi den tredje oktetten leses som 00000100 mot 00000110, så de to nettverkene er virkelig atskilt. Sett 10.8.0.0/24 ved siden av et annet 10.8.0.0/24 og alle 24 maskerte bitene stemmer, noe som betyr at én rute ikke kan uttrykke begge stedene. Maskelengden avgjør hvor sammenligningen stopper, og nettverket som ble installert sist, er det som taper.

Hva en rutet forbindelse ikke kan levere

Kringkasting og multicast reiser ikke over en rutet forbindelse, og flere kjente funksjoner er bygget på dem. Bla gjennom-lister, navngivningsannonser og tjenesteoppdagelse forutsetter alle et delt segment, så en filserver kan svare på hver forespørsel etter adresse og likevel aldri dukke opp i en liste. Navneoppløsning som avhenger av link-lokal kringkasting feiler av samme grunn, og ingen profilendring endrer hva tunnelen kan bære. Om det betyr noe, er et kravsspørsmål og ikke et rutingsspørsmål.

En klient som virkelig trenger de leveransene, krever et broet grensesnitt, som bærer Ethernet-rammer og derfor beholder kringkastingsdomenet. Prisen er en mer støyende forbindelse, tapet av den rene adresseringen beskrevet ovenfor, og en mye større feilflate når løkker oppstår. Begrunn kravet før du bytter, og foretrekk en navnetjeneste som fungerer over rutede forbindelser når kravet bare gjelder navn.

Å lese grensesnittet før du redigerer profilen

Spør kjernen om hva den installerte, i stedet for hva profilen ser ut til å si. Adresseutdata viser motparten som forklarer masken, og ruteutdata viser om det finnes en vei til den. Å kjøre begge mot tunnelsenheten tar et øyeblikk og avgjør spørsmålet.

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

Hvis disse tre stemmer, gjør profilen det den ble konfigurert til, og det gjenværende problemet ligger et annet sted. Bytt topologi bare av en grunn som navngir en manglende evne, fordi en ukjent maske ikke er det.

Relaterte artikler