MikroTik: asymmetrisches Routing zwischen dem ISP und dem VPN vermeiden

Ein VPN-Tunnel und ein klassischer Internetzugang können auf einem MikroTik problemlos koexistieren. Die Schwierigkeit tritt auf, wenn ein Server des lokalen Netzwerks über die Adresse des Internetanbieters veröffentlicht wird, während eine Policy-Routing-Regel einen Teil des ausgehenden Datenverkehrs in das VPN leitet. Die Anfrage kommt zwar über den ISP an, aber die Antwort kann über den Tunnel zurückgehen. Der Client sieht dann zwei verschiedene Pfade, und die Verbindung schlägt fehl.

Das Symptom ist trügerisch : Die Website, der E-Mail-Server, die Kamera oder der NAS antwortet einigen Clients, aber nicht anderen. Das dst-nat scheint korrekt zu sein, die Ports sind offen und der Dienst lauscht. Dennoch gelangt das erste SYN-Paket über das öffentliche WAN hinein, während das SYN-ACK den VPN nutzt. Die Abhilfe besteht darin, den Ursprung der Verbindung zu speichern und dann allen Rückkehrt-Paketen denselben Internetzugang aufzuerlegen.

Warum eine Standardroute nicht ausreicht

RouterOS wählt für jedes Paket eine Route. Wenn der Router über eine Regel verfügt, die einen Server, ein VLAN oder bestimmte Ziele an eine VPN-Tabelle leitet, kann diese Regel auch auf die Antwort eines veröffentlichten Dienstes angewendet werden. Eine gültige Standardroute in main verhindert also nicht, dass eine genauere Regel mangle das Paket woanders hin sendet.

Die Verbindungsüberwachung, oder conntrack, bietet den erforderlichen Speicher. Das erste auf dem WAN empfangene Paket wird mit einer Verbindung verknüpft. Eine Verbindungsmarkierung bleibt an beide Richtungen dieses Datenflusses angehängt. Wenn der Server antwortet, findet RouterOS diese Markierung wieder und kann eine Routenmarkierung anwenden, die eine für den ISP dedizierte Tabelle auswählt.

Vergrößern ↗

Szenario und verwendete Namen

Die folgenden Befehle zielen auf RouterOS 7 ab. Passen Sie die Namen an, bevor Sie sie einfügen. Die Adressen 192.0.2.0/24 gehören zu einem für die Dokumentation reservierten Block und dürfen nicht als echte Konfiguration verwendet werden.

Der veröffentlichte Server muss bereits mit einer Regel dst-nat funktionieren. Der Leitfaden ändert weder diese Übersetzung noch die Regeln, die den Datenverkehr auswählen, der das VPN nutzen darf.

Vor dem Beginn : Sicherung und Beobachtung

Eine falsche Routenmarkierung kann den Zugriff auf den Router unterbrechen. Arbeiten Sie aus dem LAN, aktivieren Sie den Safe Mode in WinBox oder mit Ctrl+X, und exportieren Sie dann die Konfiguration.

/export file=avant-routage-symetrique
/system backup save name=avant-routage-symetrique

Identifizieren Sie dann die Routen, die Regeln mangle und die Reihenfolge der Firewall. Eine allgemeine Regel, die vor den neuen Regeln platziert ist, kann das Paket zuerst abfangen.

/ip route print detail
/routing rule print detail
/ip firewall mangle print detail
/ip firewall filter print detail
/interface list member print

Überprüfen Sie insbesondere, dass ether1 tatsächlich das WAN des ISPs ist und dass die internen Schnittstellen zur Liste LAN gehören. Wenn Sie bereits Markierungen mit den Namen from-isp oder via-isp verwenden, wählen Sie andere Namen.

1. Erstellen der Routing-Tabelle des ISPs

In RouterOS 7 muss eine benutzerdefinierte Tabelle deklariert werden, bevor sie als new-routing-mark verwendet wird. Die Option fib ermöglicht ihre Verwendung für die tatsächliche Weiterleitung der Pakete.

/routing table
add fib name=via-isp

Fügen Sie bei einem statischen Gateway eine Standardroute in dieser Tabelle hinzu. Das Suffix @main gibt an, dass das Gateway mithilfe der Haupttabelle aufgelöst werden muss.

/ip route
add dst-address=0.0.0.0/0 gateway=192.0.2.1@main \
    routing-table=via-isp distance=1 \
    comment="Symmetrie: Rueckweg ueber ISP"

Behalten Sie nicht 192.0.2.1 bei : Ersetzen Sie es durch das Gateway, das tatsächlich in /ip route print detail sichtbar ist. Wenn das WAN sein Gateway per DHCP bezieht, verwenden Sie stattdessen das später vorgestellte Skript.

2. Markieren der eingehenden Verbindungen

Die erste Regel gilt nur für eine neue, noch nicht markierte Verbindung, die über das WAN des ISPs eingeht. Sie setzt from-isp auf die gesamte Verbindung. Sie entscheidet noch nicht über die Route.

/ip firewall mangle
add chain=prerouting action=mark-connection \
    in-interface=ether1 connection-state=new connection-mark=no-mark \
    new-connection-mark=from-isp passthrough=yes \
    comment="Symmetrie: Verbindungen vom ISP empfangen"

Wenn mehrere Internetzugänge aktiv sind, erstellen Sie für jeden Zugang eine eigene Markierung. Vermeiden Sie eine zu weit gefasste Regel, die nur auf in-interface-list=WAN basiert : Sie würde es nicht mehr ermöglichen zu wissen, welches WAN die Antwort tragen soll.

3. Zurücksenden der Antworten aus dem LAN über den ISP

Die zweite Regel stimmt nur mit Paketen überein, die aus dem LAN zurückkommen und zu einer markierten Verbindung gehören. Das erste eingehende Paket, das auf ether1 ankommt, kann daher nicht versehentlich an die Rückkehrtabelle gesendet werden. Der Ausschluss dst-address-type=!local verhindert auch, dass der Datenverkehr markiert wird, der für den Router selbst bestimmt ist.

/ip firewall mangle
add chain=prerouting action=mark-routing \
    in-interface-list=LAN connection-mark=from-isp \
    dst-address-type=!local new-routing-mark=via-isp passthrough=no \
    comment="Symmetrie: LAN-Antworten ueber ISP"

Diese Regel deckt die Antworten eines Servers hinter dst-nat ab. Die Regeln mangle für das Policy-Routing zum VPN müssen nach dieser Ausnahme kommen oder connection-mark=from-isp explizit ausschließen.

4. Abdecken der auf dem Router gehosteten Dienste

Ein Dienst, der auf dem MikroTik selbst endet — zum Beispiel ein VPN-Server — durchquert prerouting bei der Rückkehr nicht. Sein Paket wird lokal erstellt und durchläuft die Kette output. Fügen Sie also diese Regel hinzu, wenn der Router selbst auf vom ISP empfangene Verbindungen antwortet.

/ip firewall mangle
add chain=output action=mark-routing \
    connection-mark=from-isp dst-address-type=!local \
    new-routing-mark=via-isp passthrough=no \
    comment="Symmetrie: Router-Antworten ueber ISP"

Diese Regel erlaubt keinen neuen Dienst. Die Firewall input bleibt für den Zugriff auf den Router verantwortlich, und die Verwaltung sollte nicht direkt im Internet exponiert werden.

5. Verhindern, dass FastTrack die benutzerdefinierte Tabelle ignoriert

In RouterOS verarbeitet FastTrack die Pakete mit der Tabelle main. Eine Verbindung, die via-isp verwenden muss, darf also nicht in die allgemeine FastTrack-Regel eintreten. Fügen Sie eine gezielte Akzeptanz der markierten Verbindungen hinzu und platzieren Sie diese unmittelbar vor der ersten Regel fasttrack-connection.

/ip firewall filter
add chain=forward action=accept connection-mark=from-isp \
    connection-state=established,related \
    comment="Symmetrie: diese Verbindungen von FastTrack ausnehmen"

Verschieben Sie in WinBox diese Regel über FastTrack. Zeigen Sie in der Befehlszeile zuerst die Nummern an und verwenden Sie dann move mit den sichtbaren Nummern, anstatt eine Position anzunehmen.

/ip firewall filter print where action=fasttrack-connection
/ip firewall filter print where comment~"Symmetrie"

WAN mit per DHCP zugewiesenem Gateway

Eine benutzerdefinierte Route folgt nicht immer automatisch der Änderung des Gateways des DHCP-Clients. RouterOS stellt jedoch die Variablen bound und gateway-address im Ereignisskript des Clients zur Verfügung. Das folgende Skript erstellt oder aktualisiert nur die Route, die den Kommentar via-isp-dhcp trägt : Es berührt nicht die anderen Routen.

Öffnen Sie IP → DHCP Client, bearbeiten Sie den Client von ether1, und fügen Sie diesen Code in das Feld Script auf der Registerkarte „Erweitert“ ein.

:local routeComment "via-isp-dhcp"
:local routeId [/ip route find where comment=$routeComment]

:if ($bound = 1) do={
    :local nextHop ($"gateway-address" . "@main")
    :if ([:len $routeId] = 0) do={
        /ip route add dst-address=0.0.0.0/0 gateway=$nextHop \
            routing-table=via-isp distance=1 comment=$routeComment
    } else={
        /ip route set $routeId gateway=$nextHop disabled=no
    }
    :log info ("Route via-isp aktualisiert: " . $nextHop)
} else={
    :if ([:len $routeId] > 0) do={
        /ip route disable $routeId
    }
    :log warning "Route via-isp desactivee: bail DHCP absent"
}

Erneuern Sie nach dem Speichern den Lease während eines Wartungsfensters oder führen Sie das Skript über die Schnittstelle erneut aus. Überprüfen Sie, ob die Route in der Tabelle via-isp als aktiv angezeigt wird. Das Skript deaktiviert diese Route, wenn der Lease verschwindet, anstatt stillschweigend ein altes Gateway beizubehalten.

Fall eines PPPoE-Zugangs

Bei PPPoE kann das Gateway der Route die logische Schnittstelle selbst sein. Ein DHCP-Skript ist dann nicht erforderlich.

/ip route
add dst-address=0.0.0.0/0 gateway=pppoe-out1 \
    routing-table=via-isp distance=1 \
    comment="Symmetrie: PPPoE-Rueckweg ueber ISP"

Ersetzen Sie pppoe-out1 durch den tatsächlichen Namen der Schnittstelle. Wenn das VPN ebenfalls PPPoE oder eine dynamische Schnittstelle verwendet, identifizieren Sie jeden Eintrag mit einem eindeutigen Kommentar.

Überprüfen des Ergebnisses

Testen Sie aus einem tatsächlich externen Netzwerk : mobile Verbindung, entfernter Standort oder Überwachungssonde. Eine aus demselben LAN gestartete Anfrage kann Hairpin-NAT verwenden und validiert nicht den vollständigen Internetpfad.

/routing table print
/ip route print detail where routing-table=via-isp
/ip firewall mangle print stats
/ip firewall filter print stats
/ip firewall connection print detail where connection-mark=from-isp
/log print where message~"via-isp"

Für eine erfolgreiche eingehende Verbindung müssen die Zähler eine kohärente Geschichte erzählen :

1. die Regel mark-connection erhöht sich beim externen Verbindungsaufbau ;
2. die Verbindung erscheint mit connection-mark=from-isp ;
3. die Regel mark-routing des LAN erhöht sich, wenn der Server antwortet ;
4. die Standardroute von via-isp ist aktiv ;
5. die aufgebaute Verbindung wird nicht von FastTrack erfasst.

Eine begrenzte Erfassung auf der Schnittstelle des ISPs und der des VPN ermöglicht es, das Ergebnis eindeutig zu bestätigen. Das Antwortpaket des Servers muss über den ISP, nicht über den Tunnel, ausgehen.

/tool sniffer quick interface=ether1 ip-protocol=tcp
/tool torch interface=ether1

Filtern Sie, wenn möglich, nach der Adresse oder dem Port des getesteten Dienstes, um eine zu umfangreiche Erfassung zu vermeiden. Lassen Sie keinen dauerhaften Sniffer auf einem Router in Produktion laufen.

Fehlerbehebung : die häufigsten Ursachen

Vermeiden Sie auch eine Einstellung rp-filter=strict in einer absichtlich mehrpfadigen Architektur. Eine strikte Umkehrpfad-Filterung kann gültige Pakete verwerfen, wenn mehrere Tabellen und mehrere Ausgänge koexistieren. Bewerten Sie diesen Parameter im vollständigen Kontext der Firewall, bevor Sie ihn ändern.

Sauberes Entfernen der Konfiguration

Wenn das Ergebnis nicht konform ist, kann der Safe Mode die Änderungen der Sitzung rückgängig machen. Für eine manuelle Entfernung verwenden Sie die Kommentare und die eindeutigen Namen anstelle von Regelnummern, die sich möglicherweise geändert haben.

/ip firewall filter remove [find where comment="Symmetrie: diese Verbindungen von FastTrack ausnehmen"]
/ip firewall mangle remove [find where comment~"Symmetrie:"]
/ip route remove [find where comment="Symmetrie: Rueckweg ueber ISP"]
/ip route remove [find where comment="Symmetrie: PPPoE-Rueckweg ueber ISP"]
/ip route remove [find where comment="via-isp-dhcp"]
/routing table remove [find where name=via-isp]

Wenn Sie das Skript zum DHCP-Client hinzugefügt haben, leeren Sie auch dessen Feld Script. Löschen Sie die Tabelle nicht, solange noch eine Regel oder eine Route auf sie verweist.

Fazit

Die Koexistenz eines ISPs und eines VPNs stellt kein Problem dar, solange jede Verbindung einen vorhersehbaren Rückkehrpfad behält. In RouterOS ist die richtige Kombination einfach : Eine Verbindungsmarkierung speichert das Eingangs-WAN, eine Routenmarkierung verarbeitet die Antworten, und eine dedizierte Tabelle enthält den Ausgangspfad.

Die Zuverlässigkeit hängt vor allem von den Details ab : Erstellen der Tabelle vor ihrer Verwendung, Auflösen des dynamischen Gateways, Platzieren der Ausnahme vor dem VPN-Policy-Routing, Ausschließen dieser Datenflüsse von FastTrack und Überprüfen der Zähler aus einem externen Netzwerk. Sobald diese Punkte kontrolliert sind, antworten die veröffentlichten Dienste über den ISP, ohne dem Rest des Netzwerks seinen VPN-Tunnel zu entziehen.

Technische Referenzen

• MikroTik : Policy-Routing in RouterOS 7
• MikroTik : Verbindungsmarkierungen, Routenmarkierungen und FastTrack
• MikroTik : DHCP-Client und Skriptvariablen
• MikroTik : Routing-Tabellen und Migration auf RouterOS 7
• MikroTik : Verbindungsbezogenes Routing mit prerouting und output

Als Nächstes lesen

• DNS-Domänen in ein VPN mit MikroTik umleiten Netzwerke und Cybersicherheit · 16 Min.
• DNS-over-HTTPS auf MikroTik RouterOS konfigurieren Netzwerke und Cybersicherheit · 15 Min.
• Zuverlässige GeoIP-Filterung auf MikroTik RouterOS konfigurieren Netzwerke und Cybersicherheit · 17 Min.

Über den Autor

Jeremy Kraft betreut die Infrastruktur und die selbst gehosteten Dienste des IBCSC. Diese Anleitungen beschreiben Konfigurationen, die tatsächlich im Einsatz waren und vor der Veröffentlichung erneut geprüft wurden.

Eine Frage stellen Alle Anleitungen

Diskussion

Kommentare

0

Noch kein Kommentar. Eröffnen Sie die Diskussion gern mit einer Frage oder Ihrem eigenen Erfahrungsbericht.

Website

Ihr Name Sie haben ein Konto? Anmelden

Ihr Kommentar

Reiner Text, höchstens 2 000 Zeichen. Neue Kommentare werden moderiert. Ihr Name wird mit dem Kommentar angezeigt. Es wird keine E-Mail-Adresse abgefragt; gegen Spam wird nur ein nicht umkehrbarer Fingerabdruck Ihrer IP-Adresse gespeichert.

Kommentar senden