SOCKS5 starpniekserveris OpenVPN: TCP tunelis vai lietotņu starpniekošana?
Starpniekserveris pārraida straumi, nevis datagrammu. Salīdziniet TCP tuneli aiz socks-proxy ar redsocks novirzīšanu un skatiet, kur katra konstrukcija sabrūk pirmā.
Tīkli, kas pieļauj izeju tikai caur starpniekserveri, ir vieta, kur strādājošs profils pēkšņi nomirst. Starpniekservera adrese ir vismazāk interesantais mainīgais šajā neveiksmē. Visu nosaka tā satiksmes forma, ko starpniekserveris pārraidīs, jo šie starpniekserveri pārsūta baitu straumi, un UDP tunelis tāds nav. Tas atstāj divas arhitektūras, un tās lūzt dažādās vietās.
Viens ierobežojums nosaka konstrukciju
SOCKS5 patiešām nosaka UDP asociācijas režīmu. Tomēr OpenVPN klienta starpniekservera atbalsts ir veidots ap straumēm: socks-proxy ir dokumentēts TCP profiliem, un HTTP CONNECT starpniekserverim vispār nav ceļa datagrammām. Viena dokumentācijas rinda nosaka arhitektūru, pirms pieskaraties konfigurācijas failam.
Tātad jautājums nav, kuru starpniekserveri izvēlēties. Jautājums ir, vai tunelis kļūst par straumi vai paliek datagramma un ļauj kaut kam citam absorbēt starpniekošanu.
A variants: pārvērst tuneli straumē
Tam vajadzīgs serveris ar TCP klausītāju un klienta profils, kas nosauc starpniekserveri. Abas daļas ir vajadzīgas, un servera puse ir tā, ko cilvēki aizmirst:
proto tcp-client
remote vpn.example.net 443
socks-proxy 127.0.0.1 1080Aizstājiet pēdējo rindu ar http-proxy proxy.internal 8080, kad starpniekserveris runā HTTP, un pievienojiet akreditācijas datu failu, ja tas to pieprasa. Starpniekserverim jābūt gatavam izpildīt CONNECT uz jūsu VPN portu, un serverim jāatbild pa TCP; klausītājs tikai UDP šo mēģinājumu ignorē. 443 izvēle ir praktisks solis, jo daudzi ierobežojoši tīkli pieļauj to un maz ko citu.
Cena ir TCP, kas sakrauts uz TCP. Viens pazaudēts ārējais segments aptur katru iekšējo straumi, kas dala šo savienojumu, tāpēc atjaunošanās, kas parasti būtu neatkarīga, kļūst kopīga. Iestatīšana arī aizņem ilgāku laiku, un nestabils ārējais ceļš kļūst par nestabilu tuneli, nevis lēnu.
B variants: atstāt tuneli mierā
Kad tunelim jāpaliek uz UDP, tunelis nav vieta, kur kaut ko konfigurējat. Tā vietā izejošais TCP no lietotnēm tiek novirzīts uz vietējo SOCKS klausītāju, un lietotnes nekad neuzzina, ka starpniekserveris pastāv. Linux tas parasti ir redsocks un NAT REDIRECT noteikums nat tabulā.
Atkal tikai TCP. Tikai HTTP starpniekserveris, piemēram, privoxy, nevar pārraidīt patvaļīgus protokolus, un šī konstrukcija arī nepievieno datagrammu atbalstu lietotnēm.
Pastāstīt katrai lietotnei par starpniekserveri tieši parasti ir labāk tur, kur programmatūra to atbalsta. To ir vieglāk auditēt, un tas sabrūk vietā, ko jūs patiešām redzat.
Kur katra konstrukcija sabrūk
A variants sabrūk, kad serverim trūkst TCP klausītāja, kad starpniekserveris atsakās no CONNECT mērķa vai kad ārējā straume tiek ierobežota zem tā, kas tunelim vajadzīgs. Pirmie divi atstāj ierakstu starpniekservera žurnālā; trešais atstāj savienojumu, kas izveidojas un pēc tam šķiet nepareizs. Izlasiet šo žurnālu pirms profila rediģēšanas, jo tas atdala atļauju problēmu no jaudas problēmas. Pabeigts CONNECT pārvieto izmeklēšanu tuneļa iekšienē.
B variants sabrūk visam, kam vajadzīgas datagrammas, protokoliem, ko starpniekserveris nesaprot, un klusi tiem resursdatoriem, kur novirzīšanas noteikums pastāv, bet maršrutēšana sūta satiksmi tam garām.
Neviens variants nemaina ierīces prasību. Paketēm joprojām vajadzīgs TUN vai TAP mezgls, pirms kodols tās maršrutē, tāpēc procesam joprojām vajadzīga atļauja /dev/net/tun. Ietvars maina to, kas notiek pēc šī mezgla atvēršanas, nevis to, vai jums tas ir vajadzīgs.
Pierādiet, kuru ceļu izveidojāt
Skatieties uz ligzdām, nevis uz teknējuma ikonu. VPN procesam jāuztur izveidots savienojums ar starpniekservera adresi, un starpniekserverim bija jāreģistrē mērķis, uz kuru tam tika lūgts nokļūt:
ss -tnp | grep openvpnPēc tam dodieties uz galamērķi, kuru var apkalpot tikai tunelis, un uz vārdu, uz kuru var atbildēt tikai tuneļa atrisinātājs. Pabeigts starpniekservera savienojums ar mirušu tuneli parasti nozīmē, ka tālā puse nekad nav piedāvājusi jūsu profilā nosaukto transportu.
Pierakstiet transportu un pieņemošo starpniekserveri noturīgā vietā. Kad tas pats profils sabrūk citā tīklā, šī piezīme dažu sekunžu laikā izslēdz vai apstiprina starpniekserveri.