OpenVPN SOCKS5 felett: hangold össze a verziót, a transzportot és a DNS-t

A SOCKS-lánc akkor hibázik, ha a proxy verziója, a transzport vagy a DNS-útvonal nem egyezik. Válaszd a SOCKS5-öt, vigyél TCP-t, és tartsd a láncot egy namespace-en belül.

Ebből a munkaállomásból az egyik kivezető út egy SOCKS-proxy, és a mögötte lévő OpenVPN kapcsolódási időtúllépést jelent, használható részletek nélkül. Ugyanezen a gépen egy böngésző működik ezen a proxyn keresztül, a hitelesítő adatok rendben vannak, és a port válaszol. Három dolog tér el elég gyakran ahhoz, hogy először ezeket ellenőrizzük: a proxy által beszélt SOCKS-verzió, a kliens által választott transzport és az, hogy hol történik a névfeloldás. Erősítsd meg mindegyiket, mielőtt a tűzfalat okolnád.

A SOCKS-verziót a tűzfal előtt hangold össze

A közösségi OpenVPN SOCKS5-öt beszél a socks-proxy számára. Irányítsd olyan proxyra, amely csak SOCKS4-et kínál: a TCP-kapcsolat megnyílik, majd elakad, mert a kliens egy olyan üdvözlésre vár válaszra, amelyet a másik fél soha nem dolgoz fel. Kívülről ez az elakadás pontosan szűrt portnak látszik, ezért a verzió kérdése minden tűzfalszabály előtt jön. Egy SOCKS-tudatos lekérés egyetlen paranccsal eldönti.

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

Egy befejezett kérés egyszerre két dolgot bizonyít: a proxy elfogadta a SOCKS-kérést, és feloldotta a nevet. Nem kell URL-séma, mert a curl a csupasz hosztot HTTP-ként kezeli, ami ehhez a teszthez elég.

Ez a lekérés kizárja azt a hibát is, amelyet a kliensnapló elrejt. A proxy engedélyezheti a böngészőt, és mégis elutasíthatja a VPN-célt; ilyenkor az elutasítás a CONNECTnél történik, minden VPN-hitelesítés előtt. Az OpenVPN csak időtúllépést jelent, ezért a proxy saját válasza a szükséges bizonyíték.

A transzportnak mindkét oldalon TCP-nek kell lennie

A SOCKS5 itt TCP-folyamot visz, ezért magának az alagútnak proto tcp-client kell. Az UDP-re állított profil ezen az úton nem működik, mert a kliens nem használja a protokoll UDP-asszociációs módját. A profil átállítása valódi változás, nem formaság: a túlsó végnek ugyanazon a porton TCP-n kell figyelnie. A hasznos teher ekkor TCP lesz TCP-ben, ahol az elveszett szegmens kétszer kerül újraküldésre, és a tempó romlik, amit az interaktív munkamenetek sokkal jobban észrevesznek, mint a nagy átvitelek.

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

Az utasítás a proxy hosztját, egy opcionális portot és egy opcionális hitelesítőfájlt vesz át. Tedd ezeket magába a profilba, hogy a másolat máshol ugyanígy viselkedjen.

Szorítsd az egész láncot egyetlen konténerbe

A lánc a hoszton való futtatása azt jelenti, hogy átveszed az alapértelmezett útvonalát, és a feloldót olyan állapotban hagyod, amelyet később senki nem tud megmagyarázni. Egy namespace vagy egy konténer ehelyett körülhatárolja, így a hoszt megtartja a saját útját, miközben a SOCKS-ugrás és az alagút együtt él. Bent semmi nem indul el alagúteszköz, az eszköz konfigurálásához szükséges jogok és egy elérhető proxy nélkül. Egy Compose-szolgáltatás ezt cap_add: NET_ADMIN és egy bind-mountolt /dev/net/tun segítségével kapja meg.

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

Ez a pár szűkebb, mint a konténer kiemelt jogosultságokkal futtatása, és ez a teljes szükséges eszközhozzáférés. A figyelőt egy Tor-kliens vagy egy külön proxykonténer biztosíthatja. Mindkét esetben kösd loopbackhez, és a namespace-ből a hoszton keresztül érd el, ahelyett hogy a proxyt a hálózatnak tennéd ki.

A névfeloldás az, ahol az izoláció megbukik

Egy alagút, amely csomagokat visz, miközben a hoszt feloldóját kérdezi, semmit nem izolált. Két dolog teszi valódivá az izolációt: a namespace-nek saját feloldója van, és a lekérdezései a proxyn vagy az alagúton keresztül utaznak, soha nem a fizikai interfészen. Használj két nevet a teszthez: egyet, amely csak az alagút mögött létezik, és egy nyilvánosat, amelynek ugyanazt az utat kellene követnie.

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

Ha a túloldali név feloldódik, a nyilvános pedig nem, a lánc szelektív, nem törött, és a különbség megmondja, melyik lekérdezés melyik utat választotta. Ha mindkettő feloldódik a hosztról, de egyik sem a konténeren belül, a konténer még mindig a hoszt feloldóját kölcsönzi. Jegyezd fel a megtalált feloldófájlt, mert az a beállítás, amelyet meg kell változtatni.

Bizonyítsd minden ugrást sorrendben

A lista rövid. Egy SOCKS5-kérés választ kap, az alagút a proxyn keresztül eléri a figyelőjét, és a namespace-t elhagyó csomagok azt a címet viszik, amelyet a túloldal vár. Mindegyiket egyenként erősítsd meg, ahelyett hogy további konfigurációt rétegeznél. Amikor a kliens azt mondja, hogy kapcsolódva van, és semmi nem mozdul, a törés szinte mindig a második vagy a harmadik tényben van.

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

Írd fel a működő kombinációt: SOCKS-verzió, transzport, feloldó és namespace-beállítások. Ennek a láncnak a másodszori, emlékezetből való megoldása többe kerül, mint a jegyzet. Tartsd ezt a négy tényt a jegyben, ne egy csevegésszálban.

Egy lánc, amely kapcsolódást jelent és semmit nem enged át, általában azon az ugráson bukott meg, amelyet még nem bizonyítottál. Teszteld azt az ugrást, mielőtt még egy réteget hozzáadnál.

Kapcsolódó cikkek