VPN-adaptern visar /32: det betyder inte en enda destination

Adaptrar visar 255.255.255.255, och slutsatsen blir ofta att VPN:et når exakt en adress. Den läsningen blandar ihop klientens egen adress med mängden destinationer som routas genom tunneln. På ett punkt-till-punkt- eller routat gränssnitt är de två olika objekt, och bara ett av dem begränsar nåbarheten. Myten lever kvar eftersom masken ser ut som subnätmasken folk lärde sig på Ethernet.

Myten: en värdmask betyder en enda nåbar värd

En /32-tilldelning talar om för gränssnittet vilken adress som hör till den här änden av länken, och på en punkt-till-punkt-länk är det allt den betyder. Partnerns adress är ett eget fält, och rutterna som säger vad som ligger bortom partnern är återigen egna. Ingenting i masken beskriver fjärrnätet, eftersom masken inte är platsen där fjärrnät beskrivs. Att läsa den som en nåbarhetsgräns är som att läsa sitt eget husnummer som en lista över alla adresser man får besöka.

Förvirringen har en verklig rot: på Ethernet skulle en värdmask verkligen betyda en enda adress på det segmentet. En tunnel är inte ett Ethernet-segment, och vad som går genom den avgörs av klientens routingtabell, inte av masken. Därför kan samma /32 stå framför ett helt datacenter.

Läs adressen och rutterna som separata objekt

Skriv ut gränssnittet och tabellen tillsammans och läs dem sedan som två svar på två frågor. Adressen svarar på vem den här änden är; rutterna svarar på vart trafiken får gå. En tredje fråga, vilka destinationer gatewayen tillåter, syns inte alls på klienten. Adressreferensen för iproute2 beskriver fälten för lokal adress, partner och prefixrutt var för sig just därför.

ip addr show tun0
ip route show
ip route get 10.60.5.10

I Windows finns samma uppdelning mellan adresslistan och routingtabellen, och uppslagskommandot är det snabbaste sättet att se vilken som vinner för en viss destination. Om uppslaget returnerar tunnelgränssnittet skickar klienten paketet dit. Om det returnerar den fysiska adaptern frågar klienten aldrig VPN:et, och ingen behörighet på serversidan ändrar det. Kontrollera den destination du faktiskt behöver, inte en generisk offentlig adress.

Get-NetIPAddress -InterfaceAlias "VPN"
Find-NetRoute -RemoteIPAddress 10.60.5.10

Stoppa om uppslaget pekar på fel gränssnitt. Det är ett routingproblem på klienten, och det rättas på klienten.

Varför en bredare mask oftast gör det värre

Att ändra tilldelningen till en /24 för att se ut som kontorets LAN kan skapa ett prefix på länken: kärnan tror nu att hela /24:et är direkt anslutet till tunnelgränssnittet. Trafik till adresser som borde routas genom gatewayen skickas då som om en granne fanns på länken. Resultatet är ett svart hål som ser ut som ett serverhaveri.

Det döljer också det egentliga problemet, nämligen en saknad rutt eller en saknad behörighet på gatewayen. Inget av dem skapas av en bredare mask, och båda överlever ändringen. Om designen behöver ett större prefix på gränssnittet är det ett beslut för den gränssnittsmodell som används, fattat med dokumentationen i handen. Att kopiera en mask från en annan produkts skärmbilder är inte det beslutet.

Om rutten för fjärrprefixet saknas, rätta till dess provisionering. Om den finns och anslutningen ändå avvisas var masken aldrig diagnosen.

När rutten är rätt och flödet ändå misslyckas

En korrekt rutt bevisar bara att klienten kommer att skicka paketet. Gatewayen måste fortfarande acceptera destinationen, returvägen måste finnas för den tilldelade adressen, och tjänsten måste tillåta flödet. Testa dessa tre var för sig: uppslaget på klienten, gatewayens tillåtna omfång och en begäran till en nödvändig server. Att autentiseringen lyckas innan alla tre är på plats är normalt, och därför kan en ansluten klient ändå inte nå något.

ping -c1 10.60.5.10
traceroute -n 10.60.5.10
curl -sv https://app.internal.example/ -o /dev/null

Håll nätverksobjekt och gruppbehörigheter hos sin ägare på en tjänst som styrs av en apparat. Vad klienten får veta att den ska nå och vad den får använda är olika inställningar, ofta på olika skärmar. Att ändra det ena och testa det andra är hur ett ärende studsar mellan två team.

Myten som bör pensioneras är att masken är en nåbarhetsgräns. Läs adressen, rutterna och gateway-policyn som tre separata fakta, och en /32 slutar se ut som en begränsning och börjar se ut som en normal tunneltilldelning.