Én enhet gjennom en VPN-ruter trenger tre regler, ikke en bryter

Det finnes ingen bryter per enhet på en VPN-ruter; bryteren du leter etter er en snarvei som skriver policy-rutingsregler på dine vegne. I det øyeblikket én bærbar PC, ett portområde, én adresseliste eller ett LAN-segment må bruke tunnelen mens alt annet blir på WAN, bygger du en policy-rute og slår ikke på en funksjon. Jobben har tre bevegelige deler, og hver av dem feiler på sin måte: en merket tabell uten rute ser ut som stillhet, et merke satt i feil kjede ser ut som om ingenting skjedde, og en manglende NAT-regel ser ut som en tunnel som kobler til og ikke frakter noe. To deler til forsvinner fordi de aldri vises i mangle-regelen, og det er DNS og IPv6.

Myten: tunnelen er en klientinnstilling

En VPN-klient på ruteren gjør én grov ting godt: den setter 0.0.0.0/0 i hovedrutetabellen og peker den mot tunnelen. WireGuard utleder det fra AllowedIPs, OpenVPN fra en redirect-gateway som skyves fra serveren, og begge endrer veien for hver vert bak ruteren. Å snevre inn AllowedIPs eller legge til route-nopull endrer det klienten installerer. Det endrer ikke hvem installasjonen gjelder for, fordi klienten aldri ser enheter. Den ser bare pakker.

Valg etter kilde eller destinasjon er en rutebeslutning, så det hører til ruterens policy-lag: en mangle-regel pluss en andre tabell på RouterOS, et MARK pluss en ip rule på OpenWrt eller DD-WRT, eller en brannmurregel der gatewayen er tunnelen på pfSense. Netgates oppskrift for WireGuard-klienten er den du bør lese før du gjetter, fordi på den plattformen må regelens gateway, tildelingen av grensesnittet og NAT-oppføringen for utgående trafikk stemme før én eneste klient bruker tunnelen.

Den andre halvdelen av myten er den andre ruteren. Å kjøpe en boks til, eller flytte enheten til en gjeste-SSID, virker ofte, og grunnen er ikke maskinvaren: det setter enheten på sitt eget subnett, som gir deg kildevelgeren fastvaren allerede forstår. Hvis du kan definere det segmentet på ruteren du eier, løser den ekstra boksen et problem du ikke hadde.

Del én: en tunnel som ikke er standardruten

På RouterOS legger du til klienten uten standardrute og gir tunnelen sin egen tabell. Den første ruten er den merkede standarden; den andre er feilhalvdelen.

/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

Den utilgjengelige ruten er grunnen til at en merket tabell slår en unntaksliste i hovedtabellen. Når tunnelen faller, får merkede pakker umiddelbart utilgjengelig i stedet for å falle stille tilbake til WAN, så feilen dukker opp i programmets feilmelding og ikke på en geolokasjonsside du sjekker en time senere.

RouterOS 7 deler det 6.x holdt sammen: du erklærer tabellen med /routing table add name=vpn fib, og refererer så til den ved navn på ruten og i mangle-regelen. En 6.x-snutt som skriver routing-mark uten å definere tabellen, lastes rent og matcher ingenting. Den andre klassikeren er to 0.0.0.0/1-halvdeler, eller to standardruter på samme avstand i én tabell: kjernen velger én, og oppførselen kan endre seg etter en omstart.

Del to: merk før rutesøket

Velgeren bestemmer hvilke pakker som kommer inn i den tabellen. RouterOS starter vanligvis med en adresseliste for destinasjonspolicy, eller en kildeadresse for enhetspolicy:

/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-fastvaren gjør det samme med et netfilter-merke og en regel som styrer merkede pakker inn i en tabell du har fylt:

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

Kjeden er ikke et stilvalg. Når en pakke når FORWARD, har rutesøket allerede skjedd, så et MARK eller DROP der kan bare skrive om eller forkaste. Merket må lande i PREROUTING for videresendt trafikk og i OUTPUT for trafikk ruteren selv skaper, der ruterens DNS, NTP og oppdateringssjekker bor. Den utgangsveien er den vanlige grunnen til at et fullt tunnelert oppsett fortsatt svarer fra ISP-ens resolver i en lekkasjetest.

Enhetspolicy trenger en match som ikke driver. Reserver adressen i DHCP, eller match et grensesnitt for et dedikert segment; en adresse som senere flytter til en annen enhet, bruker stille tunnelen på feil klient. En bro per SSID med eget subnett er den mer holdbare versjonen av samme idé, og den gir IPv6-reglene et sted å bo også.

Del tre: NAT, DNS og LAN-unntaket

Trafikk som forlater gjennom tunnelen trenger en kildeadresse den andre siden vil svare på. Avgrens oversettelsen til tunellgrensesnittet: out-interface=VPN_NAME på RouterOS, -o tun0 på Linux, en samsvarende NAT-oppføring for utgående trafikk på pfSense. En masquerade-regel uten den avgrensningen skriver om trafikk du mente å la være, og symptomet er at enheten uten tunnel mister sin offentlige adresse.

LAN-unntaket skaper flere støttetråder enn selve tunnelen. Hvis den merkede tabellen bare har en standardrute, vil en skriver- eller NAS-destinasjon fra den valgte enheten matche den standarden og forsvinne inn i tunnelen. Legg LAN-ruten til i samme tabell, eller utelukk det lokale subnettet i velgeren; begge virker, og utelukkelsen er lettere å holde riktig når du legger til VLAN senere.

DNS tar en egen vei. Spørringer ruteren videresender, er ruterens egne og følger OUTPUT, ikke det videresendte merket, så en fullt tunnelert bærbar PC kan fortsatt slå opp navn via ISP-en. Pek klientene mot en resolver som nås over tunnelen, eller merk ruterens egen port-53-trafikk, og sjekk deretter den oppslåtte adressen i stedet for å anta at svaret reiste sammen med nettforespørselen.

Når regelen matcher, men appen fortsatt bruker WAN

Destinasjonslister eldes dårlig. Et navn slår opp til en adresse som ikke er i listen, så forespørselen tar WAN mens hver test du kjørte mot den oppførte adressen virket. Oppdater listen fra samme resolver som klienten bruker, og foretrekk en kildebasert velger når du virkelig vil ha all trafikk fra én enhet.

IPv6 er den stille omveien. Enheten har en andre adressefamilie med sin egen standardrute og sitt eget regelsett, og å matche bare IPv4-adressen er halv policy. Bruk den samme velgeren på ip6tables eller nftables-ekvivalenten, eller slå av IPv6 på det segmentet med vilje i stedet for ved et uhell.

Etablerte forbindelser betyr også noe. En conntrack-oppføring laget før endringen fortsetter å følge den gamle veien til den utløper, så en nettleser som sto åpen under redigeringen ser nøyaktig ut som en regel som aldri ble brukt. Åpne en ny forbindelse, eller tøm tilstanden, før du dømmer policyen.

Verifiser med to enheter og en omstart

Test enheten som skal være i tunnelen og enheten som ikke skal det, og sammenlign det andre hoppet i stedet for et hastighetstall. En traceroute fra hver viser enten tunellens gateway eller ISP-ens gateway på hopp to; hvis begge ser like ut, gjør ikke merket eller tabellen det regelen sier. Bruk nye forbindelser til testen.

Deretter omstart. Oppstartsrekkefølgen er der en fungerende policy blir ødelagt, fordi klienten må være oppe før den utilgjengelige ruten installeres, og et lagret øyeblikksbilde som gjenoppretter det gamle regelsettet vil overskrive tabellen din. Sjekk at hver regel er i den lagrede konfigurasjonen og at den merkede standarden finnes etter oppstart, ikke bare etter at du skrev den inn.

Hvis noe feiler, fjern merket først og se om normal trafikk kommer tilbake, og fjern deretter tabellen. Den rekkefølgen forteller deg om du jager et rute- eller et brannmurproblem, og den lar husstanden beholde en fungerende skriver mens du gjør ferdig jobben.