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

Na ruter VPN-u nema prekidača za pojedinačni uređaj; prekidač koji tražite je prečica koja umjesto vas upisuje pravila usmjeravanja po politici. U trenutku kada jedan laptop, jedan raspon portova, jedna lista adresa ili jedan LAN segment mora ići kroz tunel dok sve ostalo ostaje na WAN-u, gradite rutu politike, a ne uključujete funkciju. Posao ima tri pokretna dijela i svaki pada drugačije: označena tabela bez rute izgleda kao tišina, marka primijenjena u pogrešnom lancu izgleda kao da se ništa nije dogodilo, a pravilo NAT-a koje nedostaje izgleda kao tunel koji se povezuje i ništa ne prenosi. Još dva dijela nedostaju jer se nikada ne pojavljuju u mangle pravilu, a to su DNS i IPv6.

Mit: tunel je postavka klijenta

VPN klijent na strani rutera dobro radi jednu grubu stvar: stavlja 0.0.0.0/0 u glavnu tabelu usmjeravanja i usmjerava ga na tunel. WireGuard to izvodi iz AllowedIPs, OpenVPN iz gurnutog redirect-gateway, i oba mijenjaju putanju za svakog hosta iza rutera. Sužavanje AllowedIPs ili dodavanje route-nopull mijenja ono što klijent instalira. Ne mijenja na koga se instalacija odnosi, jer klijent nikada ne vidi uređaje. Vidi samo pakete.

Odabir po izvoru ili odredištu je odluka o usmjeravanju, pa pripada političkom sloju rutera: mangle pravilo 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 prije nagađanja, jer na toj platformi gateway pravila, dodjela interfejsa i unos odlaznog NAT-a moraju se svi složiti prije nego ijedan klijent koristi tunel.

Druga polovina mita je drugi ruter. Kupovina još jedne kutije ili prebacivanje uređaja na gostujući SSID često zaista radi, a razlog nije hardver: to stavlja uređaj na vlastitu podmrežu, što vam daje selektor izvora koji firmware već razumije. Ako taj segment možete definirati na ruteru koji posjedujete, dodatna kutija rješava problem koji niste imali.

Prvi dio: tunel koji nije zadata ruta

Na RouterOS-u dodajte klijenta bez zadate rute i dajte tunelu vlastitu tabelu. Prva ruta je označena zadata; druga je polovina kvara.

/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

Ruta unreachable je razlog zašto označena tabela pobjeđuje listu izuzetaka u glavnoj tabeli. Kada tunel padne, označeni paketi dobijaju trenutno „nedostupno“ umjesto da se tiho vrate na WAN, pa se kvar vidi u poruci o grešci aplikacije, a ne na stranici geolokacije koju provjerite 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 po imenu referencirate u ruti i u mangle pravilu. Isječak za 6.x koji ugrađuje routing-mark bez definiranja tabele učitava se čisto i ne podudara se ni s čim. Drugi klasičan slučaj su dvije polovine 0.0.0.0/1 ili dvije zadate rute na istoj udaljenosti u jednoj tabeli: kernel bira jednu, a ponašanje se može promijeniti nakon ponovnog pokretanja.

Drugi dio: marka prije traženja rute

Selektor 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 s netfilter markom i pravilom koje označene pakete usmjerava 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 stvar stila. Kada paket stigne do FORWARD, traženje rute je već obavljeno, pa MARK ili DROP tamo može samo prepisati ili odbaciti. Marka mora pasti u PREROUTING za proslijeđeni saobraćaj i u OUTPUT za saobraćaj koji ruter sam stvara, jer tu žive ruterov DNS, NTP i provjere ažuriranja. Upravo je taj izlazni put uobičajen razlog zašto potpuno tunelirana postavka u testu curenja još odgovara s ISP resolvera.

Politika uređaja traži podudaranje koje ne odstupa. Rezervišite adresu u DHCP-u ili podudarite interfejs za namjenski segment; adresa koja kasnije pređe na drugi uređaj tiho primjenjuje tunel na pogrešnog klijenta. Most za svaki SSID s vlastitom podmrežom trajnija je verzija iste ideje i daje IPv6 pravilima mjesto za život.

Treći dio: NAT, DNS i izuzetak za LAN

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

Izuzetak za LAN stvara više tema podrške od samog tunela. Ako označena tabela drži samo zadanu rutu, odredište štampača ili NAS-a s odabranog uređaja podudara se s tom zadanom i nestaje u tunelu. Dodajte LAN rutu u istu tabelu ili isključite lokalnu podmrežu u selektoru; oboje radi, a izuzetak je lakše održavati ispravnim kada kasnije dodate VLAN-ove.

DNS ide posebnim putem. Upiti koje ruter prosljeđuje potječu od rutera i slijede OUTPUT, a ne proslijeđenu marku, pa potpuno tuneliran laptop još može prevoditi imena preko ISP-a. Usmjerite klijente na resolver dostupan kroz tunel ili označite ruterov vlastiti saobraćaj na portu 53, pa provjerite prevedenu adresu umjesto da pretpostavite da je odgovor putovao s web zahtjevom.

Kada se pravilo podudara, a aplikacija još koristi WAN

Liste odredišta brzo stare. Ime se prevede u adresu koje nema na listi, pa zahtjev ide na WAN, iako je svaki test koji ste radili na adresu s liste radio. Osvježite listu s istog resolvera koji koristi klijent i dajte prednost selektoru zasnovanom na izvoru kada zaista želite sav saobraćaj s jednog uređaja.

IPv6 je tihi zaobilazni put. Uređaj ima drugu porodicu adresa s vlastitom zadanom rutom i vlastitim skupom pravila, a podudaranje samo po IPv4 adresi je pola politike. Primijenite isti selektor na ip6tables ili ekvivalent u nftablesu, ili svjesno isključite IPv6 na tom segmentu, a ne slučajno.

Uspostavljene veze su takođe važne. Conntrack unos nastao prije promjene slijedi stari put dok ne istekne, pa pregledač koji je ostao otvoren tokom izmjene izgleda upravo kao pravilo koje nikada nije primijenjeno. Otvorite novu vezu ili ispraznite stanje prije nego procijenite politiku.

Provjerite s dva uređaja i jednim ponovnim pokretanjem

Testirajte uređaj koji treba biti u tunelu i uređaj koji ne treba, i uporedite drugi hop umjesto broja brzine. Traceroute sa svakog pokazuje ili gateway tunela ili ISP gateway na drugom hopu; ako oba izgledaju isto, marka ili tabela ne rade ono što pravilo kaže. Koristite nove veze za test.

Zatim ponovo pokrenite. Redoslijed podizanja je mjesto gdje radna politika postaje pokvarena, jer klijent mora biti aktivan prije nego se instalira ruta unreachable, a sačuvani snimak koji vraća stari skup pravila prepisat će vašu tabelu. Provjerite da je svako pravilo u sačuvanoj konfiguraciji i da označena zadata ruta postoji nakon podizanja, ne samo nakon što ste je otipkali.

Ako nešto padne, prvo uklonite marku i vidite vraća li se normalan saobraćaj, zatim uklonite tabelu. Taj redoslijed vam kaže jurite li problem usmjeravanja ili problem firewall-a, i ostavlja domaćinstvo s ispravnim štampačem dok vi završavate posao.