DNS-Domänen in ein VPN mit MikroTik umleiten
Dynamische DNS-Antworten in eine Adressliste umwandeln, die zugehörigen Verbindungen markieren und in eine VPN-Tabelle umleiten, ohne das gesamte Netzwerk zu umgehen.
Das Routen einer Domain in ein VPN erscheint einfach : Es würde genügen, ihren Namen in eine Regel zu schreiben. Aber ein Router überträgt keine Namen, er überträgt Pakete an IP-Adressen. Ein und derselbe Dienst kann seine Adresse ändern, mehrere Subdomains verwenden oder sich auf ein CDN stützen, das mit anderen Websites geteilt wird. Die Konfiguration muss daher die DNS-Auflösung sauber mit dem Policy Routing verbinden.
RouterOS kann diese Kette ohne externes Skript realisieren. Ein statischer DNS-Eintrag vom Typ FWD kann eine Domain und ihre Subdomains erkennen, die Anfrage an einen Resolver weiterleiten und dann die erhaltenen Adressen zu einer dynamischen address-list hinzufügen. Die Firewall markiert anschließend die neuen Verbindungen zu dieser Liste, und eine dedizierte Tabelle sendet sie in den VPN-Tunnel.
Das Prinzip in fünf Schritten
- die LAN-Clients verwenden den MikroTik als DNS-Server ;
- eine DNS-Regel
FWDerkennt die angeforderte Domain und, falls erforderlich, ihre Subdomains ; - die zurückgegebenen IPv4-Adressen speisen die Liste
vpn-domains; - die neuen Verbindungen zu dieser Liste erhalten die Markierung
domain-vpn; - die Routing-Markierung
via-vpn-domainwählt eine Tabelle aus, deren Standardroute durch den Tunnel verläuft.
Voraussetzungen und verwendete Namen
Das Beispiel geht davon aus, dass der WireGuard-Tunnel wg-vpn bereits besteht und sein Peer die erforderlichen Zielorte akzeptiert. Für einen Tunnel, der als Internet-Ausgang genutzt wird, umfassen seine allowed-address in der Regel 0.0.0.0/0. Der Remote-Server muss auch das Forwarding und das Ausgangs-NAT gewährleisten oder eine Rückroute zum LAN kennen.
| Name | Rolle | Anzupassen |
|---|---|---|
wg-vpn | Schnittstelle des bereits funktionierenden Tunnels | Echter Name der VPN-Schnittstelle |
LAN | Liste der Client-Schnittstellen | Bridge oder interne Schnittstellenliste |
vpn-domains | Über DNS gelernte Adressen | Freier und eindeutiger Name |
domain-vpn | Markierung der ausgewählten Verbindungen | Freier und eindeutiger Name |
via-vpn-domain | Routing-Tabelle des Tunnels | Freier und eindeutiger Name |
service.example | Dokumentationsdomain | Ihre echte Domain |
Die vorgestellte Konfiguration ist bewusst auf IPv4 beschränkt. Wenn die Clients auch eine IPv6-Adresse erhalten und AAAA-Einträge auflösen, können sie den Dienst außerhalb dieser IPv4-Richtlinie erreichen. In diesem Fall muss eine äquivalente IPv6-Richtlinie entworfen oder dieser Umweg explizit unterbunden werden.
Vor der Änderung des Routings
Arbeiten Sie aus dem LAN, aktivieren Sie den Safe Mode mit Ctrl+X und exportieren Sie die Konfiguration. Stellen Sie außerdem sicher, dass der Tunnel bereits zu einer Testadresse funktioniert, bevor Sie das Domain-Routing hinzufügen.
/export file=avant-domaines-vpn
/system backup save name=avant-domaines-vpn
/interface wireguard print detail
/interface wireguard peers print detail
/ip route print detail
/ip firewall mangle print detail
Verwenden Sie die neue Regel nicht, um einen noch inaktiven Tunnel zu diagnostizieren. DNS, Routing-Tabelle und Firewall fügen mehrere Schichten hinzu ; der VPN-Transport muss separat validiert werden.
1. Erstellen der VPN-Routing-Tabelle
In RouterOS 7 muss die Tabelle existieren, bevor sie in einer Aktion mark-routing verwendet wird. Das Flag fib erlaubt ihre Verwendung für die Weiterleitung von Paketen.
/routing table
add fib name=via-vpn-domain
Fügen Sie anschließend eine Standardroute in dieser Tabelle hinzu. Bei einer Punkt-zu-Punkt-WireGuard-Schnittstelle kann die Schnittstelle als Gateway dienen.
/ip route
add dst-address=0.0.0.0/0 gateway=wg-vpn \
routing-table=via-vpn-domain distance=1 \
comment="Domains: Ausgang ueber VPN"
Verwenden Sie für einen anderen Tunneltyp das in seiner Dokumentation angegebene Gateway. Kontrollieren Sie, dass die Route das aktive Flag trägt, bevor Sie fortfahren.
/routing table print
/ip route print detail where routing-table=via-vpn-domain
2. Clients zur Verwendung des MikroTik-DNS veranlassen
Die dynamische Liste füllt sich nur, wenn der MikroTik die DNS-Anfrage sieht. Aktivieren Sie Remote-Anfragen und kündigen Sie dann die LAN-Adresse des Routers als DNS-Server im DHCP-Netzwerk an.
/ip dns
set allow-remote-requests=yes cache-size=8192KiB \
address-list-extra-time=1h
/ip dhcp-server network
set [find where address="192.168.88.0/24"] dns-server=192.168.88.1
Ersetzen Sie das Netzwerk und die Router-Adresse. Eine zusätzliche Stunde nach dem TTL reduziert das Risiko, dass ein Client noch eine Adresse speichert, während der Router sie gerade vergessen hat. Vermeiden Sie jedoch einen beliebig langen Wert : bei einem schnell wechselnden CDN könnte eine alte Adresse unnötigerweise im VPN geroutet bleiben.
Wenn allow-remote-requests=yes aktiv ist, muss die Firewall input TCP und UDP 53 aus dem LAN erlauben und sie aus dem WAN ablehnen. Das Standardprofil von RouterOS wendet diese Trennung normalerweise an, aber überprüfen Sie es.
/ip firewall filter
add chain=input action=accept in-interface-list=LAN \
protocol=udp dst-port=53 comment="DNS: LAN-Clients"
add chain=input action=accept in-interface-list=LAN \
protocol=tcp dst-port=53 comment="DNS: LAN-Clients TCP"
Platzieren Sie diese Regeln vor der endgültigen Ablehnung in der Kette input. Fügen Sie niemals eine DNS-Erlaubnis hinzu, ohne die Schnittstelle oder die Quelladressen einzuschränken : ein im Internet offener Resolver kann für Amplification-Angriffe missbraucht werden.
3. Speisen der address-list mit DNS Static
Seit RouterOS 7.16 kann ein statischer Eintrag vom Typ FWD mit einem modernen DNS-Forwarding und einer Adressliste verwendet werden. Im Beispiel werden Anfragen für service.example und seine Subdomains an den Resolver 9.9.9.9 weitergeleitet. Die Antworten speisen automatisch vpn-domains.
/ip dns static
add name=service.example type=FWD forward-to=9.9.9.9 \
match-subdomain=yes address-list=vpn-domains \
disabled=no \
comment="Domains: Aufloesung und VPN-Liste"
Ersetzen Sie die Dokumentationsdomain. Ein exakter Eintrag mit match-subdomain=yes ist einem sehr weiten regulären Ausdruck vorzuziehen : er ist lesbarer, schneller und begrenzt versehentliche Übereinstimmungen.
Wenn der Inhalt über ein CDN verteilt wird, kann der Resolver je nach Ursprungsort der DNS-Anfrage eine andere Adresse zurückgeben. Um eine Antwort zu erhalten, die mit dem VPN-Ausgang konsistent ist, können Sie den gewählten Resolver durch den Tunnel leiten, sofern das VPN bereits besteht und dies keine zirkuläre Abhängigkeit erzeugt.
/ip route
add dst-address=9.9.9.9/32 gateway=wg-vpn routing-table=main \
comment="DNS der Domains ueber VPN"
Einfache Variante für einen einzelnen Namen
Für einen einzelnen Host ohne Subdomains akzeptiert RouterOS auch einen DNS-Namen direkt in einer address-list. Der Router erstellt die entsprechenden dynamischen Einträge.
/ip firewall address-list
add list=vpn-domains address=service.example \
comment="Einzelne Domain ins VPN"
Diese Variante ist praktisch für eine kleine Anzahl bekannter Namen. Sie wird weniger klar, sobald ein Dienst mehrere Subdomains, Aliasse oder eine CDN-Kette verwendet. Die Methode FWD mit match-subdomain=yes ist dann flexibler, da sie die von den Clients tatsächlich angeforderten Adressen lernt.
4. Markieren der Verbindung und dann des Routings
Jedes Paket direkt anhand seines Ziels zu markieren funktioniert, aber eine Verbindungsmarkierung macht die Logik robuster und erleichtert den Ausschluss von FastTrack. Die erste Regel merkt sich die neuen Verbindungen, deren Ziel zu vpn-domains gehört. Die zweite wendet die VPN-Tabelle auf alle ihre Pakete an, die aus dem LAN stammen.
/ip firewall mangle
add chain=prerouting action=mark-connection \
in-interface-list=LAN dst-address-list=vpn-domains \
dst-address-type=!local connection-state=new \
connection-mark=no-mark new-connection-mark=domain-vpn \
passthrough=yes comment="Domains: Verbindung markieren"
add chain=prerouting action=mark-routing \
in-interface-list=LAN connection-mark=domain-vpn \
dst-address-type=!local new-routing-mark=via-vpn-domain \
passthrough=no comment="Domains: ins VPN routen"
Platzieren Sie diese Regeln vor den allgemeinen Policy-Routing-Regeln. Die Bedingung in-interface-list=LAN vermeidet es, den Verkehr zu markieren, der von einem anderen WAN ankommt, und dst-address-type=!local schützt den Zugriff auf die Adressen des Routers.
5. Ausschließen dieser Verbindungen von FastTrack
FastTrack verarbeitet nur die Tabelle main korrekt. Fügen Sie eine Accept-Regel für die markierten Verbindungen hinzu und platzieren Sie diese unmittelbar vor der Regel fasttrack-connection. Die anderen Verbindungen können weiterhin von FastTrack profitieren.
/ip firewall filter
add chain=forward action=accept connection-mark=domain-vpn \
connection-state=established,related \
comment="Domains: von FastTrack ausnehmen"
Zeigen Sie die Regelnummern an und verschieben Sie die Accept-Regel in WinBox oder mit move über FastTrack. Es ist nicht erforderlich, FastTrack für das gesamte Netzwerk zu deaktivieren.
/ip firewall filter print where action=fasttrack-connection
/ip firewall filter print where comment~"Domains"
6. Überprüfen des Ausgangs-NAT
In einem korrekt gerouteten Site-to-Site-VPN kann das Remote-Netzwerk eine Rückroute zum LAN besitzen, und es ist kein zusätzliches NAT erforderlich. Bei einem Tunnel, der als Internet-Ausgang verwendet wird, erwartet der Remote-Peer oft eine Quelladresse des Tunnels. Fügen Sie dann ein gezieltes Masquerade hinzu, und nur, wenn die Architektur es erfordert.
/ip firewall nat
add chain=srcnat action=masquerade out-interface=wg-vpn \
comment="Domains: NAT zum VPN-Ausgang"
Das lokale NAT reicht nicht aus, um einen WireGuard-Peer in ein Internet-Gateway zu verwandeln : das Remote-System muss auch das Forwarding erlauben und seinen eigenen Ausgang sicherstellen. Überprüfen Sie beide Enden.
Testen der gesamten Kette
Leeren Sie den DNS-Cache des Client-Rechners und lösen Sie dann die Domain auf, indem Sie explizit den MikroTik abfragen. Die Liste muss sich füllen, bevor die Zähler mangle steigen können.
/ip dns cache flush
/ip dns cache all print where name~"service.example"
/ip firewall address-list print where list=vpn-domains
/ip firewall mangle print stats where comment~"Domains"
/ip firewall connection print detail where connection-mark=domain-vpn
/ip route print detail where routing-table=via-vpn-domain
Öffnen Sie dann von einem Client aus den Dienst und beobachten Sie den Tunnel.
/interface monitor-traffic wg-vpn
/tool torch interface=wg-vpn
Überprüfen Sie auch ein nicht ausgewähltes Ziel : es muss weiterhin den normalen Internetzugang verwenden. Der Test ist unvollständig, wenn der gesamte Verkehr versehentlich in das VPN fließt.
Warum bestimmte Domains schwierig bleiben
| Situation | Auswirkung | Mögliche Reaktion |
|---|---|---|
| Der Client verwendet externes DoH oder DoT | Der MikroTik sieht die Auflösung nicht und die Liste bleibt leer | DNS der Geräte über Richtlinie, MDM oder Firewall verwalten |
| Ein CDN teilt dieselbe IP zwischen mehreren Websites | Andere Dienste könnten dem VPN folgen | Einen Anwendungsproxy verwenden, wenn eine namensbasierte Genauigkeit unerlässlich ist |
| Der Dienst ruft Nebendomains auf | Die Seite öffnet sich teilweise | Erforderliche Namen in den Entwicklertools und DNS-Protokollen identifizieren |
| Der Cache des Clients lebt länger als die Liste | Der Client behält eine IP, die der Router nicht mehr klassifiziert | address-list-extra-time vorsichtig anpassen |
| IPv6 bleibt verfügbar | Der AAAA-Verkehr kann die IPv4-Richtlinie umgehen | Eine kohärente IPv6-Richtlinie erstellen oder diesen Pfad bewusst deaktivieren |
| QUIC verwendet UDP 443 | Eine auf TCP beschränkte Filterung würde umgangen | Alle IP-Verbindungen der Liste markieren, wie in diesem Leitfaden |
Eine über DNS gelernte Adresse beweist nicht, dass sie ausschließlich zur Domain gehört. Umgekehrt, wenn eine Anwendung direkt eine IP-Adresse ohne sichtbare DNS-Anfrage kontaktiert, wird sie nie zur Liste hinzugefügt. Das Domain-Routing ist daher eine nützliche dynamische Zuordnung, keine TLS-Inhaltsprüfung.
Entfernen der Konfiguration
Kommentare und eindeutige Namen ermöglichen ein Entfernen, ohne von den Regelnummern abhängig zu sein.
/ip firewall filter remove [find where comment="Domains: von FastTrack ausnehmen"]
/ip firewall mangle remove [find where comment~"Domains:"]
/ip firewall nat remove [find where comment="Domains: NAT zum VPN-Ausgang"]
/ip dns static remove [find where comment="Domains: Aufloesung und VPN-Liste"]
/ip firewall address-list remove [find where comment="Einzelne Domain ins VPN"]
/ip route remove [find where comment="DNS der Domains ueber VPN"]
/ip route remove [find where comment="Domains: Ausgang ueber VPN"]
/routing table remove [find where name=via-vpn-domain]
Stellen Sie auch den über DHCP angekündigten DNS-Server und den vorherigen Wert von address-list-extra-time wieder her, falls sie nur für diese Funktion geändert wurden.
Fazit
RouterOS kann eine Domain und ihre Subdomains in ein VPN senden, ohne manuell eine Adressliste zu pflegen. Der Resolver wandelt die DNS-Antworten in address-list um, die Verbindungsmarkierung merkt sich die Entscheidung und die Tabelle via-vpn-domain wählt den Tunnel aus. Der Rest des Netzwerks behält seine übliche Route.
Der Erfolg hängt von drei Kontrollen ab : die Clients müssen den MikroTik tatsächlich abfragen, die markierten Verbindungen müssen außerhalb von FastTrack bleiben und der VPN-Ausgang muss über das passende Rückrouting oder NAT verfügen. Für komplexe, geteilte oder stark verteilte Dienste bleibt ein Anwendungsproxy genauer als eine Entscheidung, die nur auf IP-Adressen basiert.
Diskussion
Kommentare
Noch kein Kommentar. Eröffnen Sie die Diskussion gern mit einer Frage oder Ihrem eigenen Erfahrungsbericht.