Redsocks loopback-те тыңдайды, бірақ VPN трафигі ешқашан жетпейді

Туннель көтеріледі, клиент шлюзге ping жібере алады, бірақ прокси жолымен өтетін әрбір веб сұраныс өледі. redsocks процесі жұмыс істеп тұр және оның порты тыңдап тұр, сондықтан қызмет шлюздің өзінен сау көрінеді. Сәтсіздікке ұшырайтыны — жеткізу кезеңі: туннельден бағытталған пакет сіз іске қосқан socket-ке түспейді. Байланыс мекенжайы мен бағыттау мақсаты сәйкес келуі керек, ал әдетте олардың тек біреуі ғана тексеріледі.

Бағытталған пакет шын мәнінде қайда түседі

Шлюздегі мөлдір прокси PREROUTING-тегі nat кестесіндегі REDIRECT арқылы кіріс қосылысының межелі жерін жергілікті портқа қайта жазады. Қайта жазылған межелі жер — пакет келген интерфейстен көрінетін жергілікті мекенжай, ал басқа жерде іске қосылған процестің loopback мекенжайы емес. Тек 127.0.0.1-ге байланған тыңдаушы хостта бұрыннан жергілікті болған қосылыстарды қабылдайды, ал туннель трафигі сәтсіз болған кезде жұмысын жалғастыратын жағдай дәл осы. Клиенттің өз loopback-і үшінші мекенжай және ешқашан шлюз ережесінің мақсаты болмайды.

Сондықтан жоғарғы деңгей тіркелгі деректеріне қол тигізбес бұрын екі фактіні анықтаңыз: ереже қай жергілікті мекенжайға қайта жазады және прокси socket-і қай мекенжайға байланған.

Тыңдаушы мен бағыттау ережесін бірге оқыңыз

Socket кестесі мен nat ережелерін бір өтуде басып шығарыңыз, өйткені ешкімге тиесілі емес портқа сілтейтін ереже қате мекенжайға сілтейтін ережемен бірдей көрінеді. sudo ss -ltnp | grep redsocks байланыс мекенжайы мен иесі процесс көрсетеді. sudo iptables -t nat -S PREROUTING REDIRECT мақсатын көрсетеді, ал sudo iptables -t nat -L PREROUTING -v -n оған бірдеңе сәйкес келгенін көрсетеді.

REDSOCKS аталған пайдаланушы тізбегіне секіру, егер бұл тізбек болмаса және көзделген ерекшеліктер мен REDIRECT әрекетін алып жүрмесе, ештеңе бермейді. Атауы жұмысты жасайды деп болжаудың орнына, ол секіретін тізбекті sudo iptables -t nat -S REDSOCKS арқылы оқыңыз.

Сосын екі мәнді салыстырыңыз. Егер ереже 12345 портындағы шлюз мекенжайына бағыттаса, ал тыңдаушы 127.0.0.1:12345 деп хабарласа, сәйкессіздік сәтсіздікті қосымша диагностикасыз түсіндіреді.

Тар байланыстырыңыз, сосын оған не жете алатынын шектеңіз

Жоғарғы деңгей үлгі конфигурациясы тыңдаушыны жақсы себеппен loopback-ке қояды: мөлдір прокси оған жете алатын кез келген адамның атынан қосылыстарды қабылдайды. Байланысты 0.0.0.0-ге өзгерту жеткізуді түзетеді және бір уақытта әрбір интерфейсте портты ашады, бұл қауіпсіздік өзгерісі, бейтарап жөндеу емес. Бағыттау мақсат еткен нақты жергілікті мекенжайға байланыстыруды қалаңыз және сенімсіз интерфейстерде портты жабық ұстаңыз. Кеңірек байланыс сөзсіз болса, тек туннель бастау диапазоны мен шлюздің өз жергілікті трафигіне рұқсат беретін хост брандмауэр ережесін қосыңыз.

Жалпыға ортақ интерфейсте портты ашу бағытталған VPN трафигі үшін ешқашан қажет емес, өйткені қосылыс қайта жазғаннан кейін жергілікті түрде аяқталады. Жергілікті бағыттау жұмыс істеуі үшін проксиді интернетке ашпаңыз.

Оны клиенттен жаңа қосылыспен дәлелдеңіз

Шлюздегі shell-ден емес, нақты VPN клиентінен жаңа TCP қосылысымен тексеріңіз. Клиенттегі curl -sS -o /dev/null -w '%{http_code}\n' http://example.com бағытталған жолды басынан аяғына дейін жүргізеді.

Сосын сенімсіз желіден тыңдаушыға тікелей қосылыс әлі де қабылданбайтынын және проксидің өз жоғарғы қосылысы сол ережемен қайта ұсталмайтынын растаңыз. Рекурсивті ұстау өзіне қосылатын және сұранысты ешқашан аяқтамайтын прокси ретінде көрінеді. Проксидің межелі жерін ерекшеліктер жиынына қосыңыз немесе оның шығыс пакеттерін белгілеңіз, сонда тізбек оларды аттап өтеді.

Соңында бұл жол нені қамтымайтынын есте сақтаңыз. Кәдімгі redsocks TCP бағыттауы UDP, QUIC немесе DNS-ті SOCKS трафигіне айналдырмайды, ал жеке межелі жерлер әдетте айқын ерекшеліктерді қажет етеді. Сәтті жергілікті тест тек ешқашан мәселе болмаған loopback жолын дәлелдейді.