Den tunneladressen är en motpart, inte ett subnät du kan bläddra i

Din klient ansluter och visar ett adresspar, eller en enda adress med en 255.255.255.255 mask, och den första reaktionen är att servern har lämnat ut något trasigt. Inget är trasigt: ett tunnelgränssnitt är en punkt-till-punkt-länk, och masken beskriver den bortre änden av just den länken, inte ett område av grannar. Att läsa paret som lokal och motpart förklarar den märkliga masken, värdrutten bredvid och den saknade grannatabellen. Vad samma läsning inte ursäktar är en adressplan som överlappar kontorsnätet.

Varför masken ser fel ut på en tunnellänk

På ett Ethernet-gränssnitt säger en adress och en mask två saker: den här värden äger adressen, och allt inom prefixet är en direkt granne. Kärnan härleder en rutt på länken från dessa två fakta och löser sedan länkadresser för de grannar som den anser är närvarande. Ett punkt-till-punkt-gränssnitt behåller ägandet och släpper grannarna, så den andra adressen på klientraden är den bortre änden och inte en annan värd på ett delat segment. Det finns ingen hårdvaruadressering, ingen upplösningstrafik och ingen broadcastdomän att gå med i, och därför beter sig gränssnittet som ett rör med exakt en destination.

Det är också skälet till att en värdrutt bredvid en bred mask är normalt här och inte ett symptom. Nåbarhet på den här länken betyder en adress, och kärnan skriver ned precis det. Läs de två adresserna tillsammans innan du avgör att konfigurationen är fel, eftersom var och en för sig ser ut som ett fel.

Två topologier, två adressformer

Den äldre punkt-till-punkt-topologin ger varje klient ett litet block och använder de två mittersta adresserna, så masken ser ut som en fragment av ett nätverk och inte som en pool. Subnätstopologin delar ut en adress ur poolen med poolens mask och kallar serverns tunneladress för motparten. Båda ger en giltig länk, och de skiljer sig bara i vilka adresser som syns i profilen och i den mask en användare sannolikt ifrågasätter.

Vilken rad som än passar din klient, läs motparten först, eftersom den namnger den bortre änden och därmed förklarar masken. En profil som kopieras mellan servrar med olika topologier visar fel form för sitt nya hem, och den avvikelsen förväxlas lätt med ett serverfel.

När poolen och kontorsnätet kräver samma bitar

Eftersom länken är routad behöver poolen ett prefix som inte finns någonstans bland de nätverk servern kan nå. Dela ett och klienten håller en enda rutt för ett område som betyder två platser, och den rutt som installerades sist avgör vilken plats som vinner. Felet visar sig på klienten även om beslutet bakom tillhör adressplanen. Det användare rapporterar är att den lokala routern försvinner när tunneln kommer upp, eller att bara några få kontorsvärdar svarar.

Prefix som bara ser lika ut är ett annat fall, och att jämföra oktetter med ögat är ingen prefixjämförelse. Skriv upp båda och räkna de maskerade bitarna: 192.168.4.0/24 mot 192.168.6.0/24 stämmer till bit 22 och divergerar vid bit 23, eftersom den tredje oktetten läses som 00000100 mot 00000110, så de två näten är verkligen åtskilda. Sätt 10.8.0.0/24 bredvid ett annat 10.8.0.0/24 och alla 24 maskerade bitar stämmer, vilket betyder att en rutt inte kan uttrycka båda platserna. Masklängden avgör var jämförelsen stannar, och nätet som installerades sist är det som förlorar.

Vad en routad länk inte kan leverera

Broadcast och multicast färdas inte över en routad länk, och flera bekanta funktioner bygger på dem. Bläddringslistor, namnannonseringar och tjänsteupptäckt förutsätter alla ett delat segment, så en filserver kan svara på varje begäran efter adress och ändå aldrig dyka upp i en lista. Namnupplösning som beror på länklokal broadcast misslyckas av samma skäl, och ingen profiländring ändrar vad tunneln kan bära. Om det spelar roll är en kravfråga och inte en routingfråga.

En klient som verkligen behöver de leveranserna kräver ett bryggat gränssnitt, som bär Ethernet-ramar och därför behåller broadcastdomänen. Priset är en bullrigare länk, förlusten av den rena adressering som beskrivs ovan och en mycket större felyta när loopar uppstår. Motivera kravet innan du byter, och föredra en namntjänst som fungerar över routade länkar när kravet bara gäller namn.

Att läsa gränssnittet innan du redigerar profilen

Fråga kärnan vad den installerade, i stället för vad profilen verkar säga. Adressutdata visar motparten som förklarar masken, och ruttutdata visar om det finns en väg till den. Att köra båda mot tunnelenheten tar ett ögonblick och avgör frågan.

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

Om dessa tre stämmer gör profilen det den konfigurerades för, och det återstående problemet ligger någon annanstans. Byt topologi bara av ett skäl som namnger en saknad förmåga, för en okänd mask är inte ett sådant.