WireGuard арқылы бір қолданба: байлау — маршруттау емес

Параметр әр қолданбаға арналған ажыратқыш сияқты көрінеді, сол себепті адамдар клиентті WireGuard интерфейсіне байлап, туннельді тек сол клиент қолданады деп күтеді. Байлау шын мәнінде бастапқы адресті таңдайды. Содан кейін ядро межелі орынға маршрут іздейді, әдеттегі әдепкі маршрутты табады және пакетті туннель адресін қосып, физикалық арна арқылы жібереді. Ниетті тек сол бастапқы адрес үшін таңдалған маршрут орындайды.

Механизмнің екі жартысы бар: тек туннель трафигі пайдалануы тиіс маршруттау кестесі және сәйкес бастапқы адресті сонда жіберетін ереже.

Байлау бастапқы адресті қояды, одан артық емес

Linux шығу интерфейсін маршруттау кестесінде межені іздеу арқылы таңдайды, бұл іздеуді саясат ережелері басқа жаққа бұру мүмкіндігін алғаннан кейін болады. Ережелер бастапқы адрес, файрвол белгісі, кіріс интерфейсі, UID немесе тіпті порт бойынша таңдай алады; әрқайсысы барлық трафик емес, осы трафик деп айтудың басқа жолы. VPN клиентінің конфигурациясы туннель маршруттары бар кестені таңдайды; ереже қай трафикке оған жүгінуге рұқсат екенін таңдайды. Тек байлау екеуін де бермейді.

Сондықтан бұл сәтсіздік сонша таңғаларлық көрінеді. Қолданба туннель адресін сөзсіз пайдаланып тұр, туннель сөзсіз жұмыс істеп тұр, ал трафик сөзсіз дұрыс емес интерфейстен шығып жатыр. Әр тұжырым ақиқат және олар бірге адресті маршрутпен ештеңе байланыстырмаған жүйені сипаттайды.

Туннельге өз кестесін беріңіз

wg-quick маршруттарды профиль айтқан жерге орнатады. [Interface] астына Table = 40 қосу оларды негізгі кестенің орнына 40 кестесіне көшіреді. Интерфейсті көтеріп, олардың жеткенін растаңыз: ip -4 route ls table 40 туннель маршруттарын көрсетуі керек, ал ip -4 route get 10.66.127.142 ядроның қазір олардың бірін қалай шешетінін көрсетеді. Маршруттар өз кестесінде болғанда негізгі кесте қалғанның бәрі үшін жұмысын жалғастырады.

IPv6 үшін де солай жасаңыз, кең префиксті сәйкестендірудің орнына. ip -6 rule add from fd00::2/128 lookup 40 бір адресті бекітеді; fc00::/8 хосттағы басқа интерфейстермен қақтығысып, көзделгеннен көбін сәйкестендіретін ереже жасауы мүмкін.

Бастапқы адрес ережесін қосып, есептегіштерді қараңыз

Содан кейін екі жартыны қосыңыз: ip -4 rule add from 10.66.127.142/32 lookup 40, сол адресті WireGuard интерфейсіне тіркеп. Екі ережені де PostUp ішіне қойыңыз, қайта қосылу оларды қалпына келтірсін. Параметрмен емес, нақты сұраныспен тексеріңіз: ip route get 1.1.1.1 from 10.66.127.142 туннель құрылғысын атауы керек, ал curl --interface wg0 ifconfig.me үй адресінің орнына туннель адресін хабарлауы керек.

Әлі де сәтсіз болса, ip -s rule оқыңыз. Бар болғанымен ешқашан сәйкеспейтін ереже нөлдік есептегіштерді көрсетеді және бұл қате ережені ереженің мүлде жоқтығынан ажыратады. Сол бір пәрмен қолданба өз интерфейс параметрін елемеді ме деген болжамды азайтады.

Кері жағдай: SSH-ты туннельден тыс ұстаңыз

Қарама-қарсы мәселе де соншалықты жиі: wg-quick әдепкі маршрутқа ие және серверге SSH сессиясы ортасында үзіледі. Оның ережелері төмен басымдық нөмірінде тұр, сондықтан ерекшелік олардан бұрын бағалануы керек. ip rule add dport 22 ipproto tcp table main priority 123 мұны жаңа iproute2-де жасайды; селектор қолжетімсіз жерде ағынды nftables-те белгілеп, оның орнына белгіні сәйкестендіріңіз.

Жауап жолын да тексеріңіз. Орнатылып, содан кейін үнсіз қалатын SSH сессиясында әдетте асимметриялық маршруттау болады: бір бағыт туннельден, екіншісі физикалық интерфейстен шығады. Сервер адресі үшін ip route get жауаптың қай жаққа кететінін айтады.

Кесте нөмірін, бастапқы адрес ережесін және ерекшелікті профильдің өзіне жазыңыз. Үшеуі де бір дизайнға жатады және бірге өңделеді.