Én enhed gennem en router-VPN kræver tre regler, ikke en kontakt

Der er ingen kontakt pr. enhed på en router-VPN; den kontakt, du leder efter, er en genvej, der skriver policy routing-regler på dine vegne. I det øjeblik én bærbar, ét portområde, én adresseliste eller ét LAN-segment skal bruge tunnelen, mens alt andet bliver på WAN, bygger du en policy-rute i stedet for at aktivere en funktion. Opgaven har tre bevægelige dele, og hver af dem fejler forskelligt: en markeret tabel uden rute ligner tavshed, et mærke sat i den forkerte kæde ligner, at der ikke skete noget, og en manglende NAT-regel ligner en tunnel, der forbinder og ikke bærer noget. To dele mere forsvinder, fordi de aldrig optræder i mangle-reglen, og det er DNS og IPv6.

Myten: tunnelen er en klientindstilling

En VPN-klient på routeren gør én grov ting godt: den sætter 0.0.0.0/0 i den primære routingtabel og peger den mod tunnelen. WireGuard udleder det fra AllowedIPs, OpenVPN fra en skubbet redirect-gateway, og begge ændrer stien for hver vært bag routeren. At indsnævre AllowedIPs eller tilføje route-nopull ændrer, hvad klienten installerer. Det ændrer ikke, hvem installationen gælder, fordi klienten aldrig ser enheder. Den ser kun pakker.

Valg efter kilde eller destination er en routingbeslutning, så den hører til routerens politiklag: en mangle-regel plus en ekstra tabel på RouterOS, et MARK plus en ip rule på OpenWrt eller DD-WRT, eller en firewallregel, hvis gateway er tunnelen, på pfSense. Netgets WireGuard-klientopskrift er den, du skal læse, før du gætter, fordi regelens gateway, interface-tildelingen og den udgående NAT-post alle skal stemme overens på den platform, før en enkelt klient bruger tunnelen.

Den anden halvdel af myten er den anden router. At købe endnu en boks eller flytte enheden til et gæste-SSID virker ofte, og grunden er ikke hardwaren: det sætter enheden på sit eget subnet, hvilket giver dig den kildemarkør, firmwaren allerede forstår. Hvis du kan definere det segment på den router, du ejer, løser den ekstra boks et problem, du ikke havde.

Del et: en tunnel, der ikke er standardruten

På RouterOS tilføjer du klienten uden en standardrute og giver tunnelen sin egen tabel. Den første rute er den markerede standard; den anden er fejlhalvdelen.

/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

Ruten unreachable er grunden til, at en markeret tabel slår en undtagelsesliste i hovedtabellen. Når tunnelen falder, får markerede pakker straks unreachable i stedet for stille at falde tilbage til WAN, så fejlen viser sig i programmets fejlmeddelelse i stedet for på en geolokaliseringsside, du tjekker en time senere.

RouterOS 7 deler det, som 6.x holdt sammen: du erklærer tabellen med /routing table add name=vpn fib og henviser derefter til den ved navn på ruten og i mangle-reglen. Et 6.x-uddrag, der skriver routing-mark inline uden at definere tabellen, indlæses rent og matcher intet. Den anden klassiker er to 0.0.0.0/1-halvdele eller to standardruter på samme afstand i én tabel: kernen vælger én, og adfærden kan ændre sig efter en genstart.

Del to: markér før ruteopslaget

Markøren bestemmer, hvilke pakker der kommer i den tabel. RouterOS begynder normalt med en adresseliste til destinationspolitik eller en kildeadresse til enhedspolitik:

/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 gør det samme med et netfilter-mærke og en regel, der sender markerede pakker ind i en tabel, du har fyldt:

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

Kæden er ikke et stilvalg. Når en pakke når FORWARD, er ruteopslaget allerede sket, så et MARK eller DROP der kan kun omskrive eller kassere. Mærket skal lande i PREROUTING for videresendt trafik og i OUTPUT for trafik, som routeren selv skaber, og det er der, routerens DNS, NTP og opdateringstjek bor. Netop den udgående vej er den sædvanlige grund til, at et fuldt tunelleret opsætning stadig svarer fra ISP'ens resolver i en lækagetest.

Enhedspolitik kræver et match, der ikke driver. Reserver adressen i DHCP, eller match et interface til et dedikeret segment; en adresse, der senere flytter til en anden enhed, anvender tunnelen stille på den forkerte klient. En bro pr. SSID med sit eget subnet er den mere holdbare version af samme idé, og den giver IPv6-reglerne et sted at bo.

Del tre: NAT, DNS og LAN-undtagelsen

Trafik, der forlader gennem tunnelen, har brug for en kildeadresse, som den fjerne side vil svare på. Afgræns oversættelsen til tunnelinterfacet: out-interface=VPN_NAME på RouterOS, -o tun0 på Linux, en matchende udgående NAT-post på pfSense. En masquerade-regel uden den afgrænsning omskriver trafik, du ville lade være, og symptomet er, at den ikke-tunellerede enhed mister sin offentlige adresse.

LAN-undtagelsen skaber flere supporttråde end selve tunnelen. Hvis den markerede tabel kun har en standardrute, matcher en printer- eller NAS-destination fra den valgte enhed den standard og forsvinder ind i tunnelen. Tilføj LAN-ruten til samme tabel, eller udeluk det lokale subnet i markøren; begge virker, og udelukkelsen er lettere at holde korrekt, når du senere tilføjer VLAN'er.

DNS tager en særskilt vej. Forespørgsler, som routeren videresender, stammer fra routeren og følger OUTPUT, ikke det videresendte mærke, så en fuldt tunelleret bærbar kan stadig slå op via ISP'en. Peg klienter mod en resolver, der kan nås gennem tunnelen, eller markér routerens egen port-53-trafik, og tjek derefter den opløste adresse i stedet for at antage, at svaret rejste med webanmodningen.

Når reglen matcher, men appen stadig bruger WAN

Destinationslister bliver hurtigt forældede. Et navn opløses til en adresse, der ikke står på listen, så anmodningen tager WAN, mens hver test, du kørte mod den listede adresse, virkede. Opdater listen fra den samme resolver, som klienten bruger, og foretræk en kildebaseret markør, når du virkelig vil have al trafik fra én enhed.

IPv6 er den stille omvej. Enheden har en anden adressefamilie med sin egen standardrute og sit eget regelsæt, og at matche kun IPv4-adressen er halv politik. Anvend den samme markør på ip6tables eller nftables-ækvivalenten, eller slå IPv6 fra på det segment med vilje i stedet for ved et uheld.

Etablerede forbindelser betyder også noget. En conntrack-post, der blev oprettet før ændringen, følger den gamle vej, indtil den udløber, så en browser, der blev holdt åben under redigeringen, ligner præcis en regel, der aldrig blev anvendt. Åbn en ny forbindelse, eller skyl tilstanden, før du vurderer politikken.

Verificér med to enheder og en genstart

Test den enhed, der skal tunneleres, og den, der ikke skal, og sammenlign det andet hop i stedet for et hastighedstal. En traceroute fra hver viser enten tunnelgatewayen eller ISP-gatewayen ved hop to; hvis begge ser ens ud, gør mærket eller tabellen ikke, hvad reglen siger. Brug nye forbindelser til testen.

Genstart derefter. Opstartsrækkefølgen er der, hvor en fungerende politik bliver en brudt en, fordi klienten skal være oppe, før unreachable-ruten installeres, og et gemt snapshot, der gendanner det gamle regelsæt, vil overskrive din tabel. Tjek, at hver regel er i den gemte konfiguration, og at den markerede standard findes efter opstart, ikke kun efter at du har skrevet den.

Hvis noget fejler, fjern først mærket og se, om normal trafik vender tilbage, og fjern derefter tabellen. Den rækkefølge fortæller dig, om du jagter et routingproblem eller et firewallproblem, og den efterlader husstanden med en fungerende printer, mens du gør arbejdet færdigt.