SOCKS5 proxy pre OpenVPN: TCP tunel alebo proxy pre aplikácie?

Proxy prenáša tok, nie datagram. Porovnajte TCP tunel za socks-proxy s presmerovaním redsocks a pozrite sa, kde každý návrh zlyhá prvý.

Sie, ktoré povoľujú odchádzajúcu prevádzku len cez proxy, sú miestom, kde funkčný profil zrazu umiera. Adresa proxy je v tomto zlyhaní najmenej zaujímavá premenná. Všetko rozhoduje podoba prevádzky, ktorú bude proxy prenášať, pretože tieto proxy prenášajú bajtový tok a UDP tunel ním nie je. Zostávajú dve architektúry a každá padá na inom mieste.

O návrhu rozhoduje jedno obmedzenie

SOCKS5 síce špecifikuje režim asociácie UDP. Podpora proxy v klientovi OpenVPN je však postavená okolo tokov: socks-proxy je dokumentovaný pre profily TCP a proxy HTTP CONNECT nemá pre datagramy žiadnu cestu. Jeden riadok dokumentácie rozhodne o architektúre skôr, než sa dotknete konfiguračného súboru.

Otázka teda nie je, ktorú proxy zvoliť. Ale či sa tunel stane tokom, alebo zostane datagramom a nechá proxyovanie pohltiť niečím iným.

Varianta A: urobte z tunela tok

To vyžaduje server s TCP poslucháčom a klientsky profil, ktorý proxy pomenuje. Obe časti sú potrebné a na tú serverovú sa zabúda:

proto tcp-client
remote vpn.example.net 443
socks-proxy 127.0.0.1 1080

Nahraďte posledný riadok za http-proxy proxy.internal 8080, keď proxy hovorí HTTP, a pridajte súbor s prihlasovacími údajmi, ak ho vyžaduje. Proxy musí byť ochotná vykonať CONNECT na váš port VPN a server musí odpovedať na TCP; poslucháč iba na UDP tento pokus ignoruje. Voľba 443 je praktický ťah, pretože mnohé reštriktívne siete povoľujú ju a máloco iné.

Cena je TCP naskladané na TCP. Jeden stratený vonkajší segment zablokuje každý vnútorný tok, ktorý to spojenie zdieľa, takže obnova, ktorá by inak bola nezávislá, sa stáva zdieľanou. Nastavenie tiež trvá dlhšie a nestabilná vonkajšia cesta sa zmení na nestabilný tunel, nie na pomalý.

Varianta B: nechajte tunel na pokoji

Keď musí tunel zostať na UDP, tunel nie je miesto, kde čokoľvek konfigurujete. Namiesto toho sa odchádzajúci TCP z aplikácií presmeruje na miestny poslucháč SOCKS a aplikácie sa nikdy nedozvedia, že proxy existuje. Na Linuxe to býva redsocks spolu s pravidlom NAT REDIRECT v tabuľke nat.

Opäť len TCP. Proxy iba pre HTTP ako privoxy nedokáže prenášať ľubovoľné protokoly a tento návrh aplikáciám nepridá podporu datagramov.

Povedať každej aplikácii o proxy priamo je zvyčajne lepšie tam, kde to softvér podporuje. Ľahšie sa to audituje a zlyháva na mieste, ktoré skutočne vidíte.

Kde ktorá varianta zlyháva

Varianta A zlyháva, keď serveru chýba TCP poslucháč, keď proxy odmietne cieľ CONNECT alebo keď je vonkajší tok obmedzený pod to, čo tunel potrebuje. Prvé dve nechajú záznam v logu proxy; tretia nechá spojenie, ktoré sa nadviaže a potom pôsobí nesprávne. Prečítajte si ten log pred úpravou profilu, pretože oddeľuje problém oprávnení od problému kapacity. Dokončený CONNECT presunie vyšetrovanie dovnútra tunela.

Varianta B zlyháva pri všetkom, čo potrebuje datagramy, pri protokoloch, ktorým proxy nerozumie, a ticho na hostiteľoch, kde pravidlo presmerovania existuje, ale smerovanie posiela prevádzku mimo neho.

Ani jedna varianta nemení požiadavku na zariadenie. Pakety stále potrebujú uzol TUN alebo TAP, kým ich jadro nasmeruje, takže proces stále potrebuje oprávnenie na /dev/net/tun. Obal mení, čo sa stane po otvorení tohto uzla, nie to, či ho potrebujete.

Dokážte, ktorú cestu ste postavili

Pozerajte sa na sockety, nie na ikonu v oznamovacej oblasti. Proces VPN má držať nadviazané spojenie s adresou proxy a proxy mala zalogovať cieľ, na ktorý bola požiadaná:

ss -tnp | grep openvpn

Potom sa vyberte k cieľu, ktorý dokáže obslúžiť len tunel, a k názvu, na ktorý dokáže odpovedať len resolver tunela. Dokončené spojenie cez proxy s mŕtvym tunelom zvyčajne znamená, že vzdialená strana nikdy neponúkla transport uvedený vo vašom profile.

Zapíšte si transport a prijímajúcu proxy na trvalé miesto. Keď ten istý profil zlyhá v inej sieti, tá poznámka proxy v priebehu sekúnd vylúči alebo potvrdí.

Súvisiace články