Un singur dispozitiv prin VPN-ul routerului cere trei reguli, nu un comutator

Nu există un comutator per dispozitiv pe un VPN de router; comutatorul pe care îl cauți este o scurtătură care scrie reguli de rutare de politică în numele tău. În momentul în care un laptop, un interval de porturi, o listă de adrese sau un segment LAN trebuie să folosească tunelul în timp ce restul rămâne pe WAN, construiești o rută de politică, nu activezi o funcție. Treaba are trei părți mișcătoare, și fiecare eșuează diferit: un tabel marcat fără rută arată ca tăcere, un marcaj aplicat în lanțul greșit arată ca și cum nu s-a întâmplat nimic, iar o regulă NAT lipsă arată ca un tunel care se conectează și nu transportă nimic. Încă două părți lipsesc pentru că nu apar niciodată în regula mangle, și acelea sunt DNS și IPv6.

Mitul: tunelul este o setare a clientului

Un client VPN de pe partea routerului face bine un lucru grosolan: pune 0.0.0.0/0 în tabelul principal de rutare și îl îndreaptă spre tunel. WireGuard deduce asta din AllowedIPs, OpenVPN iar OpenVPN dintr-un redirect-gateway împins de server, și ambele schimbă calea pentru fiecare gazdă din spatele routerului. Îngustarea AllowedIPs sau adăugarea route-nopull schimbă ce instalează clientul. Nu schimbă cui se aplică instalarea, pentru că clientul nu vede niciodată dispozitive. Vede doar pachete.

Selecția după sursă sau destinație este o decizie de rutare, așa că aparține stratului de politică al routerului: o regulă mangle plus un al doilea tabel pe RouterOS, un MARK plus un ip rule pe OpenWrt sau DD-WRT, sau o regulă de firewall al cărei gateway este tunelul pe pfSense. Rețeta Netgate pentru clientul WireGuard este cea care trebuie citită înainte de a ghici, pentru că pe acea platformă gateway-ul regulii, atribuirea interfeței și intrarea NAT de ieșire trebuie să fie de acord înainte ca un singur client să folosească tunelul.

A doua jumătate a mitului este al doilea router. Cumpărarea unei alte cutii, sau mutarea dispozitivului pe un SSID de oaspeți, funcționează adesea, iar motivul nu este hardware-ul: pune dispozitivul în propriul subnet, ceea ce îți dă selectorul de sursă pe care firmware-ul îl înțelege deja. Dacă poți defini acel segment pe routerul tău, cutia suplimentară rezolvă o problemă pe care nu o aveai.

Partea întâi: un tunel care nu este ruta implicită

Pe RouterOS adaugă clientul fără rută implicită și dă tunelului propriul tabel. Prima rută este implicitul marcat; a doua este jumătatea de eșec.

/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 este motivul pentru care un tabel marcat bate o listă de excepții din tabelul principal. Când tunelul cade, pachetele marcate primesc imediat unreachable în loc să se întoarcă în liniște la WAN, așa că defecțiunea apare în mesajul de eroare al aplicației și nu într-o pagină de geolocație pe care o verifici o oră mai târziu.

RouterOS 7 desparte ce 6.x ținea împreună: declari tabelul cu /routing table add name=vpn fib, apoi îl referențiezi după nume pe rută și în regula mangle. Un fragment 6.x care scrie routing-mark fără să definească tabelul se încarcă curat și nu se potrivește cu nimic. Cealaltă clasică sunt două jumătăți 0.0.0.0/1, sau două implicite la aceeași distanță într-un tabel: kernelul alege una, iar comportamentul se poate schimba după o repornire.

Partea a doua: marchează înainte de căutarea rutei

Selectorul decide ce pachete intră în acel tabel. RouterOS începe de obicei cu o listă de adrese pentru politica de destinație, sau cu o adresă sursă pentru politica de dispozitiv:

/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

Firmware-ul Linux face același lucru cu un marcaj netfilter și o regulă care dirijează pachetele marcate într-un tabel pe care l-ai populat:

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

Lanțul nu este o alegere de stil. Când un pachet ajunge la FORWARD, căutarea rutei a avut deja loc, așa că un MARK sau DROP acolo poate doar să rescrie sau să arunce. Marcajul trebuie să ajungă în PREROUTING pentru traficul redirecționat și în OUTPUT pentru traficul pe care routerul îl generează, unde locuiesc DNS, NTP și verificările de actualizare ale routerului. Acea cale de ieșire este motivul obișnuit pentru care o configurație complet tunelată încă răspunde din resolverul ISP într-un test de scurgere.

Politica de dispozitiv are nevoie de o potrivire care nu alunecă. Rezervă adresa în DHCP, sau potrivește o interfață pentru un segment dedicat; o adresă care se mută mai târziu pe alt dispozitiv aplică în liniște tunelul clientului greșit. Un bridge per SSID cu subnet propriu este versiunea mai durabilă a aceleiași idei și dă și regulilor IPv6 un loc unde să stea.

Partea a treia: NAT, DNS și excepția de LAN

Traficul care iese prin tunel are nevoie de o adresă sursă la care cealaltă parte să răspundă. Limitează traducerea la interfața tunelului: out-interface=VPN_NAME pe RouterOS, -o tun0 pe Linux, o intrare NAT de ieșire potrivită pe pfSense. O regulă masquerade fără acea limitare rescrie trafic pe care voiai să-l lași în pace, iar simptomul este că dispozitivul din afara tunelului își pierde adresa publică.

Excepția de LAN produce mai multe fire de suport decât tunelul în sine. Dacă tabelul marcat ține doar o rută implicită, o destinație de imprimantă sau NAS de pe dispozitivul selectat se potrivește cu acel implicit și dispare în tunel. Adaugă ruta LAN în același tabel, sau exclude subnetul local în selector; ambele funcționează, iar excluderea este mai ușor de ținut corect când adaugi VLAN-uri mai târziu.

DNS ia o cale separată. Interogările pe care routerul le redirecționează provin de la router și urmează OUTPUT, nu marcajul redirecționat, așa că un laptop complet tunelat poate încă rezolva prin ISP. Îndreaptă clienții spre un resolver accesibil prin tunel, sau marchează traficul port-53 al routerului însuși, apoi verifică adresa rezolvată în loc să presupui că răspunsul a călătorit împreună cu cererea web.

Când regula se potrivește dar aplicația tot folosește WAN-ul

Listele de destinații îmbătrânesc prost. Un nume se rezolvă la o adresă care nu este în listă, așa că cererea ia WAN-ul în timp ce fiecare test făcut pe adresa listată funcționa. Reîmprospătează lista din același resolver pe care îl folosește clientul și preferă un selector bazat pe sursă când vrei cu adevărat tot traficul de la un dispozitiv.

IPv6 este ocolirea tăcută. Dispozitivul are o a doua familie de adrese cu propria rută implicită și propriul set de reguli, iar potrivirea doar a adresei IPv4 este jumătate de politică. Aplică același selector pe ip6tables sau pe echivalentul nftables, ori dezactivează IPv6 pe acel segment intenționat, nu din greșeală.

Și conexiunile stabilite contează. O intrare conntrack creată înainte de schimbare continuă să urmeze calea veche până expiră, așa că un browser lăsat deschis în timpul editării arată exact ca o regulă care nu a fost niciodată aplicată. Deschide o conexiune nouă, sau curăță starea, înainte să judeci politica.

Verifică cu două dispozitive și o repornire

Testează dispozitivul care ar trebui să fie în tunel și dispozitivul care nu ar trebui, și compară al doilea hop în locul unui număr de viteză. Un traceroute din fiecare arată fie gateway-ul tunelului, fie gateway-ul ISP la hopul doi; dacă ambele arată la fel, marcajul sau tabelul nu face ce spune regula. Folosește conexiuni noi pentru test.

Apoi repornește. Ordinea de pornire este locul unde o politică funcțională se strică, pentru că clientul trebuie să fie sus înainte de instalarea rutei unreachable, iar un snapshot salvat care restaurează setul vechi de reguli îți va suprascrie tabelul. Verifică faptul că fiecare regulă este în configurația salvată și că implicitul marcat există după boot, nu doar după ce l-ai tastat.

Dacă ceva eșuează, scoate mai întâi marcajul și vezi dacă traficul normal revine, apoi scoate tabelul. Acea ordine îți spune dacă urmărești o problemă de rutare sau una de firewall, și lasă gospodăria cu o imprimantă funcțională cât timp termini treaba.