Један уређај кроз VPN на рутеру тражи три правила, а не прекидач

На VPN-у на рутеру нема прекидача за сваки уређај; прекидач који тражите је пречица која у ваше име пише правила рутирања политике. У тренутку када један лаптоп, један опсег портова, једна листа адреса или један LAN сегмент мора да користи тунел док све остало остаје на WAN-у, градите руту политике, а не укључујете функцију. Посао има три покретна дела и сваки одбија на свој начин: означена табела без руте изгледа као тишина, ознака постављена у погрешан ланац изгледа као да се ништа није догодило, а правило NAT које недостаје изгледа као тунел који се повезује и ништа не преноси. Још два дела се губе јер се никада не појављују у правилу mangle, а то су DNS и IPv6.

Мит: тунел је подешавање клијента

VPN клијент на страни рутера добро ради једну грубу ствар: ставља 0.0.0.0/0 у главну табелу рутирања и усмерава је ка тунелу. WireGuard то изводи из AllowedIPs, OpenVPN а из redirect-gateway који гура сервер, и оба мењају путању за сваког хоста иза рутера. Сужавање AllowedIPs или додавање route-nopull мења оно што клијент инсталира. То не мења на кога се инсталација односи, јер клијент никада не види уређаје. Види само пакете.

Избор по извору или одредишту је одлука рутирања, па припада слоју политике рутера: правило mangle плус друга табела на RouterOS-у, MARK плус ip rule на OpenWrt-у или DD-WRT-у, или firewall правило чији је гејтвеј тунел на pfSense-у. Netgate-ов рецепт за WireGuard клијент је оно што треба прочитати пре нагађања, јер на тој платформи гејтвеј правила, додела интерфејса и унос излазног NAT-а морају да се сложе пре него што иједан клијент користи тунел.

Друга половина мита је други рутер. Куповина још једне кутије или премештање уређаја на гостујући SSID често успева, а разлог није хардвер: ставља уређај у сопствену подмрежу, што вам даје бирач извора који фримвер већ разуме. Ако тај сегмент можете да дефинишете на свом рутеру, додатна кутија решава проблем који нисте имали.

Први део: тунел који није подразумевана рута

На RouterOS-у додајте клијента без подразумеване руте и дајте тунелу сопствену табелу. Прва рута је означена подразумевана; друга је половина неуспеха.

/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

Недоступна рута је разлог зашто означена табела побеђује листу изузетака у главној табели. Када тунел падне, означени пакети одмах добијају недоступност уместо да се тихо врате на WAN, па се квар појављује у поруци о грешци апликације, а не на страници геолокације коју проверавате сат касније.

RouterOS 7 раздваја оно што је 6.x држао заједно: табелу декларишете са /routing table add name=vpn fib, а затим је помињете по имену на рути и у правилу mangle. Исечак за 6.x који пише routing-mark без дефинисања табеле учитава се чисто и не поклапа се ни са чим. Други класик су две половине 0.0.0.0/1, или две подразумеване руте на истој удаљености у једној табели: кернел бира једну, а понашање се може променити после рестарта.

Други део: означите пре тражења руте

Бирач одлучује који пакети улазе у ту табелу. RouterOS обично почиње листом адреса за политику одредишта, или изворном адресом за политику уређаја:

/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 фримвер ради исто са netfilter ознаком и правилом које означене пакете усмерава у табелу коју сте попунили:

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

Ланац није избор стила. Када пакет стигне до FORWARD, тражење руте је већ обављено, па MARK или DROP тамо може само да препише или одбаци. Ознака мора да падне у PREROUTING за прослеђени саобраћај и у OUTPUT за саобраћај који рутер сам ствара, где живе DNS, NTP и провере ажурирања рутера. Тај излазни пут је уобичајен разлог зашто потпуно тунелисана поставка у тесту цурења још увек одговара из ISP resolver-а.

Политика уређаја тражи поклапање које не клизи. Резервишите адресу у DHCP-у или ускладите интерфејс за наменски сегмент; адреса која се касније пресели на други уређај тихо примењује тунел на погрешног клијента. Мост по SSID-у са сопственом подмрежом је издржљивија верзија исте идеје и даје IPv6 правилима место за живот.

Трећи део: NAT, DNS и LAN изузетак

Саобраћај који излази кроз тунел тражи изворну адресу на коју ће друга страна одговорити. Ограничите превођење на интерфејс тунела: out-interface=VPN_NAME на RouterOS-у, -o tun0 на Linux-у, одговарајући унос излазног NAT-а на pfSense-у. Правило masquerade без тог ограничења преписује саобраћај који сте хтели да оставите на миру, а симптом је да уређај ван тунела губи јавну адресу.

LAN изузетак ствара више тема подршке него сам тунел. Ако означена табела држи само подразумевану руту, одредиште штампача или NAS-а са изабраног уређаја поклапа се са тим подразумеваним и нестаје у тунелу. Додајте LAN руту у исту табелу, или искључите локалну подмрежу у бирачу; оба раде, а искључење је лакше одржати исправним када касније додате VLAN-ове.

DNS иде посебним путем. Упити које рутер прослеђује потичу од рутера и прате OUTPUT, а не прослеђену ознаку, па потпуно тунелисан лаптоп и даље може да разрешава имена преко ISP-а. Усмерите клијенте на resolver доступан кроз тунел, или означите саобраћај port-53 самог рутера, па проверите разрешену адресу уместо да претпоставите да је одговор путовао заједно са веб захтевом.

Када се правило поклапа, али апликација и даље користи WAN

Листе одредишта брзо старе. Име се разрешава на адресу које нема на листи, па захтев иде преко WAN-а, док је сваки тест који сте радили на наведеној адреси радио. Освежите листу из истог resolver-а који користи клијент, и дајте предност бирачу заснованом на извору када заиста желите сав саобраћај са једног уређаја.

IPv6 је тихи заобилаз. Уређај има другу фамилију адреса са сопственом подразумеваном рутом и сопственим скупом правила, а поклапање само IPv4 адресе је пола политике. Примените исти бирач на ip6tables или еквивалент nftables, или намерно искључите IPv6 на том сегменту, а не случајно.

Успостављене везе су такође важне. Унос conntrack-а направљен пре измене наставља старим путем док не истекне, па прегледач који је остао отворен током уређивања изгледа тачно као правило које никада није примењено. Отворите нову везу, или очистите стање, пре него што процените политику.

Проверите са два уређаја и рестартом

Тестирајте уређај који би требало да буде у тунелу и уређај који не би требало, и упоредите други хоп уместо броја брзине. Traceroute са сваког показује или гејтвеј тунела или ISP гејтвеј на другом хопу; ако оба изгледају исто, ознака или табела не раде оно што правило каже. За тест користите нове везе.

Затим рестартујте. Редослед подизања је место где радна политика постаје покварена, јер клијент мора бити подигнут пре него што се инсталира недоступна рута, а сачувани снимак који враћа стари скуп правила преписаће вашу табелу. Проверите да је свако правило у сачуваној конфигурацији и да означена подразумевана рута постоји после подизања, не само након што сте је откуцали.

Ако нешто не успе, прво уклоните ознаку и видите да ли се нормалан саобраћај враћа, а затим уклоните табелу. Тај редослед вам каже да ли јурите проблем рутирања или firewall-а, и оставља домаћинству штампач који ради док завршавате посао.