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 жолун гана далилдейт.