Саясат бойынша маршруттау және SOCKS: трафикті шын мәнінде қай қабат проксилейді

Сіз VPN клиентінің трафигін 1080 портында SOCKS тыңдаушысы жұмыс істейтін хостқа жіберетін саясат маршрутын қостыңыз. Пакеттер келеді, тыңдаушы ештеңе жазбайды, қосылым ілініп қалады. Маршрутта ешбір қате жоқ: келесі секіріс пакеттің қайда баратынын таңдайды, ал SOCKS — клиент бастауға тиіс әңгіме. Адамдар трафикті прокси арқылы жіберу деп әдетте нені түсінетінің үш архитектурасын салыстырыңыз, сонда орнатуыңызда қай бөлік жетіспейтіні анық болады.

Маршруттау, DNAT және SOCKS әртүрлі нәрселерді өзгертеді

Саясат маршруты 3-қабаттың шешімін қайта жазады. Бір клиенттің трафигін таңдалған келесі секіріске жіберу үшін екі жол жеткілікті:

ip route add default via 10.50.0.2 table 101
ip rule add from 10.77.0.2 lookup 101

Осыдан кейін ядро пакетті 10.50.0.2-ге береді, ал бастапқы межелі орын IP тақырыбында қалады. Егер 10.50.0.2 маршруттаушы болса, ол пакетті жібереді. Егер ол 1080 портында SOCKS демоны бар хост болса, пакет оны қабылдай алатын ешнәрсеге адрестелмеген, және 1080 портына DNAT та көмектеспейді, өйткені түрлендірілген пакет әлі де SOCKS сәлемдесуінің орнына қолданбаның бастапқы жүктемесін алып жүреді.

SOCKS5 нұсқа байтынан, әдістер тізімінен, аутентификация алмасуынан және межелі орынды атайтын сұраныстан басталады. Бұл қолданба деректері. Ешбір маршруттау жазбасы да, netfilter мақсаты да оны жасамайды, және бір жолдағы салыстыру осы: маршруттау жол таңдайды, SOCKS серверден екінші қосылым жасауды сұрайды.

Бірінші жағдай: қолданбаның өзі SOCKS сөйлей алады

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

curl --socks5 10.50.0.2:1080 https://docs.example.com
curl --socks5-hostname 10.50.0.2:1080 https://internal.example.com

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

Екінші жағдай: IP ағындарын прокси сессияларына түрлендіретін адаптер

SOCKS сөйлей алмайтын бағдарламалар үшін түрлендіру IP трафигін тоқтататын және олардың атынан прокси сессияларын ашатын нәрседе болуы керек. Бұл компоненттің туннель интерфейсі бар, саясаттық маршруттау таңдаған ағындарды қабылдайды, әрқайсысы үшін SOCKS қол алысуды орындайды және жауаптарды қайта құрастырады. Маршрут трафикті оған бағыттайды; сессияны жасайтын — адаптер.

Оны бүкіл қосалқы желіге сеніп тапсырмас бұрын құжаттамасын оқыңыз. Көптеген адаптерлер TCP-ны жақсы тасымалдайды және UDP-мен тек SOCKS5 UDP қауымдастығы арқылы жұмыс істейді, және олардың ешқайсысы ICMP-ны прокси трафигіне айналдырмайды, сондықтан сәтті ping прокси жолы туралы ештеңе айтпайды. DNS — басқа тұзақ: егер адаптер атауларды жергілікті шешсе, тек ішкі жазбалар дұрыс емес жауапқа немесе мүлдем ештеңеге шешіледі.

Циклдердің алдын алу — тістеп алатын операциялық бөлшек. Адаптердің SOCKS серверіне өз қосылымдары қайтадан адаптерге маршрутталмауы керек, сондықтан оның трафигіне ережедегі ерекшелік немесе жеке бастау адресі қажет. Мұны қате жасасаңыз, прокси сессиясы өзін проксилеуге тырысады.

Үшінші жағдай: хост шын мәнінде маршрутталған шлюз

Кейде жұмыс істеп тұрған орнатуда SOCKS мүлдем болмайды. Қашықтағы хост пакеттерді жібереді немесе оларға NAT жасайды, ал бастауға негізделген ереже оны шығу ретінде таңдайды. Бұл дизайн заңды, және көшірілген конфигурацияның бір желіде жұмыс істеп, екіншісінде неге сәтсіз болатынын түсіндіреді: ереже бірдей, жетіспейтін бөлік — арғы жақтағы жіберу қызметі.

Үш жағдай тез ажырайды. Шын мәнінде не тыңдап тұрғанын тексеріңіз, содан кейін хостқа жететін алғашқы байттарды қараңыз:

ss -ltnp 'sport = :1080'
tcpdump -ni eth0 -X 'tcp port 1080'

Нағыз SOCKS клиентінің алғашқы жүктеме байты — 0x05, сәлемдесудегі нұсқа. Егер түсірілім оның орнына бастапқы қолданба деректерін көрсетсе, ешбір SOCKS демоны жауап бермейді, өйткені келіссөз ешқашан басталмаған. Егер 1080 портында ештеңе тыңдамаса, хост — шлюз, ал сұрақ оның жібере ме және қайтару жолы бар ма дегенге айналады.

Қабатты төрт сұрақпен таңдаңыз

Бағдарламада прокси параметрі бар ма? Оны пайдаланып, сол жерде тоқтаңыз. Трафикте аман қалуы керек UDP немесе ICMP бар ма? ICMP-ны тек маршрутталған немесе NAT шлюзі тасымалдайды, ал UDP-ға екі жақ та қолдайтын SOCKS5 қауымдастығы қажет. Машинадағы әрбір процесті, оның ішінде конфигурациялай алмайтындарыңызды да қамту керек пе? Онда интерфейске ие және ағындарды тоқтататын адаптер керек. Оның маршруттауын, DNS-ін және циклдердің алдын алу ерекшеліктерін де өз мойныңызға ала аласыз ба? Олай болмаса, қарапайым шлюзді пайдалану арзанырақ болады.

Бір айырмашылықты анық ұстаған жөн. VPN клиентінің өз socks-proxy опциясы сыртқы туннель қосылымының өз серверіне қалай жететінін сипаттайды және ішкі клиент ағындарын түрлендіру туралы ештеңе айтпайды. Бұл екеуі бір билетте үнемі шатастырылады. Маршрутқа тимес бұрын қандай қатынас керектігін шешіңіз.