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, транспорт, разрешувач и поставки на именскиот простор. Решавањето на овој синџир вторпат по памтење чини повеќе од белешката. Чувајте ги тие четири факти во тикетот, а не во четот.

Синџир што пријавува „поврзано“ и не пропушта ништо, обично се скршил на чекорот што сѐ уште не сте го докажале. Проверете го тој чекор пред да додадете уште еден слој.

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