OpenVPN üle SOCKS5: sobitage versioon, transport ja DNS

SOCKS-kett ebaõnnestub, kui puhverserveri versioon, transport või DNS-teekond ei klapi. Sobitage SOCKS5, kandke TCP-d ja hoidke kett nimeruumi sees.

Üks väljapääs sellest tööjaamast on SOCKS-puhverserver ja selle taga olev OpenVPN teatab ühenduse ajalõpust ilma ühegi kasuliku lisandita. Samas masinas olev brauser töötab selle puhverserveri kaudu, volitused on õiged ja port vastab. Kolm asja erinevad piisavalt sageli, et neid kõigepealt kontrollida: puhverserveri kõneldav SOCKS-versioon, kliendi valitud transport ja kus toimub nimede lahendamine. Kinnitage igaüks neist enne, kui otsustate, et tulemüür on süüdi.

Sobitage SOCKS-i versioon enne tulemüüri

Kogukonna OpenVPN räägib SOCKS5-te socks-proxy jaoks. Suunake see puhverserverile, mis pakub ainult SOCKS4, ning TCP-ühendus avaneb ja siis takerdub, sest klient ootab vastust tervitusele, mida teine pool kunagi ei parsi. Väljast näeb see takerdumine täpselt välja nagu filtreeritud port, mistõttu versiooniküsimus tuleb enne iga tulemüürireeglit. SOCKS-teadlik päring lahendab selle ühe käsuga.

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

Lõpetatud päring tõestab korraga kahte asja: puhverserver võttis SOCKS-päringu vastu ja lahendas nime. URL-i skeemi pole vaja, sest curl käsitleb paljast hosti HTTP-na, millest selle testi jaoks piisab.

See päring välistab ka vea, mille kliendi logi peidab. Puhverserver võib brauseri lubada ja siiski VPN-i sihtkoha tagasi lükata, ning sel juhul toimub tagasilükkamine CONNECT-i juures, enne igasugust VPN-i autentimist. OpenVPN teatab ainult ajalõpust, seega on puhverserveri enda vastus tõend, mida vajate.

Transport peab olema TCP mõlemal poolel

SOCKS5 kannab siin TCP-voogu, seega vajab tunnel ise proto tcp-client. Profiil, mis on endiselt UDP peal, ei tööta sellel teel, sest klient ei kasuta protokolli UDP-assotsiatsiooni režiimi. Profiili ümberlülitamine on tõeline muudatus, mitte formaalsus: kaugpool peab samal pordil TCP-d kuulama. Kasulik koormus muutub seejärel TCP-ks TCP sees, kus kadunud segment saadetakse kaks korda uuesti ja tempo halveneb, mida interaktiivsed seansid märkavad palju rohkem kui suured ülekanded.

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

Direktiiv võtab puhverserveri hosti, valikulise pordi ja valikulise volituste faili. Pange need profiili enda sisse, et koopia käituks mujal samamoodi.

Piirake kogu kett ühte konteinerisse

Keti tegemine hostis tähendab selle vaikimisi marsruudi ülevõtmist ja resolveri jätmist olekusse, mida keegi hiljem seletada ei oska. Nimeruum või konteiner piirab seda hoopis, nii et host hoiab oma teekonda, samal ajal kui SOCKS-hüpe ja tunnel koos elavad. Seal sees ei tõuse miski ilma tunneliseadme, selle seadme seadistamise õiguste ja kättesaadava puhverserverita. Compose-teenus saab selle cap_add: NET_ADMIN ja bind-mountitud /dev/net/tun abil.

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

See paar on kitsam kui konteineri privilegeeritult käivitamine ja moodustab kogu vajaliku seadmejuurdepääsu. Kuulaja võib anda Tori klient või eraldi puhverserveri konteiner. Mõlemal juhul siduge see loopbacki külge ja jõudke selle juurde nimeruumist hosti kaudu, selle asemel et puhverserver võrku paljastada.

Nimede lahendamine on koht, kus isolatsioon ebaõnnestub

Tunnel, mis kannab pakette, aga küsib hosti resolverit, ei ole midagi isoleerinud. Kaks asja teevad isolatsiooni tõeliseks: nimeruumil on oma resolver ja selle päringud liiguvad läbi puhverserveri või tunneli, mitte kunagi füüsilise liidese kaudu. Kasutage testiks kahte nime: ühte, mis eksisteerib ainult tunneli taga, ja avalikku, mis peaks järgima sama teed.

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

Kui kaugpoolne nimi laheneb ja avalik mitte, on kett valiv, mitte katki, ja erinevus ütleb teile, millise tee iga päring läbis. Kui mõlemad lahenevad hostist, aga mitte ükski konteineri sees, laenab konteiner endiselt hosti resolverit. Kirjutage üles leitud resolverifail, sest see on seade, mida tuleb muuta.

Tõestage iga hüpe järjekorras

Nimekiri on lühike. SOCKS5-päring saab vastuse, tunnel jõuab puhverserveri kaudu oma kuulajani ja nimeruumist lahkuvad paketid kannavad aadressi, mida kaugpool ootab. Kinnitage igaüht ükshaaval, selle asemel et laduda peale rohkem konfiguratsiooni. Kui klient ütleb, et on ühendatud, ja miski ei liigu, on katkestus peaaegu alati teises või kolmandas faktis.

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

Kirjutage üles kombinatsioon, mis töötas: SOCKS-i versioon, transport, resolver ja nimeruumi seaded. Selle keti teist korda mälu järgi lahendamine maksab rohkem kui märkus. Hoidke need neli fakti piletis, mitte vestluslõimes.

Kett, mis teatab ühendusest ja laseb midagi läbi, on tavaliselt ebaõnnestunud hüppel, mida te veel tõestanud pole. Testige seda hüpet enne veel ühe kihi lisamist.

Seotud artiklid