SOCKS5-välityspalvelin OpenVPN:lle: TCP-tunneli vai sovellusten välitys?

Verkot, jotka sallivat lähtevän liikenteen vain välityspalvelimen kautta, ovat paikka, jossa toimiva profiili kuolee yhtäkkiä. Välityspalvelimen osoite on tämän vian vähiten kiinnostava muuttuja. Kaiken ratkaisee liikenteen muoto, jonka välityspalvelin välittää, koska nämä välityspalvelimet siirtävät tavuvirtaa eikä UDP-tunneli ole sellainen. Jäljelle jää kaksi arkkitehtuuria, ja ne hajoavat eri kohdissa.

Yksi rajoitus ratkaisee rakenteen

SOCKS5 tosin määrittelee UDP-yhdistämistilan. OpenVPN-asiakkaan välitystuki on silti rakennettu virtojen ympärille: socks-proxy on dokumentoitu TCP-profiileille, eikä HTTP CONNECT -välityspalvelimella ole lainkaan reittiä datagrammeille. Yksi dokumentaatiorivi ratkaisee arkkitehtuurin ennen kuin kosket asetustiedostoa.

Kysymys ei siis ole, minkä välityspalvelimen valitset. Kysymys on, muuttuuko tunneli virraksi vai jääkö se datagrammiksi ja antaako jonkin muun ottaa välityksen hoitaakseen.

Vaihtoehto A: tee tunnelista virta

Tämä vaatii palvelimen, jossa on TCP-kuuntelija, ja asiakasprofiilin, joka nimeää välityspalvelimen. Molemmat osat tarvitaan, ja palvelinpuoli on se, joka unohdetaan:

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

Korvaa viimeinen rivi http-proxy proxy.internal 8080-rivillä, kun välityspalvelin puhuu HTTP:tä, ja lisää tunnistetiedosto, jos se vaatii sellaisen. Välityspalvelimen on oltava valmis tekemään CONNECT VPN-porttiisi, ja palvelimen on vastattava TCP:llä; vain UDP:tä kuunteleva kuuntelija jättää yrityksen huomiotta. 443:n valinta on käytännöllinen siirto, koska monet rajoittavat verkot sallivat sen ja vähän muuta.

Hinta on TCP:n pinoaminen TCP:n päälle. Yksi pudonnut ulompi segmentti pysäyttää jokaisen sisemmän virran, joka jakaa sen yhteyden, joten palautuminen, joka normaalisti olisi itsenäistä, muuttuu jaetuksi. Asennus kestää myös kauemmin, ja epävakaa ulompi reitti muuttuu epävakaaksi tunneliksi hitaan sijaan.

Vaihtoehto B: jätä tunneli rauhaan

Kun tunnelin on pysyttävä UDP:llä, tunneli ei ole paikka, jossa konfiguroit jotain. Sen sijaan sovellusten lähtevä TCP ohjataan paikalliselle SOCKS-kuuntelijalle, eivätkä sovellukset koskaan saa tietää, että välityspalvelin on olemassa. Linuxissa se on yleensä redsocks sekä NAT REDIRECT -sääntö nat-taulussa.

Taas vain TCP. Pelkkä HTTP-välityspalvelin kuten privoxy ei voi välittää mielivaltaisia protokollia, eikä tämä rakenne lisää datagrammitukea sovelluksillekaan.

Jokaiselle sovellukselle välityspalvelimesta suoraan kertominen on yleensä parempi silloin, kun ohjelmisto tukee sitä. Sitä on helpompi auditoida, ja se kaatuu paikassa, jonka todella näet.

Missä kukin vaihtoehto kaatuu

Vaihtoehto A kaatuu, kun palvelimelta puuttuu TCP-kuuntelija, kun välityspalvelin kieltäytyy CONNECT-kohteesta tai kun ulompaa virtaa rajoitetaan alle sen, mitä tunneli tarvitsee. Kaksi ensimmäistä jättävät merkinnän välityspalvelimen lokiin; kolmas jättää yhteyden, joka muodostuu ja tuntuu sitten väärältä. Lue se loki ennen profiilin muokkaamista, koska se erottaa lupia koskevan ongelman kapasiteettiongelmasta. Valmis CONNECT siirtää tutkinnan tunnelin sisään.

Vaihtoehto B kaatuu kaikkeen, joka tarvitsee datagrammeja, protokolliin, joita välityspalvelin ei ymmärrä, ja hiljaa isäntiin, joissa uudelleenohjaussääntö on olemassa mutta reititys lähettää liikenteen sen ohi.

Kumpikaan vaihtoehto ei muuta laitevaatimusta. Paketit tarvitsevat edelleen TUN- tai TAP-solmun ennen kuin ydin reitittää ne, joten prosessi tarvitsee edelleen luvan kohteessa /dev/net/tun. Kääre muuttaa sitä, mitä tapahtuu sen jälkeen, kun solmu on auki, ei sitä, tarvitsetko sitä.

Todista, minkä polun rakensit

Katso pistokkeita, älä ilmaisinalueen kuvaketta. VPN-prosessin pitäisi pitää muodostettu yhteys välityspalvelimen osoitteeseen, ja välityspalvelimen olisi pitänyt kirjata kohde, johon sen pyydettiin pääsevän:

ss -tnp | grep openvpn

Hae sitten kohde, jota vain tunneli voi palvella, ja nimi, johon vain tunnelin ratkaisija voi vastata. Valmis välitysyhteys kuolleen tunnelin kanssa tarkoittaa yleensä, että kaukopää ei koskaan tarjonnut profiilissasi nimettyä siirtotapaa.

Kirjaa siirtotapa ja vastaanottava välityspalvelin pysyvään paikkaan. Kun sama profiili epäonnistuu toisessa verkossa, se muistiinpano sulkee välityspalvelimen pois tai vahvistaa sen sekunneissa.