Den tunneladresse er en modpart, ikke et subnet du kan gennemse

Din klient opretter forbindelse og viser et adressepar, eller én adresse med en 255.255.255.255 maske, og den første reaktion er, at serveren har udleveret noget i stykker. Intet er i stykker: et tunnelinterface er et punkt-til-punkt-link, og masken beskriver den fjerne ende af netop dét link, ikke et område af naboer. At læse parret som lokal og modpart forklarer den mærkelige maske, værtsruten ved siden af og den manglende naboetabel. Det, som samme læsning ikke undskylder, er en adresseplan, der overlapper kontornetværket.

Hvorfor masken ser forkert ud på et tunnellink

På et Ethernet-interface siger en adresse og en maske to ting: denne vært ejer adressen, og alt inden for præfikset er en direkte nabo. Kernen udleder en rute på linket ud fra disse to fakta og opløser derefter linkadresser for de naboer, den mener er til stede. Et punkt-til-punkt-interface beholder ejerskabet og dropper naboerne, så den anden adresse på klientlinjen er den fjerne ende og ikke en anden vært på et delt segment. Der er ingen hardwareadressering, ingen opløsningstrafik og ingen broadcastdomæne at tilslutte sig, og derfor opfører interfacet sig som et rør med præcis én destination.

Det er også derfor, en værtsrute ved siden af en bred maske er normal her og ikke et symptom. Nåbarhed på dette link betyder én adresse, og kernen skriver præcis det ned. Læs de to adresser sammen, før du beslutter, at konfigurationen er forkert, fordi hver af dem alene ser ud som en fejl.

To topologier, to adresseformer

Den ældre punkt-til-punkt-topologi giver hver klient en lille blok og bruger de to midterste adresser, så masken ser ud som et fragment af et netværk i stedet for en pulje. Subnet-topologien uddeler en adresse fra puljen med puljens maske og kalder serverens tunneladresse for modparten. Begge giver et gyldigt link, og de adskiller sig kun i, hvilke adresser der optræder i profilen, og i den maske en bruger sandsynligvis vil sætte spørgsmålstegn ved.

Uanset hvilken række der passer til din klient, skal du læse modparten først, fordi den navngiver den fjerne ende og dermed forklarer masken. En profil, der kopieres mellem servere med forskellige topologier, vil vise den forkerte form til sit nye hjem, og den uoverensstemmelse forveksles let med en serverfejl.

Når puljen og kontornetværket kræver de samme bits

Fordi linket er routet, har puljen brug for et præfiks, der ikke findes nogen steder blandt de netværk, serveren kan nå. Del ét, og klienten har én enkelt rute for et område, der betyder to steder, og den rute, der blev installeret sidst, afgør, hvilket sted der vinder. Fejlen viser sig på klienten, selvom beslutningen bag den hører til adresseplanen. Det, brugerne rapporterer, er, at den lokale router forsvinder, når tunnelen kommer op, eller at kun nogle få kontorværter svarer.

Præfikser, der blot ligner hinanden, er et andet tilfælde, og at sammenligne oktetter med øjet er ikke en præfikssammenligning. Skriv begge op og tæl maskerede bits: 192.168.4.0/24 mod 192.168.6.0/24 stemmer overens til bit 22 og divergerer ved bit 23, fordi den tredje oktet læses 00000100 mod 00000110, så de to netværk er virkelig adskilte. Sæt 10.8.0.0/24 ved siden af et andet 10.8.0.0/24 og alle 24 maskerede bits stemmer overens, hvilket betyder, at én rute ikke kan udtrykke begge steder. Maskelængden afgør, hvor sammenligningen stopper, og det netværk, der installeres sidst, er det, der taber.

Hvad et routet link ikke kan levere

Broadcast og multicast rejser ikke over et routet link, og flere velkendte funktioner er bygget på dem. Browserlister, navneannonceringer og tjenesteopdagelse antager alle et delt segment, så en filserver kan svare på hver anmodning efter adresse og alligevel aldrig optræde på en liste. Navneopløsning, der afhænger af link-lokal broadcast, fejler af samme grund, og ingen profilændring ændrer, hvad tunnelen kan bære. Om det betyder noget, er et kravsspørgsmål og ikke et routingspørgsmål.

En klient, der virkelig har brug for de leverancer, kræver et broet interface, som bærer Ethernet-rammer og derfor beholder broadcastdomænet. Prisen er et mere støjende link, tabet af den rene adressering beskrevet ovenfor og en langt større fejlflade, når der opstår loops. Begrund kravet, før du skifter, og foretræk en navnetjeneste, der virker over routede links, når kravet kun handler om navne.

Læs interfacet, før du redigerer profilen

Spørg kernen, hvad den installerede, i stedet for hvad profilen ser ud til at sige. Adresseoutputtet viser den modpart, der forklarer masken, og ruteoutputtet viser, om der findes en vej til den. At køre begge mod tunnelinterfacet tager et øjeblik og afgør spørgsmålet.

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

Hvis de tre stemmer overens, gør profilen det, den blev konfigureret til, og det resterende problem ligger et andet sted. Skift kun topologi af en grund, der navngiver en manglende evne, fordi en ukendt maske ikke er en.