Povezava samo prek IPv6, storitev na IPv4: naj SOCKS-proxy zgradi most

Za dosego cilja ne potrebujete naslova iz ciljne družine, dokler je nekaj na poti pripravljeno posredovati. Aplikacija se poveže s proxyjem, proxy pa odpre drugo povezavo do cilja. To sta dva vtičnika z neodvisnimi družinami naslovov in nič v nobenem od protokolov ne zahteva, da se ujemata. To je posredovanje na ravni aplikacije, ne izvorna pot IPv4, in ta razlika odloča, kaj bo delovalo in kaj ne. Zamenjevanje obojega je razlog, da je prenosnik opisan kot da ima povezljivost IPv4, čeprav ima samo proxy.

Dva vtičnika, dve družini naslovov

Zahteva SOCKS5 poimenuje cilj v eni od treh oblik: dobesedni naslov v4, dobesedni naslov v6 ali ime, ki naj ga proxy razreši. Zahteva opisuje, kam naj se proxy poveže, ne kako izgleda povezava odjemalec–proxy.

Te tipe naslovov berite kot tri neodvisne izbire v enem sporočilu. Proxy, dosegljiv prek IPv6, lahko odpre vtičnik cilja IPv4, kadar ima delujoč izhod IPv4 in njegova politika dovoljuje zahtevo. Specifikacija SOCKS5 jih opredeljuje povsem brez sklicevanja na transport odjemalca.

Nadzorovan primer SSH

Vzemite gostitelja SSH, ki ga smete uporabljati, ki odgovarja na IPv6 in sam lahko doseže storitev HTTPS, ki obstaja samo na v4. Dinamično posredovanje OpenSSH postavi lokalni poslušalec SOCKS na vaš stroj, medtem ko prijavna seja teče prek v6.

ssh -6 -N -D 127.0.0.1:1081 -o ExitOnForwardFailure=yes [email protected]

Gostitelj in račun zgoraj so primeri, vezava na loopback pa ohranja poslušalec na tem računalniku. Ne nadomestite je z vezavo na nadomestne znake, da bi pisarna lahko delila neoverjen proxy. ExitOnForwardFailure=yes obstaja zato, da neuspešno posredovanje konča sejo, namesto da bi v ozadju pustilo tiho delujoč ukaz.

Ko seja teče, je zahteva videti takole:

curl --proxy socks5h://127.0.0.1:1081 https://v4-only.example/

Povezava prek loopback ni internetna pot IPv4. Z vašega stroja odhaja prijavna seja prek v6, vtičnik cilja pa odpre oddaljena stran. Oblika socks5h tudi prenese razreševanje imen na to stran, kar je pomembno, ko odjemalec nima lastne poti do razreševalnika IPv4.

Kaj cilj v resnici vidi

Cilj vidi izhodni naslov posredovalca. Noben naslov, ki bi pripadal vašemu prenosniku, se tam ne pojavi. Seznam dovoljenih virov na tej storitvi mora navesti posredovalca. Tudi njegovi dnevniki bodo promet pripisali posredovalcu. Zapišite to v evidenco sprememb pred revizijo, ker seznam dovoljenih, zgrajen okoli naslovov odjemalcev, spodleti pri prvi zahtevi.

Posredovalec je tudi kraj, kjer sta vidna oba polovica pogovora, kar je koristna lastnost pri diagnosticiranju in breme, če se posredovalec deli brez politike.

To ni DNS64 ali NAT64

DNS64 odgovarja s sintetiziranimi zapisi, ki nadomeščajo cilje v4, NAT64 pa prepisuje pakete po konfigurirani poti. Nobeno ne opisuje, kaj se dogaja tu, kjer se en pogovor o transportu konča in drugi začne in noben sintetizirani naslov ne pojasni rezultata. Uspešna zahteva torej ne pove ničesar o tem, katere prevajalske storitve upravlja vaš ponudnik, in proxy lahko na svojem izhodu izvaja običajen NAT.

Oba mehanizma lahko obstajata v istem omrežju, zato opišite tistega, ki ste ga resnično preverili, namesto tistega, ki se sliši najbližje.

Poznajte obseg, preden ga obljubite

Dinamično posredovanje OpenSSH prenaša povezave TCP, ne poljubnega prometa IP, zato UDP, ICMP in vsak protokol, ki ignorira proxy, potrebujejo drugačno podprto zasnovo. Ohranite preverjanje ključa gostitelja SSH, omejitve posredovanja strežnika in preverjanje potrdila HTTPS, ker je proxy dodatni zaupanja vredni udeleženec, ne pa razlog za slabitev preverjanja identitete. Če je cilj prenesti zunanji transport VPN skozi proxy, preverite, da ga podpirata oba konca, namesto da predpostavljate, da ga lahko posreduje kateri koli poslušalec SOCKS.

Nič od tega ne naredi odjemalca dvojnega sklada in nič od tega ni potrebno. Omogoči, da ena aplikacija doseže eno storitev prek enega posredovalca, kar je manjša trditev in veliko lažje preverljiva.