OpenVPN през SOCKS5: съгласуване на версия, транспорт и DNS

SOCKS веригата се проваля, когато версията на проксито, транспортът или пътят на DNS не съвпадат. Съгласувайте SOCKS5, пренасяйте TCP и дръжте веригата в едно пространство от имена.

Един от маршрутите навън от тази работна станция е SOCKS прокси и OpenVPN зад него съобщава за изтичане на времето за връзка без никакви полезни подробности. Браузърът на същата машина работи през това прокси, идентификационните данни са верни и портът отговаря. Три неща се разминават достатъчно често, за да се проверят първи: версията на SOCKS, на която говори проксито, транспортът, който клиентът е избрал, и мястото, където става разрешаването на имена. Потвърдете всяко от тях, преди да обвините защитната стена.

Съгласувайте версията на SOCKS преди защитната стена

Общностният OpenVPN говори SOCKS5 за socks-proxy. Насочете го към прокси, което предлага само SOCKS4, и TCP връзката се отваря, после застава, защото клиентът чака отговор на поздрав, който другата страна никога не разбира. Отвън това заставане изглежда точно като филтриран порт, затова въпросът за версията идва преди всяко правило на защитната стена. Едно изтегляне със знание за SOCKS решава това с една команда.

curl --socks5-hostname 127.0.0.1:9050 gw.lab.example

Завършена заявка доказва две неща наведнъж: проксито е приело SOCKS заявката и е разрешило името. Не е нужна URL схема, защото curl приема голо име на хост като HTTP и това е достатъчно за този тест.

Това изтегляне също изключва повредата, която журналът на клиента скрива. Проксито може да разреши браузъра и пак да откаже дестинацията на VPN, при което отказът става на CONNECT, преди каквото и да е удостоверяване на VPN. OpenVPN съобщава само за изтичане на времето, затова собственият отговор на проксито е доказателството, което ви трябва.

Транспортът трябва да е TCP от двете страни

Тук SOCKS5 носи TCP поток, затова самият тунел се нуждае от proto tcp-client. Профил, все още настроен на UDP, няма да работи по този път, защото клиентът не използва режима на UDP асоциация на протокола. Обръщането на профила е истинска промяна, а не формалност: далечната страна трябва да слуша TCP на същия порт. След това полезният товар става TCP в TCP, където загубеният сегмент се изпраща повторно два пъти и темпото се влошава, което интерактивните сесии усещат много повече от големите преноси.

proto tcp-client
remote gw.lab.example 8443
socks-proxy 127.0.0.1 9050

Директивата приема хоста на проксито, незадължителен порт и незадължителен файл с идентификационни данни. Поставете ги в самия профил, за да се държи копие другаде по същия начин.

Затворете цялата верига в един контейнер

Правенето на веригата на хоста означава да заемете маршрута му по подразбиране и да оставите разпознавача в състояние, което после никой не може да обясни. Пространство от имена или контейнер я ограничават вместо това, така че хостът пази своя път, докато SOCKS скокът и тунелът живеят заедно. Вътре нищо не се вдига без тунелно устройство, права за настройка на това устройство и достижимо прокси. Услуга на Compose получава това с cap_add: NET_ADMIN и bind-монтиран /dev/net/tun.

cap_add:
  - NET_ADMIN
devices:
  - /dev/net/tun:/dev/net/tun

Тази двойка е по-тясна от пускането на контейнера с привилегии и това е целият необходим достъп до устройството. Клиент на Tor или отделен контейнер за прокси може да осигури слушателя. И в двата случая го вържете към loopback и го достигнете от пространството от имена през хоста, вместо да излагате проксито в мрежата.

Разрешаването на имена е мястото, където изолацията се проваля

Тунел, който носи пакети и същевременно пита разпознавача на хоста, не е изолирал нищо. Две неща правят изолацията истинска: пространството от имена има свой разпознавач и неговите заявки минават през проксито или тунела, никога през физическия интерфейс. За теста използвайте две имена: едно, което съществува само зад тунела, и едно публично, което трябва да мине по същия път.

docker compose exec vpn cat /etc/resolv.conf
docker compose exec vpn getent hosts internal.lab.example

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

Докажете всеки скок по ред

Списъкът е кратък. SOCKS5 заявка получава отговор, тунелът достига слушателя си през проксито, а пакетите, напускащи пространството от имена, носят адреса, който далечната страна очаква. Потвърждавайте по едно, вместо да натрупвате конфигурация. Когато клиентът казва „свързано“, а нищо не се движи, скъсването почти винаги е във втория или третия факт.

curl --socks5-hostname 127.0.0.1:9050 gw.lab.example
docker compose exec vpn ip route get 203.0.113.10
docker compose exec vpn getent hosts internal.lab.example

Запишете комбинацията, която проработи: версия на SOCKS, транспорт, разпознавач и настройки на пространството от имена. Решаването на тази верига втори път по памет струва повече от бележката. Пазете тези четири факта в тикета, а не в чата.

Верига, която съобщава „свързано“ и не пропуска нищо, обикновено се е счупила на скока, който още не сте доказали. Проверете този скок, преди да добавите още един слой.

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