SOCKS5-proxy foar OpenVPN: TCP-tunnel of de apps proxye?

In proxy ferfiert in stream, gjin datagram. Ferlykje in TCP-tunnel efter socks-proxy mei in redsocks-omlieding en sjoch wêr't elk ûntwerp it earst bejouwt.

Netwurken dy't allinnich útgeande ferkear fia in proxy tastean, binne it plak dêr't in wurkjend profyl ynienen dea giet. It proxy-adres is de minst nijsgjirrige fariabele yn dy flater. Alles wurdt beslist troch de foarm fan it ferkear dat de proxy ferfiert, want dizze proxy's stjoere in bytestream en in UDP-tunnel is dat net. Dat lit twa arsjitektueren oer, en se brekke op ferskate plakken.

Ien beheining beslút it ûntwerp

SOCKS5 spesifisearret wol in UDP-assosjaasjemodus. De proxy-stipe fan 'e OpenVPN-klant is lykwols om streamen hinne boud: socks-proxy is dokumintearre foar TCP-profylen, en in HTTP CONNECT-proxy hat hielendal gjin paad foar datagrammen. Ien rigel dokumintaasje beslút de arsjitektuer foardat jo in konfiguraasjebestân oanreitsje.

De fraach is dus net hokker proxy jo kieze. It is oft de tunnel in stream wurdt, of in datagram bliuwt en eat oars it proxying opfange lit.

Opsje A: meitsje de tunnel in stream

Dat freget in server mei in TCP-harker, en in kliïntprofyl dat de proxy neamt. Beide stikken binne nedich, en de serverside is dejinge dy't minsken ferjitte:

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

Ferfange de lêste rigel troch http-proxy proxy.internal 8080, as de proxy HTTP praat, en foegje in oanmeldbestân ta as it dat easket. De proxy moat ree wêze om CONNECT nei jo VPN-poarte te dwaan, en de server moat op TCP antwurdzje; in harker dy't allinnich UDP is, negearret de poging. 443 kieze is in praktyske set, om't in protte beheinende netwurken dat en hast neat oars tastean.

De kosten binne TCP op TCP steapele. Ien ferlern bûtenste segmint stelt elke binnenste stream stil dy't dat ferbining dielt, dat herstel dat normaal ûnôfhinklik wêze soe, wurdt dield. De opset duorret ek langer, en in wifkôpich bûtenpaad wurdt in wifkôpige tunnel ynstee fan in stadige.

Opsje B: lit de tunnel gewurde

As de tunnel op UDP bliuwe moat, is de tunnel net it plak dêr't jo eat konfigurearje. Ynstee wurdt útgeande TCP fan applikaasjes omlaat nei in pleatslike SOCKS-harker, en de applikaasjes leare nea dat in proxy bestiet. Op Linux is dat meastentiids redsocks plus in NAT REDIRECT-regel yn 'e nat-tabel.

Wer allinnich TCP. In proxy dy't allinnich HTTP is, lykas privoxy, kin gjin willekeurige protokollen ferfiere, en dit ûntwerp foeget ek gjin datagramstipe foar de applikaasjes ta.

Elke applikaasje direkt oer de proxy fertelle is meastentiids better dêr't de software dat stipet. It is makliker te auditearjen, en it bejout him op in plak dat jo echt sjen kinne.

Wêr't elke opsje bejout

Opsje A bejout him as de server in TCP-harker mist, as de proxy it CONNECT-doel wegert, of as de bûtenstream beheind wurdt ûnder wat de tunnel nedich hat. De earste twa litte in ynskriuwing yn it proxylog; de tredde lit in ferbining efter dy't him fêstiget en dan ferkeard fielt. Lês dat log foardat jo it profyl bewurkje, om't it in tastimmingprobleem fan in kapasiteitsprobleem skiedt. In foltôge CONNECT ferpleatst it ûndersyk de tunnel yn.

Opsje B bejout him foar alles dat datagrammen nedich hat, foar protokollen dy't de proxy net begrypt, en stil op hosts dêr't de omliedingsregel bestiet mar de routing it ferkear der bylâns stjoert.

Gjin fan beide opsjes feroaret de eask fan it apparaat. Pakketten hawwe noch altyd in TUN- of TAP-knooppunt nedich foardat de kernel se routet, dat it proses hat noch altyd tastimming nedich op /dev/net/tun. In wikkel feroaret wat der bart neidat dat knooppunt iepen is, net oft jo ien nedich hawwe.

Bewiis hokker paad jo boud hawwe

Sjoch nei sockets ynstee fan it tray-ikoan. It VPN-proses moat in fêstige ferbining nei it proxy-adres hâlde, en de proxy moat it doel logd hawwe dêr't it hinne stjoerd waard:

ss -tnp | grep openvpn

Gean dan nei in bestimming dy't allinnich de tunnel betsjinje kin, en in namme dy't allinnich de tunnel-oplosser beantwurdzje kin. In foltôge proxy-ferbining mei in deade tunnel betsjut meastentiids dat de fiere kant nea it ferfier oanbean hat dat yn jo profyl neamd wurdt.

Skriuw it ferfier en de akseptearjende proxy op in duorsum plak. As itselde profyl op in oar netwurk bejout, slút dy notysje de proxy yn sekonden út of befêstiget him.

Relatearre artikelen