OpenVPN preko SOCKS5: uskladite verziju, transport i DNS

Jedna ruta iz ove radne stanice je SOCKS proxy, a OpenVPN iza njega prijavljuje timeout veze bez ičega korisnog. Preglednik na istom računalu radi kroz taj proxy, vjerodajnice su ispravne, a port odgovara. Tri stvari se često razlikuju dovoljno da ih prvo provjerite: verzija SOCKS-a koju proxy govori, transport koji je klijent odabrao i gdje se odvija razrješavanje imena. Potvrdite svaku od njih prije nego zaključite da je firewall kriv.

Uskladite SOCKS verziju prije firewalla

Community OpenVPN govori SOCKS5 za socks-proxy. Usmjerite ga na proxy koji nudi samo SOCKS4 i TCP veza se otvori, a zatim stane, jer klijent čeka odgovor na pozdrav koji drugi kraj nikada ne parsira. Izvana taj zastoj izgleda točno kao filtriran port, zato pitanje verzije dolazi prije svakog firewall pravila. SOCKS fetch to rješava jednom naredbom.

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

Završen zahtjev dokazuje dvije stvari odjednom: proxy je prihvatio SOCKS zahtjev i razriješio je ime. URL shema nije potrebna jer curl golubinji host tretira kao HTTP, što je za ovaj test dovoljno.

Taj fetch ujedno isključuje kvar koji klijentski log skriva. Proxy može dopustiti preglednik, a ipak odbiti VPN odredište, pri čemu se odbijanje događa na CONNECT, prije ikakve VPN autentifikacije. OpenVPN prijavljuje samo timeout, pa je proxyjev vlastiti odgovor dokaz koji vam treba.

Transport mora biti TCP na obje strane

SOCKS5 ovdje nosi TCP tok, pa sam tunel treba proto tcp-client. Profil koji je još postavljen na UDP neće raditi kroz ovu putanju, jer klijent ne koristi protokolov UDP asocijacijski način. Prebacivanje profila prava je promjena, a ne formalnost: drugi kraj mora slušati na TCP-u na istom portu. Teret tada postaje TCP unutar TCP-a, gdje se izgubljeni segment ponovno šalje dva puta i tempo opada, što interaktivne sesije primjećuju mnogo više od velikih prijenosa.

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

Direktiva prima proxy host, opcionalni port i opcionalnu datoteku vjerodajnica. Stavite ih u sam profil kako bi se kopija drugdje ponašala identično.

Ograničite cijeli lanac na jedan kontejner

Raditi lanac na hostu znači preuzeti njegovu zadanu rutu i ostaviti resolver u stanju koje nitko kasnije ne može objasniti. Namespace ili kontejner to umjesto toga ograničava, pa host zadržava svoju putanju dok SOCKS skok i tunel žive zajedno. Ništa se unutra ne podiže bez tunelskog uređaja, prava za konfiguraciju tog uređaja i dostupnog proxyja. Compose servis to dobiva s cap_add: NET_ADMIN i bind-montiranim /dev/net/tun.

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

Taj je par uži od pokretanja kontejnera s privilegijama i čini cijeli potrebni pristup uređaju. Tor klijent ili zasebni proxy kontejner mogu osigurati listener. U oba slučaja vežite ga na loopback i dohvatite iz namespacea preko hosta umjesto da proxy izlažete mreži.

Razrješavanje imena je mjesto gdje izolacija pada

Tunel koji nosi pakete, a pita hostov resolver, nije izolirao ništa. Dvije stvari čine izolaciju stvarnom: namespace ima vlastiti resolver, a njegovi upiti putuju kroz proxy ili tunel, nikada preko fizičkog sučelja. Za test koristite dva imena: jedno koje postoji samo iza tunela i jedno javno koje bi trebalo slijediti istu putanju.

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

Ako se ime s druge strane razriješi, a javno ne, lanac je selektivan, a ne pokvaren, i razlika vam kaže kojom je putanjom išao koji upit. Ako se oba razriješe s hosta, ali nijedno unutar kontejnera, kontejner još posuđuje hostov resolver. Zabilježite datoteku resolvera koju ste našli, jer je to postavka koja se mora promijeniti.

Dokažite svaki hop redom

Popis je kratak. SOCKS5 zahtjev dobiva odgovor, tunel kroz proxy stiže do svog listenera, a paketi koji napuštaju namespace nose adresu koju drugi kraj očekuje. Potvrdite svaki pojedinačno umjesto da dodajete još konfiguracije. Kada klijent kaže da je spojen, a ništa se ne kreće, prekid je gotovo uvijek u drugoj ili trećoj činjenici.

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

Zapišite kombinaciju koja je radila: SOCKS verzija, transport, resolver i postavke namespacea. Ponovno rješavanje ovog lanca po pamćenju košta više od bilješke. Držite te četiri činjenice u ticketu, a ne u chat niti.

Lanac koji prijavljuje vezu, a ništa ne propušta, obično je pao na hopu koji još niste dokazali. Testirajte taj hop prije nego dodate još jedan sloj.