OpenVPN үшін SOCKS5 проксиі: TCP туннелі ме, әлде қолданбаларды проксилеу ме?

Тек прокси арқылы шығуға рұқсат беретін желілер — жұмыс істеп тұрған профиль кенет өлетін жер. Прокси мекенжайы сол сәтсіздіктегі ең қызықсыз айнымалы. Барлығын прокси жіберетін трафиктің пішіні шешеді, өйткені бұл проксилер байт ағынын жібереді, ал UDP туннелі олай емес. Бұл екі архитектура қалдырады және олар әртүрлі жерде сынады.

Дизайнды бір шектеу шешеді

SOCKS5 шынымен UDP бірлестік режимін анықтайды. Дегенмен OpenVPN клиентінің прокси қолдауы ағындар төңірегінде құрылған: socks-proxy TCP профильдері үшін құжатталған, ал HTTP CONNECT проксиінің датаграммаларға жолы мүлдем жоқ. Құжаттаманың бір жолы конфигурация файлына қол тигізбес бұрын архитектураны шешеді.

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

А нұсқасы: туннельді ағынға айналдыру

Бұл үшін TCP тыңдаушысы бар сервер және проксиді атайтын клиент профилі керек. Екі бөлік те міндетті, ал адамдар ұмытатыны — сервер жағы:

proto tcp-client
remote vpn.example.net 443
socks-proxy 127.0.0.1 1080

Соңғы жолды http-proxy proxy.internal 8080 ауыстырыңыз, прокси HTTP сөйлейтін болса, және қажет етсе тіркелгі деректерінің файлын қосыңыз. Прокси VPN портыңызға CONNECT орындауға дайын болуы керек, ал сервер TCP бойынша жауап беруі керек; тек UDP тыңдаушысы әрекетті елемейді. 443 таңдау практикалық қадам, өйткені көптеген шектеулі желілер соған және аз нәрсеге рұқсат береді.

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

Б нұсқасы: туннельді жалғыз қалдыру

Туннель UDP-де қалуы керек болса, туннель — бірдеңе конфигурациялайтын орын емес. Оның орнына қолданбалардан шығатын TCP жергілікті SOCKS тыңдаушысына қайта бағытталады, ал қолданбалар проксидің бар екенін ешқашан білмейді. Linux-те бұл әдетте redsocks және nat кестесіндегі NAT REDIRECT ережесі.

Тағы да тек TCP. privoxy сияқты тек HTTP проксиі ерікті протоколдарды жібере алмайды, және бұл дизайн қолданбаларға датаграмма қолдауын да қоспайды.

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

Әр нұсқа қайда сәтсіздікке ұшырайды

А нұсқасы серверде TCP тыңдаушысы болмағанда, прокси CONNECT мақсатынан бас тартқанда немесе сыртқы ағын туннельге қажет деңгейден төмен шектелгенде сәтсіздікке ұшырайды. Алғашқы екеуі прокси журналында жазба қалдырады; үшіншісі орнап, содан кейін дұрыс емес сезілетін байланыс қалдырады. Профильді өңдеуден бұрын сол журналды оқыңыз, өйткені ол рұқсат мәселесін сыйымдылық мәселесінен ажыратады. Аяқталған CONNECT тергеуді туннельдің ішіне жылжытады.

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

Екі нұсқаның ешқайсысы құрылғы талабын өзгертпейді. Пакеттерге әлі де ядро маршруттауы үшін TUN немесе TAP түйіні қажет, сондықтан процесс әлі де /dev/net/tun рұқсатын қажет етеді. Қаптама сол түйін ашылғаннан кейін не болатынын өзгертеді, оның керек пе-жоғын емес.

Қай жолды салғаныңызды дәлелдеңіз

Науа белгішесіне емес, сокеттерге қараңыз. VPN процесі прокси мекенжайына орнатылған байланысты ұстауы керек, ал прокси одан сұралған мақсатты журналға жазуы керек еді:

ss -tnp | grep openvpn

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

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