VPN-Adapter zeigt /32 – das bedeutet nicht ein einziges Ziel

Adapter zeigen 255.255.255.255, und oft lautet die Schlussfolgerung, das VPN erreiche genau eine Adresse. Diese Lesart verwechselt die eigene Adresse des Clients mit der Menge der über den Tunnel gerouteten Ziele. Auf einer Punkt-zu-Punkt- oder gerouteten Schnittstelle sind das zwei verschiedene Objekte, und nur eines davon begrenzt die Erreichbarkeit. Der Mythos hält sich, weil die Maske wie die Subnetzmaske aussieht, die man auf Ethernet gelernt hat.

Der Mythos: Eine Hostmaske bedeutet einen einzigen erreichbaren Host

Eine /32-Zuweisung teilt der Schnittstelle mit, welche Adresse zu diesem Ende der Strecke gehört, und auf einer Punkt-zu-Punkt-Strecke ist das alles, was sie bedeutet. Die Adresse des Gegenübers ist ein eigenes Feld, und die Routen, die sagen, was hinter dem Gegenüber liegt, sind wiederum eigenes. Nichts in der Maske beschreibt das entfernte Netz, denn die Maske ist nicht der Ort, an dem entfernte Netze beschrieben werden. Sie als Erreichbarkeitsgrenze zu lesen ist, als läse man die eigene Hausnummer als Liste aller Adressen, die man besuchen darf.

Die Verwechslung hat eine reale Wurzel: auf Ethernet würde eine Hostmaske tatsächlich eine einzige Adresse in diesem Segment bedeuten. Ein Tunnel ist kein Ethernet-Segment, und was durch ihn geht, entscheidet die Routing-Tabelle des Clients, nicht die Maske. Deshalb kann dieselbe /32 vor einem ganzen Rechenzentrum stehen.

Adresse und Routen als getrennte Objekte lesen

Geben Sie Schnittstelle und Tabelle gemeinsam aus und lesen Sie sie dann als zwei Antworten auf zwei Fragen. Die Adresse beantwortet, wer dieses Ende ist; die Routen beantworten, wohin der Verkehr darf. Eine dritte Frage, welche Ziele das Gateway erlaubt, ist am Client überhaupt nicht sichtbar. Die iproute2-Adressreferenz beschreibt die Felder für lokale Adresse, Gegenüber und Präfixroute genau deshalb getrennt.

ip addr show tun0
ip route show
ip route get 10.60.5.10

Unter Windows besteht dieselbe Trennung zwischen Adressliste und Routing-Tabelle, und der Suchbefehl ist der schnellste Weg zu sehen, welche für ein bestimmtes Ziel gewinnt. Liefert die Suche die Tunnelschnittstelle, schickt der Client das Paket dorthin. Liefert sie den physischen Adapter, fragt der Client das VPN nie, und keine serverseitige Berechtigung ändert das. Prüfen Sie das Ziel, das Sie tatsächlich brauchen, nicht eine beliebige öffentliche Adresse.

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

Halten Sie an, wenn die Suche auf die falsche Schnittstelle zeigt. Das ist ein Routing-Problem des Clients, und es wird am Client behoben.

Warum eine breitere Maske es meist schlimmer macht

Die Zuweisung auf eine /24 zu ändern, damit sie wie das Büro-LAN aussieht, kann ein On-Link-Präfix erzeugen: Der Kernel glaubt nun, das ganze /24 hänge direkt an der Tunnelschnittstelle. Verkehr zu Adressen, die über das Gateway geroutet werden müssten, wird dann gesendet, als sei ein Nachbar auf der Strecke. Das Ergebnis ist ein schwarzes Loch, das wie ein Serverausfall aussieht.

Es verdeckt auch das eigentliche Problem, nämlich eine fehlende Route oder eine fehlende Berechtigung am Gateway. Beides entsteht nicht durch eine breitere Maske, und beides überlebt die Änderung. Braucht das Design ein größeres Präfix auf der Schnittstelle, ist das eine Entscheidung für das verwendete Schnittstellenmodell, getroffen mit der Dokumentation in der Hand. Eine Maske aus Screenshots eines anderen Produkts zu kopieren ist diese Entscheidung nicht.

Fehlt die Route für das entfernte Präfix, korrigieren Sie deren Bereitstellung. Ist sie vorhanden und wird die Verbindung weiterhin abgelehnt, war die Maske nie die Diagnose.

Wenn die Route stimmt und der Fluss trotzdem scheitert

Eine korrekte Route beweist nur, dass der Client das Paket senden wird. Das Gateway muss das Ziel weiterhin annehmen, der Rückweg muss für die zugewiesene Adresse existieren, und der Dienst muss den Fluss erlauben. Prüfen Sie diese drei getrennt: die Suche am Client, den erlaubten Umfang des Gateways und eine Anfrage an einen benötigten Server. Dass die Anmeldung gelingt, bevor alle drei stehen, ist normal, und deshalb erreicht ein verbundener Client trotzdem nichts.

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

Halten Sie Netzobjekte und Gruppenberechtigungen bei ihrem Eigentümer in einem geräteverwalteten Dienst. Wohin der Client erreichen soll und was er benutzen darf, sind verschiedene Einstellungen, oft auf verschiedenen Bildschirmen. Das eine zu ändern und das andere zu testen ist der Weg, auf dem ein Ticket zwischen zwei Teams hin und her springt.

Der Mythos, der in Rente gehört, ist, dass die Maske eine Erreichbarkeitsgrenze sei. Lesen Sie Adresse, Routen und Gateway-Richtlinie als drei getrennte Fakten, und eine /32 sieht nicht mehr wie eine Einschränkung aus, sondern wie eine normale Tunnelzuweisung.