SOCKS5 milliþjónn fyrir OpenVPN: TCP göng eða milliþjóna forritin?

Net sem leyfa aðeins útleið í gegnum milliþjón eru þar sem virk prófíll deyr skyndilega. Milliþjónsfangið er minnst áhugaverða breytan í þeirri bilun. Allt ræðst af lögun umferðarinnar sem milliþjónninn sendir, því þessir milliþjónar senda bætastraum og UDP göng eru það ekki. Það skilur eftir tvær arkitektúr, og þær brotna á mismunandi stöðum.

Ein takmörkun ræður hönnuninni

SOCKS5 tilgreinir vissulega UDP tengingarham. Stuðningur milliþjóns í OpenVPN biðlaranum er samt byggður í kringum strauma: socks-proxy er skjalfestur fyrir TCP prófíla, og HTTP CONNECT milliþjónn hefur alls enga leið fyrir gagnagram. Ein lína skjalfestingar ræður arkitektúrnum áður en þú snertir stillingaskrá.

Spurningin er því ekki hvaða milliþjón á að velja. Heldur hvort göngin verða straumur, eða verða áfram gagnagram og leyfa einhverju öðru að taka við milliþjónuninni.

Valkostur A: gerðu göngin að straumi

Það krefst þjóns með TCP hlustara og biðlaraprófíls sem nefnir milliþjóninn. Bæði hlutarnir eru nauðsynlegir, og þjónshliðin er sú sem fólk gleymir:

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

Skiptu síðustu línunni út fyrir http-proxy proxy.internal 8080 þegar milliþjónninn talar HTTP, og bættu við skilríkjaskrá ef hann krefst þess. Milliþjónninn verður að vera reiðubúinn að framkvæma CONNECT á VPN gáttina þína, og þjónninn verður að svara á TCP; hlustari sem er aðeins UDP hunsar tilraunina. Að velja 443 er hagnýtt skref, því mörg takmarkandi net leyfa það og lítið annað.

Kostnaðurinn er TCP staflað á TCP. Eitt tapað ytra hluti stöðvar hvern innri straum sem deilir þeirri tengingu, svo endurheimt sem venjulega væri óháð verður sameiginleg. Uppsetning tekur líka lengri tíma, og óstöðug ytri leið verður óstöðug göng í stað hægra.

Valkostur B: láttu göngin í friði

Þegar göngin verða að vera á UDP er það ekki göngin sem þú stillir. Þess í stað er útleið TCP frá forritum endurbeint á staðbundinn SOCKS hlustara, og forritin komast aldrei að því að milliþjónn sé til. Á Linux er það venjulega redsocks ásamt NAT REDIRECT reglu í nat töflunni.

Aftur aðeins TCP. Milliþjónn sem er aðeins HTTP eins og privoxy getur ekki sent handahófskennd samskiptareglur, og þessi hönnun bætir engri gagnagramstuðningi við forritin heldur.

Að segja hverju forriti beint frá milliþjóninum er venjulega betra þar sem hugbúnaðurinn styður það. Auðveldara er að endurskoða það, og það bregst á stað sem þú getur í raun séð.

Hvar hver valkostur bregst

Valkostur A bregst þegar þjóninn vantar TCP hlustara, þegar milliþjónninn neitar CONNECT markinu, eða þegar ytri straumnum er þröngvað niður fyrir það sem göngin þurfa. Fyrstu tveir skilja eftir færslu í skrá milliþjónsins; sá þriðji skilur eftir tengingu sem kemst á og finnst svo röng. Lestu þá skrá áður en þú breytir prófílnum, því hún greinir heimildarvandamál frá afkastavandamáli. Lokið CONNECT færir rannsóknina inn í göngin.

Valkostur B bregst fyrir allt sem þarf gagnagram, fyrir samskiptareglur sem milliþjónninn skilur ekki, og hljóðlega á hýslum þar sem endurbeiningarreglan er til en leiðsla sendir umferðina fram hjá henni.

Hvorugur valkostur breytir tækjakröfunni. Pakkar þurfa enn TUN eða TAP hnút áður en kjarninn leiðir þá, svo ferlið þarf enn heimild á /dev/net/tun. Umbúðir breyta því sem gerist eftir að hnúturinn er opinn, ekki hvort þú þarft hann.

Sannaðu hvaða leið þú byggðir

Sjáðu í sökklar frekar en táknmynd bakkans. VPN ferlið ætti að halda tengingu við milliþjónsfangið, og milliþjónninn ætti að hafa skráð markið sem beðið var um að ná:

ss -tnp | grep openvpn

Farðu svo á áfangastað sem aðeins göngin geta þjónað, og nafn sem aðeins leysir gönganna getur svarað. Lokið milliþjónstenging með dauðum göngum þýðir venjulega að fjarlægi endinn bauð aldrei þá flutning sem nefndur er í prófílnum þínum.

Skráðu flutninginn og milliþjóninn sem tekur við á varanlegum stað. Þegar sami prófíll bregst á öðru neti útilokar eða staðfestir þessi athugasemd milliþjóninn á sekúndum.