Ena naprava skozi VPN na usmerjevalniku zahteva tri pravila, ne stikalo

Na VPN na usmerjevalniku ni stikala za vsako napravo; stikalo, ki ga iščete, je bližnjica, ki v vašem imenu piše pravila usmerjanja politike. V trenutku, ko mora en prenosnik, eno območje vrat, en seznam naslovov ali en segment LAN uporabljati tunel, medtem ko vse ostalo ostane na WAN, gradite pot politike in ne vklapljate funkcije. Delo ima tri gibljive dele in vsak odpove drugače: označena tabela brez poti je videti kot tišina, oznaka v napačni verigi je videti, kot da se ni zgodilo nič, manjkajoče pravilo NAT pa je videti kot tunel, ki se poveže in nič ne prenese. Manjkata še dva dela, ker se nikoli ne pojavita v pravilu mangle, in to sta DNS in IPv6.

Mit: tunel je nastavitev odjemalca

Odjemalec VPN na strani usmerjevalnika dobro opravi eno grobo stvar: vstavi 0.0.0.0/0 v glavno usmerjevalno tabelo in jo usmeri v tunel. WireGuard to izpelje iz AllowedIPs, OpenVPN in iz redirect-gateway, ki ga potisne strežnik, in oba spremenita pot za vsakega gostitelja za usmerjevalnikom. Zoženje AllowedIPs ali dodajanje route-nopull spremeni, kaj odjemalec namesti. Ne spremeni pa, na koga se namestitev nanaša, ker odjemalec nikoli ne vidi naprav. Vidi samo pakete.

Izbira po viru ali cilju je odločitev usmerjanja, zato spada v plast politike usmerjevalnika: pravilo mangle in druga tabela na RouterOS, MARK in ip rule na OpenWrt ali DD-WRT, ali pravilo požarnega zidu, katerega prehod je tunel, na pfSense. Netgateov recept za odjemalca WireGuard je tisti, ki ga je treba prebrati, preden ugibate, ker se morajo na tej platformi prehod pravila, dodelitev vmesnika in vnos izhodnega NAT uskladiti, preden en sam odjemalec uporabi tunel.

Druga polovica mita je drugi usmerjevalnik. Nakup dodatne škatle ali premik naprave na gostujoči SSID pogosto deluje, razlog pa ni strojna oprema: napravo postavi v lastno podomrežje, kar vam da izbirnik vira, ki ga strojna programska oprema že razume. Če lahko ta segment določite na svojem usmerjevalniku, dodatna škatla reši problem, ki ga niste imeli.

Prvi del: tunel, ki ni privzeta pot

Na RouterOS dodajte odjemalca brez privzete poti in dajte tunelu lastno tabelo. Prva pot je označena privzeta; druga je polovica odpovedi.

/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

Nedosegljiva pot je razlog, da označena tabela premaga seznam izjem v glavni tabeli. Ko tunel pade, označeni paketi takoj dobijo nedosegljivost, namesto da bi se tiho vrnili na WAN, zato se napaka pokaže v sporočilu o napaki aplikacije in ne na strani z geolokacijo, ki jo preverite uro pozneje.

RouterOS 7 ločuje, kar je 6.x držal skupaj: tabelo razglasite z /routing table add name=vpn fib, nato pa se nanjo sklicujete po imenu na poti in v pravilu mangle. Odlomek za 6.x, ki piše routing-mark brez opredelitve tabele, se naloži čisto in se ne ujema z ničimer. Drugi klasik sta dve polovici 0.0.0.0/1 ali dve privzeti poti na enaki razdalji v eni tabeli: jedro izbere eno, vedenje pa se lahko po ponovnem zagonu spremeni.

Drugi del: označite pred iskanjem poti

Izbirnik odloči, kateri paketi vstopijo v to tabelo. RouterOS običajno začne s seznamom naslovov za politiko cilja ali z izvornim naslovom za politiko naprave:

/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

Vdelana programska oprema Linuxa stori isto z oznako netfilter in pravilom, ki označene pakete usmeri v tabelo, ki ste jo napolnili:

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

Veriga ni izbira sloga. Ko paket doseže FORWARD, je iskanje poti že opravljeno, zato lahko MARK ali DROP tam samo prepiše ali zavrže. Oznaka mora pristati v PREROUTING za posredovani promet in v OUTPUT za promet, ki ga ustvari usmerjevalnik sam, kjer živijo DNS, NTP in preverjanja posodobitev usmerjevalnika. Ta izhodna pot je običajen razlog, da popolnoma tunelirana postavitev v preskusu uhajanja še vedno odgovarja iz resolverja ponudnika.

Politika naprave potrebuje ujemanje, ki ne zdrsne. Rezervirajte naslov v DHCP ali uskladite vmesnik za namenski segment; naslov, ki se pozneje preseli na drugo napravo, tiho uporabi tunel na napačnem odjemalcu. Most po SSID z lastnim podomrežjem je trajnejša različica iste zamisli in daje pravilom IPv6 prostor za življenje.

Tretji del: NAT, DNS in izjema za LAN

Promet, ki odhaja skozi tunel, potrebuje izvorni naslov, na katerega bo druga stran odgovorila. Omejite prevajanje na vmesnik tunela: out-interface=VPN_NAME na RouterOS, -o tun0 na Linuxu, ustrezen vnos izhodnega NAT na pfSense. Pravilo masquerade brez te omejitve prepiše promet, ki ste ga hoteli pustiti pri miru, simptom pa je, da naprava zunaj tunela izgubi javni naslov.

Izjema za LAN povzroči več niti podpore kot tunel sam. Če označena tabela vsebuje le privzeto pot, se cilj tiskalnika ali NAS iz izbrane naprave ujame s to privzeto in izgine v tunelu. Dodajte pot LAN v isto tabelo ali v izbirniku izvzemite lokalno podomrežje; oboje deluje, izvzem pa je lažje ohraniti pravilen, ko pozneje dodate VLAN.

DNS gre po ločeni poti. Poizvedbe, ki jih usmerjevalnik posreduje, izvirajo iz usmerjevalnika in sledijo OUTPUT, ne posredovani oznaki, zato lahko popolnoma tuneliran prenosnik še vedno razrešuje prek ponudnika. Usmerite odjemalce na resolver, dosegljiv skozi tunel, ali označite promet port-53 samega usmerjevalnika, nato pa preverite razrešeni naslov, namesto da bi predpostavili, da je odgovor potoval skupaj z zahtevo po spletu.

Ko se pravilo ujema, aplikacija pa še vedno uporablja WAN

Seznami ciljev se hitro starajo. Ime se razreši na naslov, ki ga ni na seznamu, zato zahteva gre skozi WAN, medtem ko je vsak preskus, ki ste ga opravili na navedenem naslovu, deloval. Osvežite seznam iz istega resolverja, ki ga uporablja odjemalec, in raje izberite izbirnik na podlagi vira, kadar res želite ves promet z ene naprave.

IPv6 je tihi obhod. Naprava ima drugo družino naslovov z lastno privzeto potjo in lastnim naborom pravil, ujemanje samo z naslovom IPv4 pa je polovica politike. Uporabite isti izbirnik na ip6tables ali ekvivalentu nftables, ali namerno onemogočite IPv6 v tem segmentu, ne po nesreči.

Tudi vzpostavljene povezave štejejo. Vnos conntrack, ustvarjen pred spremembo, sledi stari poti, dokler ne poteče, zato je brskalnik, ki je ostal odprt med urejanjem, videti natanko kot pravilo, ki ni bilo nikoli uporabljeno. Odprite novo povezavo ali počistite stanje, preden presodite politiko.

Preverite z dvema napravama in ponovnim zagonom

Preskusite napravo, ki bi morala biti v tunelu, in napravo, ki ne bi smela biti, ter primerjajte drugi skok in ne števila hitrosti. Traceroute iz vsake pokaže bodisi prehod tunela bodisi prehod ponudnika na drugem skoku; če sta oba videti enako, oznaka ali tabela ne delata tega, kar pravi pravilo. Za preskus uporabite nove povezave.

Nato znova zaženite. Vrstni red zagona je mesto, kjer se delujoča politika pokvari, ker mora biti odjemalec pokonci, preden se namesti nedosegljiva pot, shranjen posnetek, ki obnovi star nabor pravil, pa bo prepisal vašo tabelo. Preverite, da je vsako pravilo v shranjeni konfiguraciji in da označeno privzeto obstaja po zagonu, ne le potem, ko ste ga vtipkali.

Če kaj odpove, najprej odstranite oznako in poglejte, ali se normalni promet vrne, nato odstranite tabelo. Ta vrstni red vam pove, ali lovite težavo z usmerjanjem ali s požarnim zidom, in gospodinjstvu pusti delujoč tiskalnik, medtem ko delo dokončate.