SOCKS5 прокси за OpenVPN: 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 и додајте датотеку са акредитивима ако је тражи. Прокси мора бити спреман да изврши 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

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

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