Dat tunneladres is een peer, geen subnet dat je kunt doorbladeren

Je client maakt verbinding en toont een adrespaar, of één adres met een 255.255.255.255 masker, en de eerste reactie is dat de server iets kapots heeft uitgegeven. Niets is kapot: een getunnelde interface is een point-to-point-verbinding, en het masker beschrijft het verre uiteinde van die ene verbinding, niet een reeks buren. Het paar als lokaal en peer lezen verklaart het vreemde masker, de hostroute ernaast en de ontbrekende buurtabel. Wat dezelfde lezing niet goedpraat, is een adresplan dat overlapt met het kantoornetwerk.

Waarom het masker op een tunnelverbinding verkeerd lijkt

Op een Ethernet-interface stellen een adres en een masker twee dingen: deze host bezit het adres, en alles binnen de prefix is een directe buur. De kernel leidt daaruit een route op de verbinding af en lost vervolgens linkadressen op voor de buren die hij aanwezig acht. Een point-to-point-interface houdt het eigendom en laat de buren vallen, dus het tweede adres op de clientregel is het verre uiteinde en niet een andere host op een gedeeld segment. Er is geen hardwareadressering, geen omzettingsverkeer en geen broadcastdomein om bij te horen, waardoor de interface zich gedraagt als een buis met precies één bestemming.

Daarom is een hostroute naast een breed masker hier normaal en geen symptoom. Bereikbaarheid op deze verbinding betekent één adres, en de kernel schrijft precies dat op. Lees de twee adressen samen voordat je besluit dat de configuratie verkeerd is, want elk ervan ziet er alleen al uit als een fout.

Twee topologieën, twee adresvormen

De oudere point-to-point-topologie geeft elke client een klein blok en gebruikt de twee middelste adressen, zodat het masker op een fragment van een netwerk lijkt in plaats van een pool. De subnettopologie deelt een adres uit de pool met het poolmasker en noemt het tunneladres van de server de peer. Beide leveren een geldige verbinding, en ze verschillen alleen in welke adressen in het profiel verschijnen en in het masker dat een gebruiker waarschijnlijk ter discussie stelt.

Welke rij ook bij je client past, lees eerst de peer, want die benoemt het verre uiteinde en verklaart daarmee het masker. Een profiel dat tussen servers met verschillende topologieën wordt gekopieerd, toont de verkeerde vorm voor zijn nieuwe thuis, en die discrepantie wordt gemakkelijk voor een serverfout aangezien.

Wanneer de pool en het kantoornetwerk dezelfde bits opeisen

Omdat de verbinding gerouteerd is, heeft de pool een prefix nodig die nergens voorkomt onder de netwerken die de server kan bereiken. Deel er één en de client houdt één route voor een bereik dat twee plaatsen betekent, en de laatst geïnstalleerde route bepaalt welke plaats wint. De storing openbaart zich op de client, hoewel de beslissing erachter bij het adresplan hoort. Wat gebruikers melden, is dat de lokale router verdwijnt zodra de tunnel omhoog komt, of dat slechts enkele kantoorhosts antwoorden.

Prefixen die alleen op elkaar lijken zijn een ander geval, en octetten met het oog vergelijken is geen prefixvergelijking. Schrijf beide op en tel de gemaskeerde bits: 192.168.4.0/24 tegen 192.168.6.0/24 komen overeen tot bit 22 en divergeren bij bit 23, omdat het derde octet wordt gelezen als 00000100 tegen 00000110, dus die twee netwerken zijn echt gescheiden. Zet 10.8.0.0/24 naast een ander 10.8.0.0/24 en alle 24 gemaskeerde bits komen overeen, wat betekent dat één route niet beide plaatsen kan uitdrukken. De maskerlengte bepaalt waar de vergelijking stopt, en het netwerk dat als tweede is geïnstalleerd, is degene die verliest.

Wat een gerouteerde verbinding niet kan leveren

Broadcast en multicast reizen niet over een gerouteerde verbinding, en verschillende bekende functies zijn erop gebouwd. Browserslijsten, naamaankondigingen en servicedetectie gaan allemaal uit van een gedeeld segment, zodat een bestandsserver elk verzoek op adres kan beantwoorden en toch nooit in een lijst verschijnt. Naamresolutie die van link-lokale broadcast afhangt, mislukt om dezelfde reden, en geen profielwijziging verandert wat de tunnel kan dragen. Of dat belangrijk is, is een vereistenkwestie en geen routeringskwestie.

Een client die die leveringen echt nodig heeft, vereist een overbrugde interface, die Ethernet-frames draagt en daardoor het broadcastdomein behoudt. De prijs is een luidruchtiger verbinding, het verlies van de hierboven beschreven schone adressering en een veel groter storingsvlak zodra lussen optreden. Rechtvaardig de eis voordat je wisselt, en geef de voorkeur aan een naamdienst die over gerouteerde verbindingen werkt wanneer de eis alleen over namen gaat.

De interface lezen voordat je het profiel bewerkt

Vraag de kernel wat hij heeft geïnstalleerd, niet wat het profiel lijkt te zeggen. De adresuitvoer toont de peer die het masker verklaart, en de routeuitvoer toont of er een pad ernaartoe bestaat. Beide tegen het tunnelapparaat laten lopen kost een moment en beslecht de vraag.

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

Als die drie overeenkomen, doet het profiel waarvoor het is geconfigureerd, en het resterende probleem ligt elders. Wijzig de topologie alleen om een reden die een ontbrekende mogelijkheid noemt, want een onbekend masker is dat niet.