SOCKS5 прокси за OpenVPN: TCP тунел или проксирање на апликациите?

Проксито пренесува тек, а не датаграм. Споредете TCP тунел зад socks-proxy со пренасочување redsocks и видете каде секој дизајн прв се крши.

Мрежите што дозволуваат излез само преку прокси се местото каде работен профил одеднаш умира. Адресата на проксито е најмалку интересната променлива во тој неуспех. Сѐ одлучува формата на сообраќајот што проксито ќе го пренесе, бидејќи овие проксија пренесуваат бајтен тек, а 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, и додајте датотека со акредитиви ако бара. Проксито мора да биде подготвено да изврши CONNECT на вашата VPN порта, а серверот мора да одговори на TCP; слушач само на UDP го игнорира обидот. Изборот на 443 е практичен чекор, бидејќи многу ограничувачки мрежи дозволуваат тоа и малку друго.

Цената е TCP нареден врз TCP. Еден изгубен надворешен сегмент го блокира секој внатрешен тек што го дели тоа поврзување, па закрепнувањето што инаку би било независно станува заедничко. Поставувањето исто така трае подолго, а нестабилна надворешна патека станува нестабилен тунел, а не бавен.

Опција Б: оставете го тунелот на мир

Кога тунелот мора да остане на UDP, тунелот не е местото каде што конфигурирате нешто. Наместо тоа, излезниот TCP од апликациите се пренасочува кон локален SOCKS слушач, и апликациите никогаш не дознаваат дека постои прокси. На Linux тоа обично е redsocks плус правило NAT REDIRECT во табелата nat.

Повторно само TCP. Прокси само за HTTP како privoxy не може да пренесува произволни протоколи, а овој дизајн не додава ниту поддршка за датаграми за апликациите.

Да се каже на секоја апликација директно за проксито обично е подобро таму каде што софтверот го поддржува. Полесно е да се ревидира, и се крши на место што навистина можете да го видите.

Каде се крши секоја опција

Опцијата А се крши кога на серверот му недостига TCP слушач, кога проксито ја одбива целта CONNECT, или кога надворешниот тек е ограничен под она што му е потребно на тунелот. Првите две оставаат запис во дневникот на проксито; третото остава врска што се воспоставува и потоа изгледа погрешно. Прочитајте го тој дневник пред да го уредите профилот, бидејќи го одделува проблемот со дозвола од проблемот со капацитет. Завршен CONNECT ја преместува истрагата внатре во тунелот.

Опцијата Б се крши за сѐ што бара датаграми, за протоколи што проксито не ги разбира, и тивко на домаќини каде правилото за пренасочување постои, но рутирањето го испраќа сообраќајот покрај него.

Ниту една опција не го менува барањето за уредот. Пакетите сѐ уште бараат TUN или TAP јазол пред јадрото да ги рутира, така што процесот сѐ уште бара дозвола на /dev/net/tun. Обвивката менува што се случува откако тој јазол е отворен, а не дали ви е потребен.

Докажете кој пат го изградивте

Гледајте во сокетите, а не во иконата во системскиот треј. VPN процесот треба да држи воспоставена врска со адресата на проксито, а проксито требало да ја евидентира целта до која било побарано да стигне:

ss -tnp | grep openvpn

Потоа упатете се кон одредиште што само тунелот може да го опслужи, и кон име на кое само решавачот на тунелот може да одговори. Завршена прокси врска со мртов тунел обично значи дека далечната страна никогаш не го понудила транспортот наведен во вашиот профил.

Запишете го транспортот и проксито што прифаќа на трајно место. Кога истиот профил ќе се скрши на друга мрежа, таа белешка го исклучува или потврдува проксито во секунди.

Поврзани статии