OpenVPN SOCKS5:n yli: sovita versio, siirto ja DNS

Yksi reitti ulos tältä työasemalta on SOCKS-välityspalvelin, ja sen takana OpenVPN raportoi yhteyden aikakatkaisun ilman mitään hyödyllistä tietoa. Saman koneen selain toimii kyseisen välityspalvelimen kautta, tunnukset ovat oikein ja portti vastaa. Kolme asiaa eroaa tarpeeksi usein, jotta ne kannattaa tarkistaa ensin: SOCKS-versio, jota välityspalvelin puhuu, asiakkaan valitsema siirto ja paikka, jossa nimen selvitys tapahtuu. Vahvista jokainen ennen kuin syytät palomuuria.

Sovita SOCKS-versio ennen palomuuria

Community-OpenVPN puhuu SOCKS5:tä socks-proxy-kohdassa. Ohjaa se välityspalvelimeen, joka tarjoaa vain SOCKS4:n, ja TCP-yhteys avautuu ja pysähtyy, koska asiakas odottaa vastausta tervehdykseen, jota toinen pää ei koskaan jäsenna. Ulkoa katsottuna pysähdys näyttää täsmälleen suodatetulta portilta, siksi versiokysymys tulee ennen mitään palomuurisääntöä. Yksi SOCKS-tietoinen nouto ratkaisee sen yhdellä komennolla.

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

Valmis pyyntö todistaa kaksi asiaa kerralla: välityspalvelin hyväksyi SOCKS-pyynnön ja se selvitti nimen. URL-kaaviota ei tarvita, koska curl kohtelee paljasta isäntää HTTP:nä, ja se riittää tähän testiin.

Se nouto sulkee pois myös vian, jonka asiakasloki kätkee. Välityspalvelin voi sallia selaimen ja silti hylätä VPN-kohteen, jolloin hylkäys tapahtuu CONNECT-vaiheessa, ennen mitään VPN-todennusta. OpenVPN raportoi vain aikakatkaisun, joten välityspalvelimen oma vastaus on tarvitsemasi todiste.

Siirron on oltava TCP molemmilla puolilla

SOCKS5 kuljettaa tässä TCP-virtaa, joten itse tunneli tarvitsee proto tcp-client. UDP:hen yhä asetettu profiili ei toimi tätä reittiä, koska asiakas ei käytä protokollan UDP-liittymistilaa. Profiilin kääntäminen on todellinen muutos eikä muodollisuus: toisen pään on kuunneltava TCP:tä samassa portissa. Sitten hyötykuorma on TCP:tä TCP:n sisällä, jossa kadonnut segmentti lähetetään uudelleen kahdesti ja tahti heikkenee, minkä vuorovaikutteiset istunnot huomaavat paljon suurempia siirtoja enemmän.

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

Direktiivi ottaa välityspalvelimen isännän, valinnaisen portin ja valinnaisen tunnustiedoston. Aseta ne itse profiiliin, jotta kopio käyttäytyy samoin muualla.

Sulje koko ketju yhteen konttiin

Ketjun tekeminen isännällä tarkoittaa sen oletusreitin valtaamista ja selvittäjän jättämistä tilaan, jota kukaan ei myöhemmin selitä. Nimiavaruus tai kontti rajaa sen sen sijaan, joten isäntä säilyttää oman reittinsä, kun SOCKS-hyppy ja tunneli elävät yhdessä. Sisällä mikään ei nouse ilman tunnelilaitetta, oikeuksia sen määrittämiseen ja tavoitettavissa olevaa välityspalvelinta. Compose-palvelu saa sen cap_add: NET_ADMIN:llä ja bind-mountatulla /dev/net/tun:llä.

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

Tämä pari on kapeampi kuin kontin ajaminen etuoikeutettuna, ja se on kaikki tarvittava laitekäyttö. Tor-asiakas tai erillinen välityspalvelinkontti voi tarjota kuuntelijan. Kummassakin tapauksessa sido se loopbackiin ja saavu siihen nimiavaruudesta isännän kautta sen sijaan, että altistat välityspalvelimen verkolle.

Nimen selvitys on se kohta, jossa eristys pettää

Tunneli, joka kuljettaa paketteja mutta kysyy silti isännän selvittäjältä, ei eristänyt mitään. Kaksi asiaa tekee eristyksestä todellisen: nimiavaruudella on oma selvittäjä, ja sen kyselyt kulkevat välityspalvelimen tai tunnelin kautta, eivät koskaan fyysisen liitännän kautta. Käytä testissä kahta nimeä: yhtä, joka on olemassa vain tunnelin takana, ja julkista, jonka pitäisi kulkea samaa reittiä.

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

Jos kaukonimi selvitetään mutta julkinen ei, ketju on valikoiva eikä rikki, ja ero kertoo, minkä reitin kukin kysely otti. Jos molemmat selvitetään isännältä mutta ei kumpaakaan kontissa, kontti lainaa yhä isännän selvittäjää. Kirjaa löytämäsi selvittäjätiedosto, koska juuri se asetus on muutettava.

Todista jokainen hyppy järjestyksessä

Luettelo on lyhyt. SOCKS5-pyyntö saa vastauksen, tunneli saavuttaa kuuntelijansa välityspalvelimen kautta ja nimiavaruudesta lähtevät paketit kantavat osoitteen, jota kaukopää odottaa. Vahvista yksi kerrallaan sen sijaan, että lisäät konfiguraatiota. Kun asiakas sanoo yhdistetty eikä mikään liiku, katkos on lähes aina toisessa tai kolmannessa tosiseikassa.

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

Kirjaa toimiva yhdistelmä: SOCKS-versio, siirto, selvittäjä ja nimiavaruuden asetukset. Tämän ketjun ratkaiseminen toisen kerran muistista maksaa enemmän kuin muistiinpano. Pidä ne neljä tosiseikkaa tikissä, älä chatissa.

Ketju, joka raportoi yhdistetty ja ei päästä mitään läpi, on yleensä epäonnistunut hypyssä, jota et vielä todistanut. Testaa se hyppy ennen kuin lisäät uuden kerroksen.