Isang device sa pamamagitan ng router VPN ay nangangailangan ng tatlong patakaran, hindi isang toggle

Walang switch kada device sa isang router VPN; ang toggle na hinahanap mo ay isang shortcut na nagsusulat ng mga patakaran ng policy routing sa ngalan mo. Sa sandaling ang isang laptop, isang hanay ng port, isang listahan ng address o isang segment ng LAN ay kailangang gumamit ng tunnel habang ang lahat ng iba ay nananatili sa WAN, gumagawa ka ng policy route at hindi nagbubukas ng feature. Ang gawain ay may tatlong gumagalaw na bahagi, at bawat isa ay nabigo nang iba: ang markadong talahanayan na walang ruta ay mukhang katahimikan, ang markang inilagay sa maling chain ay mukhang walang nangyari, at ang nawawalang patakaran sa NAT ay mukhang isang tunnel na kumokonekta at walang dinadala. Dalawa pang bahagi ang nawawala dahil hindi sila kailanman lumilitaw sa patakaran ng mangle, at iyon ay ang DNS at IPv6.

Ang mito: ang tunnel ay isang setting ng client

Ang VPN client sa gilid ng router ay mahusay sa isang bastos na bagay: inilalagay nito ang 0.0.0.0/0 sa pangunahing routing table at itinuturo ito sa tunnel. Hinango ito ng WireGuard mula sa AllowedIPs, OpenVPN at mula sa redirect-gateway na itinutulak ng server, at parehong binabago ang landas ng bawat host sa likod ng router. Ang pagpapaliit ng AllowedIPs o pagdaragdag ng route-nopull ay binabago ang inilalagay ng client. Hindi nito binabago kung sino ang saklaw ng pag-install, dahil hindi kailanman nakikita ng client ang mga device. Mga packet lang ang nakikita nito.

Ang pagpili ayon sa pinagmulan o destinasyon ay isang desisyon sa routing, kaya kabilang ito sa layer ng patakaran ng router: isang patakaran ng mangle kasama ang pangalawang talahanayan sa RouterOS, isang MARK kasama ang ip rule sa OpenWrt o DD-WRT, o isang patakaran ng firewall na ang gateway ay ang tunnel sa pfSense. Ang recipe ng WireGuard client ng Netgate ang dapat basahin bago manghula, dahil sa plataporma na iyon ang gateway ng patakaran, ang pagtatalaga ng interface at ang entry ng NAT palabas ay dapat magkasundo bago gamitin ng isang client ang tunnel.

Ang kabilang kalahati ng mito ay ang pangalawang router. Ang pagbili ng isa pang kahon, o paglipat ng device sa isang guest SSID, ay madalas gumagana, at ang dahilan ay hindi hardware: inilalagay nito ang device sa sarili nitong subnet, na nagbibigay sa iyo ng tagapili ng pinagmulan na nauunawaan na ng firmware. Kung madedefine mo ang segment na iyon sa router na pagmamay-ari mo, ang dagdag na kahon ay lumulutas ng problemang wala ka.

Unang bahagi: isang tunnel na hindi ang default na ruta

Sa RouterOS, idagdag ang client na walang default na ruta at bigyan ang tunnel ng sarili nitong talahanayan. Ang unang ruta ay ang markadong default; ang pangalawa ay ang kalahati ng pagpalya.

/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

Ang hindi maabot na ruta ang dahilan kung bakit natatalo ng markadong talahanayan ang listahan ng eksepsiyon sa pangunahing talahanayan. Kapag bumagsak ang tunnel, ang mga markadong packet ay agad na nakakakuha ng hindi maabot sa halip na tahimik na bumalik sa WAN, kaya lumilitaw ang pagpalya sa mensahe ng error ng aplikasyon at hindi sa isang pahina ng geolocation na tinitingnan mo makalipas ang isang oras.

Hinihiwalay ng RouterOS 7 ang pinagsama ng 6.x: idinedeklara mo ang talahanayan sa /routing table add name=vpn fib, pagkatapos ay tinutukoy ito sa pamamagitan ng pangalan sa ruta at sa patakaran ng mangle. Ang snippet ng 6.x na nagsusulat ng routing-mark nang hindi tinutukoy ang talahanayan ay malinis na naglo-load at walang tinutugma. Ang isa pang klasiko ay ang dalawang kalahati ng 0.0.0.0/1, o dalawang default sa parehong distansya sa isang talahanayan: pumipili ang kernel ng isa, at maaaring magbago ang pag-uugali pagkatapos ng reboot.

Ikalawang bahagi: markahan bago ang paghahanap ng ruta

Ang tagapili ang nagpapasya kung aling mga packet ang papasok sa talahanayang iyon. Karaniwang nagsisimula ang RouterOS sa isang listahan ng address para sa patakaran ng destinasyon, o isang source address para sa patakaran ng device:

/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

Ginagawa rin ito ng firmware ng Linux sa isang marka ng netfilter at isang patakarang nagdadala ng mga markadong packet sa isang talahanayang pinuno mo:

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

Ang chain ay hindi pagpipilian ng estilo. Sa oras na maabot ng packet ang FORWARD, nangyari na ang paghahanap ng ruta, kaya ang MARK o DROP doon ay makakapagsulat muli o makakatapon lamang. Dapat mapunta ang marka sa PREROUTING para sa trapikong ipinapasa at sa OUTPUT para sa trapikong likha ng router mismo, kung saan nakatira ang DNS, NTP at mga pagsusuri ng update ng router. Ang landas na palabas na iyon ang karaniwang dahilan kung bakit ang isang ganap na naka-tunnel na setup ay sumasagot pa rin mula sa resolver ng ISP sa isang leak test.

Ang patakaran ng device ay nangangailangan ng tugma na hindi gumagalaw. Ireserba ang address sa DHCP, o itugma ang isang interface para sa isang nakalaang segment; ang isang address na lumilipat mamaya sa ibang device ay tahimik na inilalapat ang tunnel sa maling client. Ang isang tulay kada SSID na may sariling subnet ay ang mas matibay na bersyon ng parehong ideya, at binibigyan din nito ng lugar ang mga patakaran ng IPv6.

Ikatlong bahagi: NAT, DNS at ang eksepsiyon sa LAN

Ang trapikong lumalabas sa tunnel ay nangangailangan ng source address na sasagutin ng kabilang panig. Limitahan ang pagsasalin sa interface ng tunnel: out-interface=VPN_NAME sa RouterOS, -o tun0 sa Linux, isang tugmang entry ng NAT palabas sa pfSense. Ang patakaran ng masquerade na walang saklaw na iyon ay nagsusulat muli ng trapikong balak mong iwanang tahimik, at ang sintomas ay nawawala ng pampublikong address ang device na wala sa tunnel.

Ang eksepsiyon sa LAN ay lumilikha ng mas maraming thread ng suporta kaysa sa tunnel mismo. Kung ang markadong talahanayan ay may default na ruta lamang, ang destinasyong printer o NAS mula sa piniling device ay tutugma sa default na iyon at mawawala sa tunnel. Idagdag ang ruta ng LAN sa parehong talahanayan, o ibukod ang lokal na subnet sa tagapili; parehong gumagana, at ang pagbubukod ay mas madaling panatilihing tama kapag nagdagdag ka ng VLAN mamaya.

Ang DNS ay may hiwalay na landas. Ang mga query na ipinapasa ng router ay nagmumula sa router at sumusunod sa OUTPUT, hindi sa ipinasa na marka, kaya ang isang ganap na naka-tunnel na laptop ay makakapag-resolve pa rin sa pamamagitan ng ISP. Ituro ang mga client sa isang resolver na maaabot sa pamamagitan ng tunnel, o markahan ang port-53 na trapiko ng router mismo, pagkatapos ay suriin ang na-resolve na address sa halip na ipagpalagay na naglakbay ang sagot kasama ng web request.

Kapag tumugma ang patakaran pero gumagamit pa rin ng WAN ang app

Mabilis tumanda ang mga listahan ng destinasyon. Ang isang pangalan ay nagre-resolve sa isang address na wala sa listahan, kaya kinukuha ng request ang WAN habang gumagana ang bawat pagsubok na ginawa mo sa nakalistang address. I-refresh ang listahan mula sa parehong resolver na ginagamit ng client, at piliin ang tagapiling nakabatay sa pinagmulan kapag talagang gusto mo ang lahat ng trapiko mula sa isang device.

Ang IPv6 ay ang tahimik na lusutan. May pangalawang pamilya ng address ang device na may sariling default na ruta at sariling set ng patakaran, at ang pagtutugma lamang sa address ng IPv4 ay kalahati ng patakaran. Ilapat ang parehong tagapili sa ip6tables o sa katumbas ng nftables, o sadyang patayin ang IPv6 sa segment na iyon sa halip na aksidente.

Mahalaga rin ang mga naitatag na koneksiyon. Ang isang entry ng conntrack na nilikha bago ang pagbabago ay patuloy na sumusunod sa lumang landas hanggang sa mag-expire, kaya ang browser na nanatiling bukas habang nag-edit ay mukhang eksaktong isang patakarang hindi kailanman inilapat. Magbukas ng bagong koneksiyon, o i-flush ang estado, bago mo hatulan ang patakaran.

I-verify sa dalawang device at isang reboot

Subukan ang device na dapat nasa tunnel at ang device na hindi dapat, at ihambing ang ikalawang hop sa halip na isang numero ng bilis. Ang traceroute mula sa bawat isa ay nagpapakita ng gateway ng tunnel o gateway ng ISP sa ikalawang hop; kung pareho ang hitsura, hindi ginagawa ng marka o talahanayan ang sinasabi ng patakaran. Gumamit ng mga bagong koneksiyon para sa pagsubok.

Pagkatapos ay i-reboot. Ang pagkakasunod-sunod ng boot ang lugar kung saan nasisira ang isang gumaganang patakaran, dahil kailangang nakabangon ang client bago ma-install ang hindi maabot na ruta, at ang isang naka-save na snapshot na nagbabalik ng lumang set ng patakaran ay magpapatong sa talahanayan mo. Suriin na ang bawat patakaran ay nasa naka-save na configuration at ang markadong default ay umiiral pagkatapos ng boot, hindi lamang pagkatapos mong i-type ito.

Kung may pumalya, alisin muna ang marka at tingnan kung bumabalik ang normal na trapiko, pagkatapos ay alisin ang talahanayan. Sinasabi ng pagkakasunod-sunod na iyon kung hinahabol mo ang isang problema sa routing o sa firewall, at iniiwan nito ang sambahayan na may gumaganang printer habang tinatapos mo ang trabaho.