OpenVPN caur SOCKS5: saskaņojiet versiju, transportu un DNS

Viena izeja no šīs darbstacijas ir SOCKS starpniekserveris, un aiz tā esošais OpenVPN ziņo par savienojuma taimautu bez nekā noderīga. Pārlūks tajā pašā mašīnā darbojas caur šo starpniekserveri, akreditācijas dati ir pareizi, un ports atbild. Trīs lietas pietiekami bieži atšķiras, lai tās vispirms pārbaudītu: SOCKS versija, ko runā starpniekserveris, transports, ko izvēlējies klients, un kur notiek vārdu izšķiršana. Apstipriniet katru no tām, pirms nolemjat, ka vainīgs ir ugunsmūris.

Saskaņojiet SOCKS versiju pirms ugunsmūra

Kopienas OpenVPN runā SOCKS5 socks-proxy vajadzībām. Novirziet to uz starpniekserveri, kas piedāvā tikai SOCKS4, un TCP savienojums atveras, tad iestrēgst, jo klients gaida atbildi uz sveicienu, ko otrs gals nekad neapstrādā. No ārpuses šī iestrēgšana izskatās tieši kā filtrēts ports, tāpēc versijas jautājums nāk pirms jebkura ugunsmūra noteikuma. SOCKS izprotošs pieprasījums to atrisina ar vienu komandu.

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

Pabeigts pieprasījums pierāda divas lietas uzreiz: starpniekserveris pieņēma SOCKS pieprasījumu un tas izšķīra vārdu. URL shēma nav vajadzīga, jo curl tukšu resursdatoru uzskata par HTTP, ar ko šim testam pietiek.

Šis pieprasījums arī izslēdz kļūmi, ko slēpj klienta žurnāls. Starpniekserveris var atļaut pārlūku un tomēr atteikt VPN galamērķi, un tādā gadījumā atteikums notiek pie CONNECT, pirms jebkuras VPN autentifikācijas. OpenVPN ziņo tikai par taimautu, tāpēc paša starpniekservera atbilde ir vajadzīgais pierādījums.

Transportam abās pusēs jābūt TCP

SOCKS5 šeit pārvieto TCP plūsmu, tāpēc pašam tunelim vajag proto tcp-client. Profils, kas joprojām iestatīts uz UDP, pa šo ceļu nestrādās, jo klients neizmanto protokola UDP asociācijas režīmu. Profila pārslēgšana ir īsta izmaiņa, nevis formalitāte: otram galam tajā pašā portā jāklausās TCP. Kravnesība tad kļūst TCP TCP iekšienē, kur pazaudēts segments tiek pārsūtīts divreiz un temps pasliktinās, ko interaktīvās sesijas pamana daudz vairāk nekā lieli pārsūtījumi.

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

Direktīva ņem starpniekservera resursdatoru, neobligātu portu un neobligātu akreditācijas datu failu. Ielieciet tos pašā profilā, lai kopija citur uzvestos identiski.

Ierobežojiet visu ķēdi vienā konteinerā

Ķēdes veikšana resursdatorā nozīmē pārņemt tā noklusējuma maršrutu un atstāt šķīrēju stāvoklī, ko vēlāk neviens nevar izskaidrot. Namespace vai konteiners to ierobežo, tāpēc resursdators patur savu ceļu, kamēr SOCKS lēciens un tunelis dzīvo kopā. Iekšā nekas nepaceļas bez tuneļa ierīces, tiesībām to konfigurēt un sasniedzama starpniekservera. Compose pakalpojums to iegūst ar cap_add: NET_ADMIN un bind piesaistītu /dev/net/tun.

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

Šis pāris ir šaurāks par konteinera palaišanu ar privileģijām, un tas ir viss nepieciešamais ierīces piekļuves apjoms. Klausītāju var nodrošināt Tor klients vai atsevišķs starpniekservera konteiners. Abos gadījumos piesaistiet to loopback un sasniedziet no namespace caur resursdatoru, nevis atklājot starpniekserveri tīklam.

Vārdu izšķiršana ir vieta, kur izolācija neizdodas

Tunelis, kas pārvieto paketes un prasa resursdatora šķīrēju, neko nav izolējis. Divas lietas padara izolāciju īstu: namespace ir savs šķīrējs, un tā vaicājumi ceļo caur starpniekserveri vai tuneli, nekad pa fizisko saskarni. Testam izmantojiet divus vārdus: vienu, kas pastāv tikai aiz tuneļa, un publisku, kam vajadzētu iet to pašu ceļu.

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

Ja tālās puses vārds izšķiras un publiskais ne, ķēde ir selektīva, nevis salauzta, un atšķirība pasaka, kuru ceļu gāja katrs vaicājums. Ja abi izšķiras no resursdatora, bet neviens konteinera iekšienē, konteiners joprojām aizņemas resursdatora šķīrēju. Pierakstiet atrasto šķīrēja failu, jo tas ir iestatījums, kas jāmaina.

Pierādiet katru lēcienu secībā

Saraksts ir īss. SOCKS5 pieprasījums saņem atbildi, tunelis caur starpniekserveri sasniedz savu klausītāju, un paketes, kas atstāj namespace, nes adresi, ko gaida tālā puse. Apstipriniet katru atsevišķi, nevis kārtojot vēl vairāk konfigurācijas. Kad klients saka, ka ir savienots, un nekas ne kustas, lūzums gandrīz vienmēr ir otrajā vai trešajā faktā.

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

Pierakstiet kombināciju, kas strādāja: SOCKS versija, transports, šķīrējs un namespace iestatījumi. Atrisināt šo ķēdi otro reizi no atmiņas maksā vairāk nekā piezīme. Turiet šos četrus faktus biļetē, nevis tērzēšanas pavedienā.

Ķēde, kas ziņo par savienojumu un neko nelaida cauri, parasti ir kritusi lēcienā, kuru vēl neesat pierādījis. Pārbaudiet šo lēcienu, pirms pievienojat vēl vienu slāni.