Еден уред низ рутерски VPN бара три правила, а не прекинувач
Еден уред низ рутерски VPN е политичко рутирање, а не квадратче: означена табела, ограничено NAT правило, плус DNS, IPv6 и LAN патеки што водичите ги прескокнуваат.
На рутерски 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, и му остава на домаќинството печатач што работи додека ја завршувате работата.