Eén apparaat via een router-VPN vraagt drie regels, geen schakelaar

Er is geen schakelaar per apparaat op een router-VPN; de schakelaar die je zoekt is een snelkoppeling die namens jou beleidsrouteringsregels schrijft. Zodra één laptop, één poortbereik, één adressenlijst of één LAN-segment de tunnel moet gebruiken terwijl al het andere op de WAN blijft, bouw je een beleidsroute in plaats van een functie in te schakelen. Het werk heeft drie bewegende delen, en elk faalt anders: een gemarkeerde tabel zonder route ziet eruit als stilte, een mark in de verkeerde chain ziet eruit alsof er niets is gebeurd, en een ontbrekende NAT-regel ziet eruit als een tunnel die verbindt en niets vervoert. Nog twee delen ontbreken omdat ze nooit in de mangle-regel verschijnen, en dat zijn DNS en IPv6.

De mythe: de tunnel is een clientinstelling

Een VPN-client aan de routerkant doet één bot ding goed: hij zet 0.0.0.0/0 in de hoofdrouteringstabel en wijst die naar de tunnel. WireGuard leidt dat af uit AllowedIPs, OpenVPN uit een redirect-gateway die de server pusht, en beide veranderen het pad voor elke host achter de router. AllowedIPs versmallen of route-nopull toevoegen verandert wat de client installeert. Het verandert niet op wie die installatie van toepassing is, want de client ziet nooit apparaten. Hij ziet alleen pakketten.

Selectie op bron of bestemming is een routeringsbeslissing, dus hoort die bij de beleidslaag van de router: een mangle-regel plus een tweede tabel op RouterOS, een MARK plus een ip rule op OpenWrt of DD-WRT, of een firewallregel waarvan de gateway de tunnel is op pfSense. Netgates WireGuard-clientrecept is degene die je moet lezen voordat je gaat gissen, want op dat platform moeten de gateway van de regel, de toewijzing van de interface en de uitgaande NAT-regel het allemaal eens zijn voordat één client de tunnel gebruikt.

De tweede helft van de mythe is de tweede router. Een extra doos kopen, of het apparaat naar een gast-SSID verplaatsen, werkt vaak, en de reden is niet de hardware: het zet het apparaat in zijn eigen subnet, wat je de bronselector geeft die de firmware al begrijpt. Als je dat segment op je eigen router kunt definiëren, lost de extra doos een probleem op dat je niet had.

Deel één: een tunnel die niet de standaardroute is

Voeg op RouterOS de client toe zonder standaardroute en geef de tunnel zijn eigen tabel. De eerste route is de gemarkeerde standaard; de tweede is de faalhelft.

/ip route add dst-address=0.0.0.0/0 gateway=VPN_GATEWAY_IP routing-mark=vpn distance=1
/ip route add dst-address=0.0.0.0/0 type=unreachable routing-mark=vpn distance=2

De unreachable-route is waarom een gemarkeerde tabel een uitzonderingenlijst in de hoofdtabel verslaat. Als de tunnel wegvalt, krijgen gemarkeerde pakketten meteen unreachable in plaats van stilletjes terug te vallen op de WAN, zodat de storing in de foutmelding van de toepassing verschijnt en niet op een geolocatiepagina die je een uur later controleert.

RouterOS 7 splitst wat 6.x bij elkaar hield: je declareert de tabel met /routing table add name=vpn fib en verwijst er daarna bij naam naar op de route en in de mangle-regel. Een 6.x-fragment dat routing-mark schrijft zonder de tabel te definiëren, laadt netjes en matcht niets. De andere klassieker zijn twee 0.0.0.0/1-helften, of twee standaarden op dezelfde afstand in één tabel: de kernel kiest er één, en het gedrag kan na een herstart veranderen.

Deel twee: markeer vóór de route-opzoeking

De selector bepaalt welke pakketten die tabel binnenkomen. RouterOS begint meestal met een adressenlijst voor bestemmingsbeleid, of een bronadres voor apparaatbeleid:

/ip firewall mangle add chain=prerouting src-address=192.168.88.50 action=mark-routing new-routing-mark=vpn
/ip firewall mangle add chain=prerouting dst-address-list=via-vpn action=mark-routing new-routing-mark=vpn
/ip firewall address-list add list=via-vpn address=203.0.113.10

Linux-firmware doet hetzelfde met een netfilter-mark en een regel die gemarkeerde pakketten in een tabel stuurt die je hebt gevuld:

iptables -t mangle -A PREROUTING -p tcp --dport 27000:27050 -j MARK --set-mark 0x200
ip route add default dev tun0 table 100
ip rule add fwmark 0x200 table 100

De chain is geen stijlkeuze. Tegen de tijd dat een pakket FORWARD bereikt, is de route-opzoeking al gebeurd, dus een MARK of DROP daar kan alleen herschrijven of weggooien. De mark moet in PREROUTING landen voor doorgestuurd verkeer en in OUTPUT voor verkeer dat de router zelf maakt, waar de DNS, NTP en updatecontroles van de router leven. Dat uitvoerpad is de gebruikelijke reden waarom een volledig getunnelde opstelling in een lektest nog steeds antwoordt via de ISP-resolver.

Apparaatbeleid heeft een match nodig die niet wegloopt. Reserveer het adres in DHCP, of match een interface voor een toegewijd segment; een adres dat later naar een ander apparaat verhuist, past de tunnel stilletjes toe op de verkeerde client. Een bridge per SSID met een eigen subnet is de duurzamere versie van hetzelfde idee, en het geeft de IPv6-regels ook een plek.

Deel drie: NAT, DNS en de LAN-uitzondering

Verkeer dat door de tunnel naar buiten gaat, heeft een bronadres nodig waar de andere kant op antwoordt. Beperk de vertaling tot de tunnelinterface: out-interface=VPN_NAME op RouterOS, -o tun0 op Linux, een bijpassende uitgaande NAT-regel op pfSense. Een masquerade-regel zonder die afbakening herschrijft verkeer dat je met rust wilde laten, en het symptoom is dat het niet-getunnelde apparaat zijn openbare adres verliest.

De LAN-uitzondering veroorzaakt meer supportthreads dan de tunnel zelf. Als de gemarkeerde tabel alleen een standaardroute bevat, matcht een printer- of NAS-bestemming van het geselecteerde apparaat die standaard en verdwijnt in de tunnel. Voeg de LAN-route toe aan dezelfde tabel, of sluit het lokale subnet uit in de selector; beide werken, en de uitsluiting is makkelijker correct te houden wanneer je later VLAN's toevoegt.

DNS neemt een apart pad. Query's die de router doorstuurt, zijn van de router afkomstig en volgen OUTPUT, niet de doorgestuurde mark, dus een volledig getunnelde laptop kan nog steeds via de ISP resolven. Wijs clients naar een resolver die via de tunnel bereikbaar is, of markeer het port-53-verkeer van de router zelf, en controleer dan het opgeloste adres in plaats van aan te nemen dat het antwoord met de webaanvraag meereisde.

Wanneer de regel matcht maar de app nog steeds de WAN gebruikt

Bestemmingslijsten verouderen slecht. Een naam resolvet naar een adres dat niet in de lijst staat, dus gaat de aanvraag over de WAN terwijl elke test die je tegen het vermelde adres deed werkte. Ververs de lijst vanuit dezelfde resolver die de client gebruikt, en geef de voorkeur aan een op de bron gebaseerde selector wanneer je echt al het verkeer van één apparaat wilt.

IPv6 is de stille omweg. Het apparaat heeft een tweede adressenfamilie met zijn eigen standaardroute en zijn eigen regelset, en alleen het IPv4-adres matchen is de helft van een beleid. Pas dezelfde selector toe op ip6tables of het nftables-equivalent, of schakel IPv6 op dat segment bewust uit in plaats van per ongeluk.

Gevestigde verbindingen tellen ook. Een conntrack-item dat vóór de wijziging is aangemaakt, blijft het oude pad volgen tot het verloopt, dus een browser die tijdens de bewerking openbleef, ziet er precies uit als een regel die nooit is toegepast. Open een nieuwe verbinding, of leeg de status, voordat je het beleid beoordeelt.

Controleer met twee apparaten en een herstart

Test het apparaat dat door de tunnel moet en het apparaat dat dat niet moet, en vergelijk de tweede hop in plaats van een snelheidsgetal. Een traceroute vanaf elk toont ofwel de tunnelgateway ofwel de ISP-gateway op hop twee; als beide er hetzelfde uitzien, doen de mark of de tabel niet wat de regel zegt. Gebruik nieuwe verbindingen voor de test.

Herstart dan. De opstartvolgorde is waar een werkend beleid stukgaat, want de client moet actief zijn voordat de unreachable-route wordt geïnstalleerd, en een opgeslagen snapshot die de oude regelset herstelt, overschrijft je tabel. Controleer dat elke regel in de opgeslagen configuratie staat en dat de gemarkeerde standaard na de boot bestaat, niet alleen nadat je hem hebt getypt.

Als iets mislukt, verwijder dan eerst de mark en kijk of normaal verkeer terugkomt, en verwijder daarna de tabel. Die volgorde vertelt je of je een routeringsprobleem of een firewallprobleem achtervolgt, en ze laat het huishouden een werkende printer houden terwijl je de klus afmaakt.