Diese Tunneladresse ist ein Peer, kein Subnetz, das man durchsuchen kann

Dein Client baut eine Verbindung auf und zeigt ein Adresspaar oder eine einzelne Adresse mit einer 255.255.255.255-Maske, und die erste Reaktion ist, dass der Server etwas Kaputtes ausgegeben hat. Nichts ist kaputt: Eine getunnelte Schnittstelle ist eine Punkt-zu-Punkt-Strecke, und die Maske beschreibt das ferne Ende dieser einen Strecke, nicht einen Bereich von Nachbarn. Das Paar als lokal und Peer zu lesen erklärt die seltsame Maske, die Host-Route daneben und die fehlende Nachbartabelle. Was dieselbe Lesart nicht entschuldigt, ist ein Adressplan, der sich mit dem Büronetz überschneidet.

Warum die Maske auf einer Tunnelstrecke falsch aussieht

Auf einer Ethernet-Schnittstelle sagen eine Adresse und eine Maske zwei Dinge: Dieser Host besitzt die Adresse, und alles innerhalb des Präfixes ist ein direkter Nachbar. Der Kernel leitet aus diesen beiden Tatsachen eine Route auf der Strecke ab und löst dann Verbindungsadressen für die Nachbarn auf, die er für vorhanden hält. Eine Punkt-zu-Punkt-Schnittstelle behält den Besitz und lässt die Nachbarn fallen, deshalb ist die zweite Adresse in der Client-Zeile das ferne Ende und nicht ein weiterer Host auf einem gemeinsamen Segment. Es gibt keine Hardwareadressierung, keinen Auflösungsverkehr und keine Broadcast-Domäne, der man beitreten könnte, weshalb sich die Schnittstelle wie ein Rohr mit genau einem Ziel verhält.

Das ist auch der Grund, warum eine Host-Route neben einer breiten Maske hier normal ist und kein Symptom. Erreichbarkeit auf dieser Strecke bedeutet eine Adresse, und der Kernel schreibt genau das auf. Lies die beiden Adressen zusammen, bevor du entscheidest, dass die Konfiguration falsch ist, denn jede von ihnen allein sieht wie ein Fehler aus.

Zwei Topologien, zwei Adressformen

Die ältere Punkt-zu-Punkt-Topologie gibt jedem Client einen kleinen Block und verwendet die beiden mittleren Adressen, weshalb die Maske wie ein Ausschnitt eines Netzes und nicht wie ein Pool aussieht. Die Subnetz-Topologie vergibt eine Adresse aus dem Pool mit der Pool-Maske und nennt die Tunneladresse des Servers den Peer. Beide ergeben eine gültige Strecke, und sie unterscheiden sich nur darin, welche Adressen im Profil erscheinen und welche Maske ein Benutzer wahrscheinlich hinterfragt.

Welche Zeile auch zu deinem Client passt, lies zuerst den Peer, denn er benennt das ferne Ende und erklärt damit die Maske. Ein Profil, das zwischen Servern mit unterschiedlichen Topologien kopiert wird, zeigt für sein neues Zuhause die falsche Form, und diese Diskrepanz wird leicht für einen Serverfehler gehalten.

Wenn der Pool und das Büronetz dieselben Bits beanspruchen

Weil die Strecke geroutet ist, braucht der Pool ein Präfix, das nirgends unter den Netzen vorkommt, die der Server erreichen kann. Teile eines, und der Client hält eine einzige Route für einen Bereich, der zwei Orte bedeutet, und die zuletzt installierte Route entscheidet, welcher Ort gewinnt. Der Fehler zeigt sich beim Client, obwohl die Entscheidung dahinter zum Adressplan gehört. Was Benutzer melden, ist ein verschwindender lokaler Router, sobald der Tunnel hochkommt, oder dass nur einige Büro-Hosts antworten.

Präfixe, die nur ähnlich aussehen, sind ein anderer Fall, und Oktette mit dem Auge zu vergleichen ist kein Präfixvergleich. Schreib beide auf und zähle die maskierten Bits: 192.168.4.0/24 gegen 192.168.6.0/24 stimmen bis Bit 22 überein und weichen bei Bit 23 ab, weil das dritte Oktett als 00000100 gegen 00000110 gelesen wird, also sind diese beiden Netze wirklich getrennt. Setze 10.8.0.0/24 neben ein weiteres 10.8.0.0/24 und alle 24 maskierten Bits stimmen überein, was bedeutet, dass eine Route nicht beide Orte ausdrücken kann. Die Maskenlänge entscheidet, wo der Vergleich endet, und das zuletzt installierte Netz ist das, welches verliert.

Was eine geroutete Strecke nicht liefern kann

Broadcast und Multicast reisen nicht über eine geroutete Strecke, und mehrere vertraute Funktionen bauen darauf. Browsing-Listen, Namensankündigungen und Diensterkennung setzen alle ein gemeinsames Segment voraus, sodass ein Dateiserver jede Anfrage per Adresse beantworten und trotzdem nie in einer Liste erscheinen kann. Namensauflösung, die auf Link-Local-Broadcast angewiesen ist, scheitert aus demselben Grund, und keine Profiländerung ändert, was der Tunnel tragen kann. Ob das wichtig ist, ist eine Frage der Anforderungen und nicht des Routings.

Ein Client, der diese Zustellungen wirklich braucht, erfordert eine gebrückte Schnittstelle, die Ethernet-Frames trägt und damit die Broadcast-Domäne behält. Der Preis ist eine lautere Strecke, der Verlust der oben beschriebenen sauberen Adressierung und eine viel größere Fehlerfläche, sobald Schleifen auftreten. Begründe die Anforderung, bevor du wechselst, und bevorzuge einen Namensdienst, der über geroutete Strecken funktioniert, wenn die Anforderung nur Namen betrifft.

Die Schnittstelle lesen, bevor du das Profil bearbeitest

Frag den Kernel, was er installiert hat, statt was das Profil zu sagen scheint. Die Adressausgabe zeigt den Peer, der die Maske erklärt, und die Routenausgabe zeigt, ob ein Weg dorthin existiert. Beides gegen das Tunnelgerät laufen zu lassen dauert einen Moment und klärt die Frage.

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

Wenn diese drei übereinstimmen, tut das Profil, wofür es konfiguriert wurde, und das verbleibende Problem liegt anderswo. Ändere die Topologie nur aus einem Grund, der eine fehlende Fähigkeit benennt, denn eine unbekannte Maske ist keiner.