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

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

Запишете транспорта и приемащото прокси на трайно място. Когато същият профил се провали в друга мрежа, тази бележка изключва или потвърждава проксито за секунди.

Подобни статии