Éi eining gjennom ein VPN-rutar treng tre reglar, ikkje ein brytar

Det finst ingen brytar per eining på ein VPN-rutar; brytaren du leitar etter er ein snarveg som skriv policy-rutingsreglar på dine vegner. I det augneblinken éi berbar datamaskin, eitt portområde, éi adresseliste eller eitt LAN-segment må bruke tunnelen medan alt anna blir verande på WAN, byggjer du ein policy-rute og slår ikkje på ein funksjon. Arbeidet har tre rørlege delar, og kvar av dei sviktar på sin måte: ein merkt tabell utan rute ser ut som stille, eit merke sett i feil kjede ser ut som om ingenting skjedde, og ein manglande NAT-regel ser ut som ein tunnel som koplar til og ikkje fraktar noko. To delar til forsvinn fordi dei aldri viser seg i mangle-regelen, og det er DNS og IPv6.

Myten: tunnelen er ei klientinnstilling

Ein VPN-klient på rutarsida gjer éi grov sak godt: han set 0.0.0.0/0 i hovudrutetabellen og peikar han mot tunnelen. WireGuard leier det ut frå AllowedIPs, OpenVPN frå ein redirect-gateway som blir skyvd frå tenaren, og båe endrar vegen for kvar vert bak rutaren. Å snevre inn AllowedIPs eller leggje til route-nopull endrar det klienten installerer. Det endrar ikkje kven installasjonen gjeld for, fordi klienten aldri ser einingar. Han ser berre pakkar.

Val etter kjelde eller mål er ei ruteavgjerd, så det høyrer til policy-laget til rutaren: ein mangle-regel pluss ein andre tabell på RouterOS, eit MARK pluss ein ip rule på OpenWrt eller DD-WRT, eller ein brannmurregel der gatewayen er tunnelen på pfSense. Netgate sin oppskrift for WireGuard-klienten er den du bør lese før du gjetar, fordi på den plattforma må gatewayen til regelen, tildelinga av grensesnittet og NAT-oppføringa for utgåande trafikk stemme før éin einaste klient brukar tunnelen.

Den andre halvdelen av myten er den andre rutaren. Å kjøpe ein boks til, eller flytte eininga til ein gjeste-SSID, verkar ofte, og grunnen er ikkje maskinvara: det set eininga på sitt eige subnett, som gjev deg kjeldeveljaren fastvaren allereie forstår. Viss du kan definere det segmentet på rutaren du eig, løyser den ekstra boksen eit problem du ikkje hadde.

Del éin: ein tunnel som ikkje er standardruta

På RouterOS legg du til klienten utan standardrute og gjev tunnelen sin eigen tabell. Den første ruta er den merkte 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 utilgjengelege ruta er grunnen til at ein merkt tabell slår ei unntaksliste i hovudtabellen. Når tunnelen fell, får merkte pakkar straks utilgjengeleg i staden for å falle stille tilbake til WAN, så feilen dukkar opp i feilmeldinga til programmet og ikkje på ei geolokasjonsside du sjekkar ein time seinare.

RouterOS 7 deler det 6.x heldt saman: du erklærer tabellen med /routing table add name=vpn fib, og viser så til han ved namn på ruta og i mangle-regelen. Ein 6.x-snutt som skriv routing-mark utan å definere tabellen, blir lasta reint og matchar ingenting. Den andre klassikaren er to 0.0.0.0/1-halvdelar, eller to standardruter på same avstand i éin tabell: kjernen vel éin, og åtferda kan endre seg etter ein omstart.

Del to: merk før rutesøket

Veljaren avgjer kva pakkar som kjem inn i den tabellen. RouterOS byrjar vanlegvis med ei adresseliste for målpolicy, eller ei kjeldeadresse for einingspolicy:

/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 gjer det same med eit netfilter-merke og ein regel som styrer merkte pakkar inn i ein 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

Kjeda er ikkje eit stilval. Når ein pakke når FORWARD, har rutesøket alt skjedd, så eit MARK eller DROP der kan berre skrive om eller kaste. Merket må lande i PREROUTING for vidaresend trafikk og i OUTPUT for trafikk rutaren sjølv skaper, der DNS, NTP og oppdateringssjekkane til rutaren bur. Den utgangsvegen er den vanlege grunnen til at eit fullt tunna oppsett framleis svarar frå ISP-en sin resolver i ein lekkasjetest.

Einingspolicy treng ein match som ikkje driv. Reserver adressa i DHCP, eller match eit grensesnitt for eit dedikert segment; ei adresse som seinare flyttar til ei anna eining, brukar stille tunnelen på feil klient. Ei bru per SSID med eige subnett er den meir haldbare versjonen av same idé, og ho gjev IPv6-reglane ein stad å bu også.

Del tre: NAT, DNS og LAN-unntaket

Trafikk som går ut gjennom tunnelen treng ei kjeldeadresse den andre sida vil svare på. Avgrens omsetjinga til tunellgrensesnittet: out-interface=VPN_NAME på RouterOS, -o tun0 på Linux, ei samsvarande NAT-oppføring for utgåande trafikk på pfSense. Ein masquerade-regel utan den avgrensinga skriv om trafikk du meinte å la vere, og symptomet er at eininga utan tunnel mistar den offentlege adressa si.

LAN-unntaket skaper fleire støttetrådar enn sjølve tunnelen. Viss den merkte tabellen berre har ei standardrute, vil ein skrivar- eller NAS-destinasjon frå den valde eininga matche den standarden og forsvinne inn i tunnelen. Legg LAN-ruta til i same tabell, eller utelukk det lokale subnettet i veljaren; båe verkar, og utelukkinga er lettare å halde rett når du legg til VLAN seinare.

DNS tek ein eigen veg. Spørjingar rutaren vidaresender, er rutaren sine eigne og følgjer OUTPUT, ikkje det vidaresende merket, så ein fullt tunna berbar datamaskin kan framleis slå opp namn via ISP-en. Peik klientane mot ein resolver som ein når over tunnelen, eller merk sjølve port-53-trafikken til rutaren, og sjekk deretter den oppslåtte adressa i staden for å gå ut frå at svaret reiste saman med nettførespurnaden.

Når regelen matchar, men appen framleis brukar WAN

Destinasjonslister blir fort gamle. Eit namn slår opp til ei adresse som ikkje står i lista, så førespurnaden tek WAN medan kvar test du køyrde mot den oppførte adressa verka. Oppdater lista frå same resolver som klienten brukar, og føretrekk ein kjeldebasert veljar når du verkeleg vil ha all trafikk frå éi eining.

IPv6 er den stille omvegen. Eininga har ein andre adressefamilie med si eiga standardrute og sitt eige regelsett, og å matche berre IPv4-adressa er halv policy. Bruk den same veljaren på ip6tables eller nftables-ekvivalenten, eller slå av IPv6 på det segmentet med vilje i staden for ved eit uhell.

Etablerte samband tel også. Ei conntrack-oppføring laga før endringa held fram med å følgje den gamle vegen til ho går ut, så ein nettlesar som stod open under redigeringa ser nøyaktig ut som ein regel som aldri vart brukt. Opne eit nytt samband, eller tøm tilstanden, før du dømmer policyen.

Stadfest med to einingar og ein omstart

Test eininga som skal vere i tunnelen og eininga som ikkje skal det, og samanlikn det andre hoppet i staden for eit farts tal. Ein traceroute frå kvar viser anten gatewayen til tunnelen eller ISP-en sin gateway på hopp to; viss båe ser like ut, gjer ikkje merket eller tabellen det regelen seier. Bruk nye samband til testen.

Deretter omstart. Oppstartsrekkjefølgja er der ein fungerande policy blir øydelagd, fordi klienten må vere oppe før den utilgjengelege ruta blir installert, og eit lagra augneblinksbilete som gjenopprettar det gamle regelsettet vil overskrive tabellen din. Sjekk at kvar regel er i den lagra konfigurasjonen og at den merkte standarden finst etter oppstart, ikkje berre etter at du skreiv han inn.

Viss noko sviktar, fjern merket først og sjå om normal trafikk kjem tilbake, og fjern deretter tabellen. Den rekkjefølgja fortel deg om du jagar eit rute- eller eit brannmurproblem, og ho lèt husstanden behalde ein fungerande skrivar medan du gjer ferdig jobben.