Een toestel deur ’n router-VPN het drie reëls nodig, nie ’n skakelaar nie

Daar is geen skakelaar per toestel op ’n router-VPN nie; die skakelaar waarna jy soek, is ’n kortpad wat beleidsteroutingreëls namens jou skryf. Die oomblik wanneer een skootrekenaar, een poortreeks, een adreslys of een LAN-segment deur die tonnel moet gaan terwyl al die res op die WAN bly, bou jy ’n beleidsroete eerder as om ’n funksie te aktiveer. Die werk het drie bewegende dele, en elkeen faal anders: ’n gemerkte tabel sonder ’n roete lyk soos stilte, ’n merk wat in die verkeerde ketting toegepas is, lyk of niks gebeur het nie, en ’n ontbrekende NAT-reël lyk soos ’n tonnel wat verbind en niks dra nie. Nog twee stukke gaan verlore omdat hulle nooit in die mangle-reël verskyn nie, en dit is DNS en IPv6.

Die mite: die tonnel is ’n kliëntinstelling

’n VPN-kliënt aan die routerkant doen een bot ding goed: dit sit 0.0.0.0/0 in die hoofroetetabel en wys dit na die tonnel. WireGuard lei dit uit AllowedIPs af, OpenVPN uit ’n gestuurde redirect-gateway, en albei verander die pad vir elke gasheer agter die router. Om AllowedIPs te vernou of route-nopull by te voeg, verander wat die kliënt installeer. Dit verander nie op wie die installasie van toepassing is nie, want die kliënt sien nooit toestelle nie. Hy sien net pakkette.

Seleksie volgens bron of bestemming is ’n roetebesluit, so dit hoort by die router se beleidslaag: ’n mangle-reël plus ’n tweede tabel op RouterOS, ’n MARK plus ’n ip rule op OpenWrt of DD-WRT, of ’n firewallreël waarvan die gateway die tonnel is op pfSense. Netgate se WireGuard-kliëntresep is die een om te lees voordat jy raai, want op daardie platform moet die reël se gateway, die koppelvlaktoewysing en die uitgaande NAT-inskrywing almal saamstem voordat ’n enkele kliënt die tonnel gebruik.

Die tweede helfte van die mite is die tweede router. Om nog ’n boks te koop, of die toestel na ’n gas-SSID te skuif, werk dikwels, en die rede is nie die hardeware nie: dit plaas die toestel op sy eie subnet, wat jou die bronselektor gee wat die firmware al verstaan. As jy daardie segment op die router kan definieer wat jy reeds het, los die ekstra boks ’n probleem op wat jy nie gehad het nie.

Deel een: ’n tonnel wat nie die verstekroete is nie

Op RouterOS voeg jy die kliënt by sonder ’n verstekroete en gee die tonnel sy eie tabel. Die eerste roete is die gemerkte verstek; die tweede is die fouthalf.

/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

Die onbereikbare roete is die rede waarom ’n gemerkte tabel ’n uitsonderingslys in die hooftabel klop. Wanneer die tonnel val, kry gemerkte pakkette dadelik ’n onbereikbaar eerder as om stilweg na die WAN terug te val, so die fout wys in die toepassing se foutboodskap eerder as op ’n geo-liggingblad wat jy ’n uur later nagaan.

RouterOS 7 splits wat 6.x saam gehou het: jy verklaar die tabel met /routing table add name=vpn fib, en verwys dan op die roete en in die mangle-reël by die naam daarvan. ’n 6.x-fragment wat routing-mark inlyn sit sonder om die tabel te definieer, laai skoon en pas niks. Die ander klassieke geval is twee 0.0.0.0/1-halwes, of twee verstekke op dieselfde afstand in een tabel: die kern kies een, en die gedrag kan ná ’n herlaai verander.

Deel twee: merk voor die roetesoektog

Die selektor besluit watter pakkette daardie tabel binnegaan. RouterOS begin gewoonlik met ’n adreslys vir bestemmingsbeleid, of ’n bronadres vir toestelbeleid:

/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 doen dieselfde ding met ’n netfilter-merk en ’n reël wat gemerkte pakkette in ’n tabel stuur wat jy gevul het:

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

Die ketting is nie ’n stylvraag nie. Teen die tyd dat ’n pakket FORWARD bereik, het die roetesoektog al plaasgevind, so ’n MARK of DROP daar kan net herskryf of weggooi. Die merk moet in PREROUTING beland vir deurgestuurde verkeer en in OUTPUT vir verkeer wat die router self begin, want dit is waar die router se DNS, NTP en opdateringskontroles woon. Daardie uitvoerpad is die gewone rede waarom ’n volledig getonnelde opstelling in ’n lektiotoets steeds van die ISP-resolver antwoord.

Toestelbeleid het ’n passing nodig wat nie wegdryf nie. Reserveer die adres in DHCP, of pas ’n koppelvlak vir ’n toegewyde segment; ’n adres wat later na ’n ander toestel skuif, pas die tonnel stilweg op die verkeerde kliënt toe. ’n Brug per SSID met sy eie subnet is die duursamer weergawe van dieselfde idee, en dit gee die IPv6-reëls ook ’n plek om te woon.

Deel drie: NAT, DNS en die LAN-uitsondering

Verkeer wat deur die tonnel uitgaan, het ’n bronadres nodig wat die verre kant sal antwoord. Beperk die vertaling tot die tonnelkoppelvlak: out-interface=VPN_NAME op RouterOS, -o tun0 op Linux, ’n ooreenstemmende uitgaande NAT-inskrywing op pfSense. ’n Masquerade-reël sonder daardie beperking herskryf verkeer wat jy bedoel het om alleen te laat, en die simptoom is dat die ongetonnelde toestel sy publieke adres verloor.

Die LAN-uitsondering veroorsaak meer ondersteuningsdrade as die tonnel self. As die gemerkte tabel net ’n verstekroete hou, pas ’n drukker- of NAS-bestemming van die gekose toestel by daardie verstek en verdwyn in die tonnel. Voeg die LAN-roete by dieselfde tabel, of sluit die plaaslike subnet in die selektor uit; albei werk, en die uitsluiting is makliker om korrek te hou wanneer jy later VLAN's byvoeg.

DNS neem ’n aparte pad. Navrae wat die router deurstuur, kom van die router self en volg OUTPUT, nie die deurgestuurde merk nie, so ’n volledig getonnelde skootrekenaar kan steeds deur die ISP resolveer. Wys kliënte na ’n resolver wat deur die tonnel bereikbaar is, of merk die router se eie poort-53-verkeer, en kyk dan na die geresolveerde adres eerder as om te aanvaar dat die antwoord saam met die webrekwestie gereis het.

Wanneer die reël pas maar die app gebruik steeds die WAN

Bestemmingslyste verouder sleg. ’n Naam resolveer na ’n adres wat nie in die lys is nie, so die rekwest neem die WAN terwyl elke toets wat jy teen die gelyste adres gedoen het, gewerk het. Verfris die lys van dieselfde resolver wat die kliënt gebruik, en verkies ’n brongebaseerde selektor wanneer jy werklik alle verkeer van een toestel wil hê.

IPv6 is die stil omleiding. Die toestel het ’n tweede adresfamilie met sy eie verstekroete en sy eie reëlstel, en om net die IPv4-adres te pas, is ’n halwe beleid. Pas dieselfde selektor op ip6tables of die nftables-ekwivalent toe, of skakel IPv6 op daardie segment doelbewus af eerder as per ongeluk.

Gevestigde verbindings maak ook saak. ’n Conntrack-inskrywing wat voor die verandering geskep is, volg die ou pad totdat dit verval, so ’n blaaier wat tydens die wysiging oopgebly het, lyk presies soos ’n reël wat nooit toegepas is nie. Maak ’n vars verbinding oop, of spoel die toestand, voordat jy die beleid beoordeel.

Verifieer met twee toestelle en ’n herlaai

Toets die toestel wat getonnel moet word en die toestel wat nie moet nie, en vergelyk die tweede hop eerder as ’n spoedgetal. ’n Traceroute van elkeen wys óf die tonnelpoort óf die ISP-poort by hop twee; as albei dieselfde lyk, doen die merk of die tabel nie wat die reël sê nie. Gebruik nuwe verbindings vir die toets.

Herlaai dan. Opstartvolgorde is waar ’n werkende beleid ’n stukkende een word, want die kliënt moet op wees voordat die onbereikbare roete geïnstalleer word, en ’n gestoorde momentopname wat die ou reëlstel herstel, sal jou tabel oorskryf. Kyk dat elke reël in die gestoorde konfigurasie is en dat die gemerkte verstek ná die opstart bestaan, nie net nadat jy dit getik het nie.

As iets faal, verwyder eers die merk en kyk of normale verkeer terugkeer, verwyder dan die tabel. Daardie volgorde sê vir jou of jy ’n roeteprobleem of ’n firewallprobleem jaag, en dit laat die huishouding met ’n werkende drukker terwyl jy die werk klaarmaak.