Bepaalde domeinen routeren via een VPN met MikroTik
DNS-antwoorden omzetten in een dynamische adreslijst, de bijbehorende verbindingen markeren en deze naar een VPN-tabel sturen zonder het hele netwerk om te leiden.
Een domein routeren in een VPN lijkt eenvoudig : het zou volstaan om de naam in een regel te schrijven. Maar een router verzendt geen namen, hij verzendt pakketten naar IP-adressen. Eenzelfde service kan van adres veranderen, meerdere subdomeinen gebruiken of steunen op een CDN die gedeeld wordt met andere sites. De configuratie moet dus de DNS-resolutie correct koppelen aan policy routing.
RouterOS kan deze keten realiseren zonder extern script. Een statische DNS-invoer van het type FWD kan een domein en zijn subdomeinen herkennen, het verzoek doorsturen naar een resolver en vervolgens de verkregen adressen toevoegen aan een dynamische address-list. De firewall markeert daarna de nieuwe verbindingen naar deze lijst en een specifieke tabel stuurt ze de VPN-tunnel in.
Het principe in vijf stappen
- de LAN-clients gebruiken de MikroTik als DNS-server ;
- een DNS-regel
FWDherkent het gevraagde domein en, indien nodig, zijn subdomeinen ; - de teruggegeven IPv4-adressen voeden de lijst
vpn-domains; - de nieuwe verbindingen naar deze lijst krijgen de markering
domain-vpn; - de routeringsmarkering
via-vpn-domainselecteert een tabel waarvan de standaardroute door de tunnel gaat.
Vereisten en gebruikte namen
Het voorbeeld veronderstelt dat de WireGuard-tunnel wg-vpn al is opgezet en dat de peer de nodige bestemmingen accepteert. Voor een tunnel die als internetuitgang wordt gebruikt, omvatten de allowed-address doorgaans 0.0.0.0/0. De externe server moet ook forwarding en uitgaande NAT verzekeren, of een terugkeerroute naar het LAN kennen.
| Naam | Rol | Aan te passen |
|---|---|---|
wg-vpn | Interface van de reeds werkende tunnel | Echte naam van de VPN-interface |
LAN | Lijst van client-interfaces | Bridge of interne interfacelijst |
vpn-domains | Adressen geleerd via DNS | Vrije en unieke naam |
domain-vpn | Markering van de geselecteerde verbindingen | Vrije en unieke naam |
via-vpn-domain | Routeringstabel van de tunnel | Vrije en unieke naam |
service.example | Documentatiedomein | Uw werkelijke domein |
De getoonde configuratie is opzettelijk beperkt tot IPv4. Als de clients ook een IPv6-adres krijgen en AAAA-records oplossen, kunnen ze de service bereiken buiten dit IPv4-beleid om. Men moet dan een gelijkwaardig IPv6-beleid ontwerpen of deze omzeilroute expliciet blokkeren.
Voor het aanpassen van de routering
Werk vanuit het LAN, activeer de Safe Mode met Ctrl+X en exporteer de configuratie. Controleer ook of de tunnel al werkt naar een testadres voordat u routering per domein toevoegt.
/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
Gebruik de nieuwe regel niet om een nog inactieve tunnel te diagnosticeren. DNS, de routeringstabel en de firewall voegen meerdere lagen toe ; het VPN-transport moet afzonderlijk worden gevalideerd.
1. De routeringstabel van de VPN aanmaken
In RouterOS 7 moet de tabel bestaan voordat ze wordt gebruikt in een mark-routing-actie. De vlag fib staat het gebruik ervan toe voor het doorsturen van pakketten.
/routing table
add fib name=via-vpn-domain
Voeg daarna een standaardroute toe in deze tabel. Bij een punt-tot-punt WireGuard-interface kan de interface als gateway dienen.
/ip route
add dst-address=0.0.0.0/0 gateway=wg-vpn \
routing-table=via-vpn-domain distance=1 \
comment="Domeinen: uitgang via VPN"
Voor een ander type tunnel gebruikt u de gateway die in de documentatie ervan staat. Controleer of de route de actieve vlag draagt voordat u verdergaat.
/routing table print
/ip route print detail where routing-table=via-vpn-domain
2. De clients het DNS van de MikroTik laten gebruiken
De dynamische lijst vult zich enkel als de MikroTik het DNS-verzoek ziet. Activeer externe verzoeken (remote requests) en kondig vervolgens het LAN-adres van de router aan als DNS-server in het DHCP-netwerk.
/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
Vervang het netwerk en het adres van de router. Een extra uur bovenop de TTL vermindert het risico dat een client nog een adres behoudt terwijl de router het net is vergeten. Vermijd echter een willekeurig lange waarde : bij een snel veranderende CDN kan een oud adres onnodig in de VPN gerouteerd blijven.
Wanneer allow-remote-requests=yes actief is, moet de firewall input TCP en UDP 53 vanaf het LAN toestaan en ze vanaf het WAN weigeren. Het standaardprofiel van RouterOS past deze scheiding normaal toe, maar controleer dit.
/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"
Plaats deze regels voor de definitieve afwijzing van de input-keten. Voeg nooit een DNS-toelating toe zonder de interface of bronadressen te beperken : een open resolver op het internet kan worden misbruikt voor amplificatie-aanvallen.
3. De address-list voeden met DNS Static
Sinds RouterOS 7.16 kan een statische invoer van het type FWD worden gebruikt met een moderne DNS-forward en een adressenlijst. In het voorbeeld worden de verzoeken voor service.example en zijn subdomeinen doorgestuurd naar de resolver 9.9.9.9. De antwoorden voeden 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="Domeinen: resolutie en VPN-lijst"
Vervang het documentatiedomein. Een exacte invoer met match-subdomain=yes heeft de voorkeur boven een zeer brede reguliere expressie : ze is leesbaarder, sneller en beperkt onbedoelde overeenkomsten.
Als de inhoud wordt verdeeld via een CDN, kan de resolver een ander adres teruggeven afhankelijk van de locatie vanwaar het DNS-verzoek vertrekt. Om een antwoord te krijgen dat coherent is met de VPN-uitgang, kunt u de gekozen resolver door de tunnel laten gaan, op voorwaarde dat de VPN al is opgezet en dit geen circulaire afhankelijkheid creëert.
/ip route
add dst-address=9.9.9.9/32 gateway=wg-vpn routing-table=main \
comment="DNS van domeinen via VPN"
Eenvoudige variant voor één enkele naam
Voor één enkele host zonder subdomeinen accepteert RouterOS ook een DNS-naam rechtstreeks in een address-list. De router maakt de overeenkomstige dynamische invoeren aan.
/ip firewall address-list
add list=vpn-domains address=service.example \
comment="Enkel domein naar VPN"
Deze variant is handig voor een klein aantal gekende namen. Ze wordt minder duidelijk zodra een service meerdere subdomeinen, aliassen of een CDN-keten gebruikt. De methode FWD met match-subdomain=yes is dan flexibeler, omdat ze de adressen leert die daadwerkelijk door de clients worden opgevraagd.
4. De verbinding en vervolgens de routering markeren
Elk pakket rechtstreeks markeren op basis van de bestemming werkt, maar een verbindingsmarkering maakt de logica robuuster en vergemakkelijkt de uitsluiting van FastTrack. De eerste regel onthoudt de nieuwe verbindingen waarvan de bestemming tot vpn-domains behoort. De tweede past de VPN-tabel toe op al hun pakketten afkomstig van het LAN.
/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="Domeinen: verbinding markeren"
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="Domeinen: routeren in VPN"
Plaats deze regels voor de algemene policy routing-regels. De voorwaarde in-interface-list=LAN vermijdt het markeren van verkeer dat vanuit een andere WAN aankomt, en dst-address-type=!local beschermt de toegang tot de adressen van de router.
5. Deze verbindingen uitsluiten van FastTrack
FastTrack verwerkt enkel de tabel main correct. Voeg een acceptatieregel toe voor de gemarkeerde verbindingen en plaats ze onmiddellijk voor de regel fasttrack-connection. De andere verbindingen kunnen blijven profiteren van FastTrack.
/ip firewall filter
add chain=forward action=accept connection-mark=domain-vpn \
connection-state=established,related \
comment="Domeinen: uitsluiten van FastTrack"
Toon de regelnummers en verplaats de acceptatie boven FastTrack in WinBox of met move. Het is niet nodig om FastTrack voor het hele netwerk uit te schakelen.
/ip firewall filter print where action=fasttrack-connection
/ip firewall filter print where comment~"Domeinen"
6. De uitgaande NAT controleren
In een correct geroute site-to-site VPN kan het externe netwerk een terugkeerroute naar het LAN hebben en is geen extra NAT nodig. Voor een tunnel die als internetuitgang wordt gebruikt, verwacht de externe peer vaak een bronadres van de tunnel. Voeg dan een gerichte masquerade toe, en enkel als de architectuur dit vereist.
/ip firewall nat
add chain=srcnat action=masquerade out-interface=wg-vpn \
comment="Domeinen: NAT naar VPN-uitgang"
Lokale NAT is niet voldoende om een WireGuard-peer om te zetten in een internetgateway : het externe systeem moet ook forwarding toestaan en zijn eigen uitgang verzekeren. Controleer beide uiteinden.
De volledige keten testen
Maak de DNS-cache van de client leeg en los daarna het domein op door expliciet de MikroTik te bevragen. De lijst moet zich vullen voordat de mangle-tellers kunnen toenemen.
/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~"Domeinen"
/ip firewall connection print detail where connection-mark=domain-vpn
/ip route print detail where routing-table=via-vpn-domain
Open vervolgens vanaf een client de service en observeer de tunnel.
/interface monitor-traffic wg-vpn
/tool torch interface=wg-vpn
Controleer ook een niet-geselecteerde bestemming : deze moet de normale internettoegang blijven gebruiken. De test is onvolledig als al het verkeer per ongeluk de VPN in gaat.
Waarom sommige domeinen moeilijk blijven
| Situatie | Gevolg | Mogelijke reactie |
|---|---|---|
| De client gebruikt externe DoH of DoT | De MikroTik ziet de resolutie niet en de lijst blijft leeg | Het DNS van de apparaten beheren via beleid, MDM of firewall |
| Een CDN deelt hetzelfde IP tussen meerdere sites | Andere services kunnen de VPN volgen | Een applicatie-proxy gebruiken als nauwkeurigheid per naam onmisbaar is |
| De service roept nevendomeinen aan | De pagina opent gedeeltelijk | De vereiste namen identificeren in de ontwikkelaarstools en DNS-logboeken |
| De cache van de client leeft langer dan de lijst | De client behoudt een IP die de router niet meer classificeert | address-list-extra-time zorgvuldig aanpassen |
| IPv6 blijft beschikbaar | Het AAAA-verkeer kan het IPv4-beleid omzeilen | Een coherent IPv6-beleid creëren of dit pad bewust uitschakelen |
| QUIC gebruikt UDP 443 | Een filtering beperkt tot TCP zou worden omzeild | Alle IP-verbindingen van de lijst markeren, zoals in deze handleiding |
Een via DNS geleerd adres bewijst niet dat het uitsluitend aan het domein toebehoort. Omgekeerd, als een applicatie rechtstreeks een IP-adres contacteert zonder zichtbaar DNS-verzoek, zal het nooit aan de lijst worden toegevoegd. Routering per domein is dus een nuttige dynamische koppeling, geen inspectie van de TLS-inhoud.
De configuratie verwijderen
De opmerkingen en unieke namen maken verwijdering mogelijk zonder afhankelijk te zijn van regelnummers.
/ip firewall filter remove [find where comment="Domeinen: uitsluiten van FastTrack"]
/ip firewall mangle remove [find where comment~"Domeinen:"]
/ip firewall nat remove [find where comment="Domeinen: NAT naar VPN-uitgang"]
/ip dns static remove [find where comment="Domeinen: resolutie en VPN-lijst"]
/ip firewall address-list remove [find where comment="Enkel domein naar VPN"]
/ip route remove [find where comment="DNS van domeinen via VPN"]
/ip route remove [find where comment="Domeinen: uitgang via VPN"]
/routing table remove [find where name=via-vpn-domain]
Herstel ook de via DHCP aangekondigde DNS-server en de vorige waarde van address-list-extra-time indien deze uitsluitend voor deze functie waren gewijzigd.
Conclusie
RouterOS kan een domein en zijn subdomeinen naar een VPN sturen zonder handmatig een adressenlijst te onderhouden. De resolver zet de DNS-antwoorden om in address-list, de verbindingsmarkering onthoudt de beslissing en de tabel via-vpn-domain selecteert de tunnel. De rest van het netwerk behoudt zijn gebruikelijke route.
Het succes hangt af van drie controles : de clients moeten de MikroTik daadwerkelijk bevragen, de gemarkeerde verbindingen moeten buiten FastTrack blijven en de VPN-uitgang moet over de juiste terugkeerroutering of NAT beschikken. Voor complexe, gedeelde of sterk gedistribueerde services blijft een applicatie-proxy nauwkeuriger dan een beslissing die uitsluitend op IP-adressen gebaseerd is.
Discussie
Reacties
Nog geen reacties. U kunt de discussie openen met een vraag of uw eigen ervaring.