OpenVPN tra SOCKS5: kongruigi version, transporton kaj DNS

SOCKS-ĉeno fiaskas, kiam la proksia versio, la transporto aŭ la DNS-vojo ne kongruas. Kongruigu SOCKS5, portu TCP kaj tenu la ĉenon ene de unu nomspaco.

Unu elirejo el ĉi tiu laborejo estas SOCKS-proksio, kaj OpenVPN malantaŭ ĝi raportas tempolimon de konekto sen iu ajn utila detalo. La retumilo sur la sama maŝino funkcias tra tiu proksio, la akreditaĵoj estas ĝustaj kaj la pordo respondas. Tri aferoj sufiĉe ofte malsamas por esti kontrolataj unue: la SOCKS-versio, kiun parolas la proksio, la transporto, kiun elektis la kliento, kaj la loko, kie okazas la nom-resolvo. Konfirmu ĉiun el ili antaŭ ol kulpigi la fajroŝirmilon.

Kongruigu la SOCKS-version antaŭ la fajroŝirmilo

Komunuma OpenVPN parolas SOCKS5 por socks-proxy. Direktu ĝin al proksio, kiu ofertas nur SOCKS4, kaj la TCP-konekto malfermiĝas kaj poste haltas, ĉar la kliento atendas respondon al salutado, kiun la alia flanko neniam analizas. De ekstere tiu halto aspektas ĝuste kiel filtrita pordo, tial la demando pri la versio venas antaŭ ĉiu ajn fajroŝirmila regulo. Unu elŝuto kun SOCKS-scio solvas ĝin per unu komando.

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

Plenumita peto pruvas du aferojn samtempe: la proksio akceptis la SOCKS-peton kaj ĝi solvis la nomon. URL-skemo ne necesas, ĉar curl traktas nudan gastiganton kiel HTTP, kaj tio sufiĉas por ĉi tiu testo.

Tiu elŝuto ankaŭ ekskludas la fiaskon, kiun kaŝas la klienta protokolo. Proksio povas permesi la retumilon kaj tamen rifuzi la VPN-celon, kaj tiam la rifuzo okazas ĉe CONNECT, antaŭ iu ajn VPN-aŭtentikigo. OpenVPN raportas nur tempolimon, do la propra respondo de la proksio estas la pruvo, kiun vi bezonas.

La transporto devas esti TCP ambaŭflanke

SOCKS5 portas ĉi tie TCP-fluon, do la tunelo mem bezonas proto tcp-client. Profilo ankoraŭ agordita al UDP ne funkcios laŭ ĉi tiu vojo, ĉar la kliento ne uzas la UDP-asocian reĝimon de la protokolo. Renversi la profilon estas vera ŝanĝo, ne formalaĵo: la malproksima flanko devas aŭskulti TCP ĉe la sama pordo. Poste la ŝarĝo fariĝas TCP ene de TCP, kie perdita segmento estas resendata dufoje kaj la takto malboniĝas, kion interagaj sesioj sentas multe pli ol grandaj transigoj.

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

La direktivo prenas la proksian gastiganton, laŭvolan pordon kaj laŭvolan akreditaĵdosieron. Metu ilin en la profilon mem, por ke kopio aliloke kondutu same.

Enfermu la tutan ĉenon en unu ujo

Fari la ĉenon sur la gastiganto signifas transpreni ĝian defaŭltan vojon kaj lasi la solvilon en stato, kiun neniu poste povos klarigi. Nomspaco aŭ ujo limigas ĝin anstataŭe, do la gastiganto konservas sian propran vojon dum la SOCKS-salto kaj la tunelo vivas kune. Nenio leviĝas interne sen tunela aparato, rajtoj por agordi ĝin kaj atingebla proksio. Compose-servo akiras tion per cap_add: NET_ADMIN kaj bind-muntita /dev/net/tun.

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

Tiu paro estas pli mallarĝa ol ruli la ujon kun ĉiuj rajtoj, kaj ĝi estas la tuta necesa aparata aliro. Tor-kliento aŭ aparta proksiujo povas provizi la aŭskultanton. En ambaŭ kazoj ligigu ĝin al loopback kaj atingu ĝin el la nomspaco tra la gastiganto anstataŭ elmeti la proksion al la reto.

Nom-resolvo estas la loko, kie la izolado fiaskas

Tunelo, kiu portas pakaĵojn sed tamen demandas la solvilon de la gastiganto, izolis nenion. Du aferoj igas la izoladon reala: la nomspaco havas propran solvilon, kaj ĝiaj demandoj iras tra la proksio aŭ la tunelo, neniam tra la fizika interfaco. Uzu du nomojn por la testo: unu, kiu ekzistas nur malantaŭ la tunelo, kaj publikan, kiu devus sekvi la saman vojon.

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

Se la malproksima nomo solviĝas kaj la publika ne, la ĉeno estas elekta kaj ne rompita, kaj la diferenco diras, kiun vojon ĉiu demando iris. Se ambaŭ solviĝas el la gastiganto sed neniu interne de la ujo, la ujo ankoraŭ prunteprenas la solvilon de la gastiganto. Notu la trovitan solvilan dosieron, ĉar tiu estas la agordo, kiun oni devas ŝanĝi.

Pruvu ĉiun salton laŭ ordo

La listo estas mallonga. SOCKS5-peto ricevas respondon, la tunelo atingas sian aŭskultanton tra la proksio, kaj pakaĵoj forlasantaj la nomspacon portas la adreson, kiun la malproksima flanko atendas. Konfirmu unu post unu anstataŭ aldoni pli da agordo. Kiam la kliento diras konektita kaj nenio moviĝas, la rompo preskaŭ ĉiam estas en la dua aŭ tria fakto.

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

Notu la kombinon, kiu funkciis: SOCKS-versio, transporto, solvilo kaj nomspacaj agordoj. Solvi ĉi tiun ĉenon duan fojon el memoro kostas pli ol la noto. Tenu tiujn kvar faktojn en la bileto, ne en la babilejo.

Ĉeno, kiu raportas konektita kaj trapasigas nenion, kutime fiaskis ĉe la salto, kiun vi ankoraŭ ne pruvis. Testu tiun salton antaŭ ol aldoni alian tavolon.

Rilataj artikoloj