OpenVPN oor SOCKS5: pas weergawe, vervoer en DNS bymekaar

'n SOCKS-ketting faal wanneer die proxy-weergawe, die vervoer of die DNS-pad nie ooreenstem nie. Pas SOCKS5, dra TCP, en hou die ketting binne 'n naamruimte.

Een roete uit hierdie werkstasie is 'n SOCKS-proxy, en OpenVPN daaragter rapporteer 'n verbindingstimeout sonder enige nuttige besonderhede. 'n Blaaier op dieselfde masjien werk deur daardie proxy, die geloofsbriewe is korrek, en die poort antwoord. Drie dinge verskil dikwels genoeg om eerste na te kyk: die SOCKS-weergawe wat die proxy praat, die vervoer wat die kliënt gekies het, en waar naamresolusie plaasvind. Bevestig elkeen daarvan voordat jy besluit die firewall is skuldig.

Pas die SOCKS-weergawe aan voor die firewall

Gemeenskaps-OpenVPN praat SOCKS5 vir socks-proxy. Wys dit na 'n proxy wat net SOCKS4 bied, en die TCP-verbinding open, dan stagneer dit, want die kliënt wag vir 'n antwoord op 'n groet wat die ander kant nooit ontleed nie. Van buite lyk daardie stagnasie presies soos 'n gefiltreerde poort, en daarom kom die weergawevraag voor enige firewall-reël. 'n SOCKS-bewuste ophaling beslis dit in een opdrag.

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

'n Voltooide versoek bewys twee dinge gelyktydig: die proxy het die SOCKS-versoek aanvaar en dit het die naam opgelos. Geen URL-skema is nodig nie, want curl behandel 'n kaal gasheer as HTTP, wat vir hierdie toets genoeg is.

Daardie ophaling skakel ook die fout uit wat die kliëntlog versteek. 'n Proxy kan die blaaier toelaat en steeds die VPN-bestemming weier, en in daardie geval gebeur die weiering by CONNECT, voor enige VPN-verifikasie. OpenVPN rapporteer slegs 'n timeout, so die proxy se eie antwoord is die bewys wat jy nodig het.

Die vervoer moet aan beide kante TCP wees

SOCKS5 dra hier 'n TCP-stroom, so die tonnel self het proto tcp-client nodig. 'n Profiel wat steeds op UDP gestel is, sal nie deur hierdie pad werk nie, want die kliënt gebruik nie die protokol se UDP-assosiasiemodus nie. Om die profiel om te skakel is 'n werklike verandering eerder as 'n formaliteit: die ander kant moet op dieselfde poort na TCP luister. Die vrag word dan TCP binne TCP, waar 'n verlore segment twee keer herversend word en die tempo verswak, wat interaktiewe sessies baie meer opmerk as groot oordragte.

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

Die opdrag neem die proxy-gasheer, 'n opsionele poort en 'n opsionele geloofsbriewe-lêer. Sit dit in die profiel self sodat 'n kopie elders identies werk.

Beperk die hele ketting tot een houer

Om die ketting op die gasheer te doen, beteken om sy verstekroete oor te neem en die oplosser in 'n toestand te laat wat niemand later kan verduidelik nie. 'n Naamruimte of 'n houer beperk dit eerder, sodat die gasheer sy eie pad hou terwyl die SOCKS-hop en die tonnel saam bestaan. Niks kom daarbinne op sonder 'n tonneltoestel, die regte om daardie toestel te konfigureer, en 'n bereikbare proxy nie. 'n Compose-diens kry dit met cap_add: NET_ADMIN en 'n vasgemaakte /dev/net/tun.

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

Daardie paar is smaller as om die houer met volle regte te laat loop, en dit is die hele toesteltoegang wat nodig is. 'n Tor-kliënt of 'n aparte proxy-houer kan die luisteraar verskaf. Bind dit in elk geval aan loopback, en bereik dit vanuit die naamruimte deur die gasheer eerder as om die proxy aan die netwerk bloot te stel.

Naamresolusie is waar die isolasie misluk

'n Tonnel wat pakkette dra terwyl dit die gasheer se oplosser vra, het niks geïsoleer nie. Twee dinge maak die isolasie werklik: die naamruimte het 'n oplosser van sy eie, en sy navrae reis deur die proxy of die tonnel, nooit oor die fisiese koppelvlak nie. Gebruik twee name vir die toets: een wat net agter die tonnel bestaan, en 'n openbare een wat dieselfde pad behoort te volg.

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

As die verre naam oplos en die openbare een nie, is die ketting selektief eerder as stukkend, en die verskil vertel jou watter pad elke navraag geneem het. As albei van die gasheer af oplos maar nie een binne die houer nie, leen die houer steeds die gasheer se oplosser. Teken die oplosser-lêer aan wat jy gevind het, want dit is die instelling wat moet verander.

Bewys elke hop in volgorde

Die lys is kort. 'n SOCKS5-versoek kry 'n antwoord, die tonnel bereik sy luisteraar deur die proxy, en pakkette wat die naamruimte verlaat dra die adres wat die verre kant verwag. Bevestig elkeen op 'n slag eerder as om meer konfigurasie by te voeg. Wanneer die kliënt sê dit is gekonnekteer en niks beweeg nie, is die breuk byna altyd in die tweede of derde feit.

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

Skryf die kombinasie neer wat gewerk het: SOCKS-weergawe, vervoer, oplosser en naamruimte-instellings. Om hierdie ketting 'n tweede keer uit geheue op te los kos meer as die nota. Hou daardie vier feite in die kaartjie eerder as in 'n gespreksdraad.

'n Ketting wat sê dit is gekonnekteer en niks deurlaat nie, het gewoonlik misluk by die hop wat jy nog nie bewys het nie. Toets daardie hop voordat jy nog 'n laag byvoeg.

Verwante artikels