Jedan uređaj kroz VPN na ruteru traži tri pravila, a ne prekidač

Na VPN-u na ruteru nema prekidača za svaki uređaj; prekidač koji tražite je prečica koja u vaše ime piše pravila rutiranja politike. U trenutku kada jedan laptop, jedan opseg portova, jedna lista adresa ili jedan LAN segment mora da koristi tunel dok sve ostalo ostaje na WAN-u, gradite rutu politike, a ne uključujete funkciju. Posao ima tri pokretna dela i svaki odbija na svoj način: označena tabela bez rute izgleda kao tišina, oznaka postavljena u pogrešan lanac izgleda kao da se ništa nije dogodilo, a pravilo NAT koje nedostaje izgleda kao tunel koji se povezuje i ništa ne prenosi. Još dva dela se gube jer se nikada ne pojavljuju u pravilu mangle, a to su DNS i IPv6.

Mit: tunel je podešavanje klijenta

VPN klijent na strani rutera dobro radi jednu grubu stvar: stavlja 0.0.0.0/0 u glavnu tabelu rutiranja i usmerava je ka tunelu. WireGuard to izvodi iz AllowedIPs, OpenVPN a iz redirect-gateway koji gura server, i oba menjaju putanju za svakog hosta iza rutera. Sužavanje AllowedIPs ili dodavanje route-nopull menja ono što klijent instalira. To ne menja na koga se instalacija odnosi, jer klijent nikada ne vidi uređaje. Vidi samo pakete.

Izbor po izvoru ili odredištu je odluka rutiranja, pa pripada sloju politike rutera: pravilo mangle plus druga tabela na RouterOS-u, MARK plus ip rule na OpenWrt-u ili DD-WRT-u, ili firewall pravilo čiji je gateway tunel na pfSense-u. Netgateov recept za WireGuard klijent je ono što treba pročitati pre nagađanja, jer na toj platformi gateway pravila, dodela interfejsa i unos izlaznog NAT-a moraju da se slože pre nego što ijedan klijent koristi tunel.

Druga polovina mita je drugi ruter. Kupovina još jedne kutije ili premeštanje uređaja na gostujući SSID često uspeva, a razlog nije hardver: stavlja uređaj u sopstvenu podmrežu, što vam daje birač izvora koji firmware već razume. Ako taj segment možete da definišete na svom ruteru, dodatna kutija rešava problem koji niste imali.

Prvi deo: tunel koji nije podrazumevana ruta

Na RouterOS-u dodajte klijenta bez podrazumevane rute i dajte tunelu sopstvenu tabelu. Prva ruta je označena podrazumevana; druga je polovina neuspeha.

/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

Nedostupna ruta je razlog zašto označena tabela pobeđuje listu izuzetaka u glavnoj tabeli. Kada tunel padne, označeni paketi odmah dobijaju nedostupnost umesto da se tiho vrate na WAN, pa se kvar pojavljuje u poruci o grešci aplikacije, a ne na stranici geolokacije koju proveravate sat kasnije.

RouterOS 7 razdvaja ono što je 6.x držao zajedno: tabelu deklarišete sa /routing table add name=vpn fib, a zatim je pominjete po imenu na ruti i u pravilu mangle. Isječak za 6.x koji piše routing-mark bez definisanja tabele učitava se čisto i ne poklapa se ni sa čim. Drugi klasik su dve polovine 0.0.0.0/1, ili dve podrazumevane rute na istoj udaljenosti u jednoj tabeli: kernel bira jednu, a ponašanje se može promeniti posle restarta.

Drugi deo: označite pre traženja rute

Birač odlučuje koji paketi ulaze u tu tabelu. RouterOS obično počinje listom adresa za politiku odredišta, ili izvornom adresom za politiku uređaja:

/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 radi isto sa netfilter oznakom i pravilom koje označene pakete usmerava u tabelu koju ste popunili:

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

Lanac nije izbor stila. Kada paket stigne do FORWARD, traženje rute je već obavljeno, pa MARK ili DROP tamo može samo da prepiše ili odbaci. Oznaka mora da padne u PREROUTING za prosleđeni saobraćaj i u OUTPUT za saobraćaj koji ruter sam stvara, gde žive DNS, NTP i provere ažuriranja rutera. Taj izlazni put je uobičajen razlog zašto potpuno tunelovana postavka u testu curenja još uvek odgovara iz ISP resolvera.

Politika uređaja traži poklapanje koje ne klizi. Rezervišite adresu u DHCP-u ili uskladite interfejs za namenski segment; adresa koja se kasnije preseli na drugi uređaj tiho primenjuje tunel na pogrešnog klijenta. Most po SSID-u sa sopstvenom podmrežom je izdržljivija verzija iste ideje i daje IPv6 pravilima mesto za život.

Treći deo: NAT, DNS i LAN izuzetak

Saobraćaj koji izlazi kroz tunel traži izvornu adresu na koju će druga strana odgovoriti. Ograničite prevođenje na interfejs tunela: out-interface=VPN_NAME na RouterOS-u, -o tun0 na Linuxu, odgovarajući unos izlaznog NAT-a na pfSense-u. Pravilo masquerade bez tog ograničenja prepisuje saobraćaj koji ste hteli da ostavite na miru, a simptom je da uređaj van tunela gubi javnu adresu.

LAN izuzetak stvara više tema podrške nego sam tunel. Ako označena tabela drži samo podrazumevanu rutu, odredište štampača ili NAS-a sa izabranog uređaja poklapa se sa tim podrazumevanim i nestaje u tunelu. Dodajte LAN rutu u istu tabelu, ili isključite lokalnu podmrežu u biraču; oba rade, a isključenje je lakše održati ispravnim kada kasnije dodate VLAN-ove.

DNS ide posebnim putem. Upiti koje ruter prosleđuje potiču od rutera i prate OUTPUT, a ne prosleđenu oznaku, pa potpuno tunelovan laptop i dalje može da razrešava imena preko ISP-a. Usmerite klijente na resolver dostupan kroz tunel, ili označite saobraćaj port-53 samog rutera, pa proverite razrešenu adresu umesto da pretpostavite da je odgovor putovao zajedno sa veb zahtevom.

Kada se pravilo poklapa, ali aplikacija i dalje koristi WAN

Liste odredišta brzo stare. Ime se razrešava na adresu koje nema na listi, pa zahtev ide preko WAN-a, dok je svaki test koji ste radili na navedenoj adresi radio. Osvežite listu iz istog resolvera koji koristi klijent, i dajte prednost biraču zasnovanom na izvoru kada zaista želite sav saobraćaj sa jednog uređaja.

IPv6 je tihi zaobilaz. Uređaj ima drugu familiju adresa sa sopstvenom podrazumevanom rutom i sopstvenim skupom pravila, a poklapanje samo IPv4 adrese je pola politike. Primenite isti birač na ip6tables ili ekvivalent nftables, ili namerno isključite IPv6 na tom segmentu, a ne slučajno.

Uspostavljene veze su takođe važne. Unos conntrack-a napravljen pre izmene nastavlja starim putem dok ne istekne, pa pregledač koji je ostao otvoren tokom uređivanja izgleda tačno kao pravilo koje nikada nije primenjeno. Otvorite novu vezu, ili očistite stanje, pre nego što procenite politiku.

Proverite sa dva uređaja i restartom

Testirajte uređaj koji bi trebalo da bude u tunelu i uređaj koji ne bi trebalo, i uporedite drugi hop umesto broja brzine. Traceroute sa svakog pokazuje ili gateway tunela ili ISP gateway na drugom hopu; ako oba izgledaju isto, oznaka ili tabela ne rade ono što pravilo kaže. Za test koristite nove veze.

Zatim restartujte. Redosled podizanja je mesto gde radna politika postaje pokvarena, jer klijent mora biti podignut pre nego što se instalira nedostupna ruta, a sačuvani snimak koji vraća stari skup pravila prepisaće vašu tabelu. Proverite da je svako pravilo u sačuvanoj konfiguraciji i da označena podrazumevana ruta postoji posle podizanja, ne samo nakon što ste je otkucali.

Ako nešto ne uspe, prvo uklonite oznaku i vidite da li se normalan saobraćaj vraća, a zatim uklonite tabelu. Taj redosled vam kaže da li jurite problem rutiranja ili firewall-a, i ostavlja domaćinstvu štampač koji radi dok završavate posao.