Ein VPN-Client mit LAN-Adresse ist nicht im LAN

Der Client verbindet sich, erhält 10.50.0.200 und erreicht den Server unter 10.50.0.20 nicht, obwohl beide Adressen im selben /24 liegen. Hinter dieser Konfiguration steht die Annahme, eine Adresse aus dem LAN-Präfix mache den Client zu einem Teil des LAN. Das ist nicht so. Der Client hängt an einer Punkt-zu-Punkt-Verbindung, der Server hält das Ziel für lokal, und das fehlende Stück ist eine Nachbarantwort, die niemand sendet.

Der Irrtum: gleiches Präfix bedeutet gleiches Segment

Ein Adresspräfix teilt einem Host mit, welche Ziele er direkt erreichen kann und welche einen Router benötigen. Es sagt dem Host nicht, wie das Ziel physisch angebunden ist, und es garantiert erst recht nicht, dass das Ziel eine Anfrage auf der Sicherungsschicht beantworten kann. Das sind verschiedene Fragen, die von verschiedenen Tabellen auf dem Host beantwortet werden. Die Maske beantwortet die erste, die Nachbartabelle die zweite, und nur die erste liegt aus Sicht des VPN in Ihrer Hand.

Wenn der Server an 10.50.0.200 sendet, vergleicht er das Ziel mit seiner eigenen Maske, hält die Adresse für on-link und fragt das lokale Segment nach der Hardwareadresse, die dazugehört. Diese Anfrage geht über die Ethernet-Schnittstelle hinaus, und der VPN-Client ist nicht dort, um sie zu hören.

Nichts in der Konfiguration des Clients kann das von seiner Seite aus beheben. Der Antwortpfad hängt davon ab, dass ein Gerät im LAN stellvertretend für den Client antwortet oder dass der Client eine Adresse hat, die der Server nicht für lokal hält.

Was der lokale Host mit der Adresse tatsächlich macht

Das Verhalten ist leicht zu beobachten und lohnt sich, bevor Sie etwas ändern. Schauen Sie auf einem LAN-Host nach dem Versuch, den Client zu erreichen, in die Nachbartabelle: ein unvollständiger oder fehlgeschlagener Eintrag ist die ganze Diagnose in einer Zeile. Diese Zeile sagt Ihnen außerdem, dass der Fehler im Segment liegt und nicht irgendwo im Tunnel.

ip neigh show 10.50.0.200
ip route get 10.50.0.200
arping -I eth0 -c 3 10.50.0.200

Die Routensuche wird das Ziel über die Ethernet-Schnittstelle als on-link melden, und genau das ist das Problem. Bleibt der Nachbareintrag unvollständig, während die VPN-Sitzung steht, haben Sie bestätigt, dass die fehlende Schicht die Auflösung auf der Sicherungsschicht ist und nicht Routing- oder Firewall-Politik.

Führen Sie dieselbe Prüfung von einem Host in einem anderen Subnetz aus und vergleichen Sie. Ein Host, der den Client über einen Router erreicht, braucht überhaupt keinen Nachbareintrag, und dieser Unterschied ist die Designentscheidung im Kleinen.

Wie Proxy ARP einen Next Hop liefert

Proxy ARP bringt das Gateway dazu, die Anfrage auf der Sicherungsschicht stellvertretend für ein Ziel zu beantworten, das es über eine andere Schnittstelle erreichen kann. Der LAN-Host erhält eine Hardwareadresse, schickt den Frame an das Gateway, und das Gateway leitet das Paket in die VPN-Sitzung weiter. Aus Sicht des Hosts sieht es einfach so aus, als läge der Client hinter dem Gateway. An der Konfiguration des Clients ändert sich nichts.

Die RouterOS-ARP-Dokumentation von MikroTik beschreibt diesen Einsatz für Einwahlclients, die den Adressraum des angeschlossenen LAN mitnutzen. Der Mechanismus ist eine Reparatur der Nachbarauflösung, und er funktioniert, weil das Gateway wirklich auf beiden Pfaden liegt.

Das ist nicht dasselbe, als würde man den Client in das LAN brücken. Das Gateway muss das Paket weiterhin an die richtige aktive Sitzung weiterleiten, und seine Routing- und Firewall-Politik muss den Dienst weiterhin erlauben. Proxy ARP ändert, wer die Nachbaranfrage beantwortet, nicht, wer sprechen darf.

Lesen Sie die Modusnamen der Plattform sorgfältig. RouterOS unterscheidet proxy-arp von local-proxy-arp, und der zweite behandelt Verkehr, der dieselbe Schnittstelle betritt und verlässt. Das sind keine austauschbaren Schreibweisen, und beide wahllos zu aktivieren ist keine Abkürzung.

Was Proxy ARP Ihnen nicht gibt

Es liefert keine Broadcast- oder Multicast-Erkennung. Ein Client, der einen Dienst per Broadcast finden muss, scheitert weiterhin, weil das Gateway Unicast in die Sitzung weiterleitet und den Client nicht zu einem Mitglied der Broadcast-Domäne des LAN macht. Erkennungsprotokolle, die auf Broadcast setzen, sind bei Designs mit geliehenen Adressen eine häufige Quelle für Meldungen, dass es bei dem einen funktioniert und bei dem anderen nicht.

Es reserviert die Adresse nicht. Steht die geliehene Nummer auch in einem DHCP-Pool oder in einer statischen Zuweisung, können zwei Geräte dieselbe Adresse erhalten, und das resultierende Verhalten hängt vom Timing ab. Eine erfolgreiche Anmeldung ist keine Reservierung.

Und es erspart Ihnen nicht die Abstimmung mit dem Eigentümer des LAN. Ein Proxy-ARP-Eintrag, der den Besitzer des Adressplans überrascht, ist ein Supportfall, der auf eine ruhige Woche wartet.

Vergleich mit einem separat gerouteten Pool

Die Alternative besteht darin, VPN-Clients ein eigenes Präfix zu geben und LAN-Hosts dorthin routen zu lassen. Der Server sendet dann Off-Link-Antworten an sein Gateway, das Gateway routet das Präfix zum VPN-Endpunkt, und auf dem LAN-Segment ist überhaupt keine Nachbarauflösung nötig. Das sind weniger bewegliche Teile als eine geliehene Adresse plus eine Proxy-Antwort.

Dieses Design ist leichter zu durchdenken und leichter zu prüfen, weil der Client-Bereich sichtbar vom LAN-Bereich getrennt ist. Es kostet eine Route, einen Rückweg und eine Zugriffsregel, also dieselben Dinge, die das Proxy-ARP-Design an einer weniger offensichtlichen Stelle braucht.

Wählen Sie zwischen den Modellen bewusst und nicht zufällig. Proxy ARP repariert eine bestimmte Beziehung; ein gerouteter Pool macht diese Reparatur überflüssig. Schreiben Sie auf, welches Sie gewählt haben und warum, dann muss es der Nächste nicht aus einem fehlgeschlagenen Nachbareintrag neu entdecken.