Ainult IPv6-ühendus, IPv4-teenus: lase SOCKS-proksil see sillata

Teil pole sihtkoha aadressiperekonda kuuluvat aadressi vaja, et selleni jõuda, kui vaid miski teekonnal on valmis edastama. Rakendus ühendub proksiga ja proksi avab teise ühenduse sihtkohaga. Need on kaks sokkelt, millel on sõltumatud aadressiperekonnad, ja kumbki protokoll ei nõua, et need kattuksid. See on rakendustasandi edastamine, mitte natiivne IPv4-teekond, ja see erinevus otsustab, mis töötab ja mis mitte. Nende kahe segamine on põhjus, miks sülearvutit kirjeldatakse IPv4-ühendusega, kuigi kõik, mis tal on, on proksi.

Kaks sokkelt, kaks aadressiperekonda

SOCKS5-päring nimetab sihtkoha ühes kolmest vormist: sõnasõnaline v4-aadress, sõnasõnaline v6-aadress või nimi, mille proksi peab lahendama. Päring kirjeldab, kuhu proksi peaks ühenduma, mitte seda, kuidas klient-proksi ühendus välja näeb.

Lugege neid aadressitüüpe kolme sõltumatu valikuna ühes sõnumis. IPv6 kaudu kättesaadav proksi saab avada IPv4-sihtkoha sokkeli alati, kui tal on toimiv IPv4-väljund ja tema poliitika lubab päringut. SOCKS5 spetsifikatsioon määratleb need ilma igasuguse viiteta kliendi transpordile.

Kontrollitud SSH-näide

Võtke SSH-host, mida tohib kasutada, mis vastab IPv6-l ja suudab ise jõuda HTTPS-teenuseni, mis eksisteerib ainult v4-l. OpenSSH dünaamiline edastamine paneb teie masinale kohaliku SOCKS-kuulaja, samal ajal kui sisselogimissessioon käib üle v6.

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

Ülaltoodud host ja konto on näited ning loopback-sidumine hoiab kuulaja selles arvutis. Ärge asendage seda metamärk-sidumisega, et kontor saaks jagada autentimata proksit. ExitOnForwardFailure=yes on olemas selleks, et ebaõnnestunud edastamine lõpetaks sessiooni, selle asemel et jätta taustale vaikne käsk tööle.

Sessiooni töötamise ajal näeb päring välja selline:

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

Loopback-ühendus ei ole IPv4-internetiteekond. Teie masinast lahkub sisselogimissessioon üle v6 ja sihtkoha sokkeli avab kaugem pool. Vorm socks5h delegeerib ka nimede lahendamise sellele poolele, mis loeb siis, kui kliendil pole omaette IPv4-lahendusteed.

Mida sihtkoht tegelikult näeb

Sihtkoht näeb edastaja väljundiaadressi. Ükski teie sülearvutile kuuluv aadress seal ei ilmu. Selle teenuse allika lubatud loend peab edastaja nimetama. Ka selle logid omistavad liikluse edastajale. Kirjutage see enne auditit muudatuste registrisse, sest kliendi aadresside ümber ehitatud lubatud loend ebaõnnestub esimese päringu juures.

Edastaja on ka koht, kus on näha vestluse kaks poolt, mis on diagnoosimisel kasulik omadus ja koormus, kui edastajat jagatakse ilma poliitikata.

See ei ole DNS64 ega NAT64

DNS64 vastab sünteesitud kirjetega, mis esindavad v4-sihtkohti, ja NAT64 kirjutab paketid ümber mööda konfigureeritud teekonda. Kumbki ei kirjelda seda, mis siin juhtub, kus üks transpordivestlus lõpeb ja teine algab ning ükski sünteesitud aadress ei selgita tulemust. Seetõttu ei ütle õnnestunud päring midagi selle kohta, milliseid tõlketeenuseid teie teenusepakkuja käitab, ja proksi võib oma väljundil tavalist NAT-i teha.

Mõlemad mehhanismid võivad eksisteerida samas võrgus, seega kirjeldage seda, mida te tegelikult kontrollisite, mitte seda, mis kõlab kõige lähemalt.

Tea ulatust enne, kui seda lubad

OpenSSH dünaamiline edastamine kannab TCP-ühendusi, mitte suvalist IP-liiklust, seega vajavad UDP, ICMP ja iga proksit eirav protokoll teistsugust toetatud lahendust. Säilitage SSH-hostivõtme kontroll, serveri edastuspiirangud ja HTTPS-sertifikaadi valideerimine, sest proksi on täiendav usaldusväärne osaleja, mitte põhjus identiteedikontrolle nõrgendada. Kui eesmärk on kanda VPN-i välist transporti läbi proksi, kontrollige, et mõlemad otsad seda transporti toetavad, selle asemel et eeldada, et iga SOCKS-kuulaja suudab seda edastada.

Miski sellest ei tee klienti kahekihiliseks ja miski sellest pole vajalik. See paneb ühe rakenduse jõudma ühe teenuseni ühe edastaja kaudu, mis on väiksem väide ja palju lihtsamini kontrollitav.