IPv6 soilik konexioa, IPv4 zerbitzua: utzi SOCKS proxyari zubia egiten

Ez duzu helmugako familia bereko helbiderik behar hara iristeko, bidean zerbait birbidaltzeko prest badago. Aplikazioa proxyarekin konektatzen da, eta proxyak bigarren konexio bat irekitzen du helmugarekin. Helbide-familia independenteak dituzten bi socket dira, eta bi protokoloetako batek ere ez du eskatzen bat etortzea. Hori aplikazio-mailako birbidaltzea da, ez IPv4 bide natiboa, eta bereizketak erabakitzen du zer ibiliko den eta zer ez. Biak nahastea da ordenagailu eramangarri bat IPv4 konektibitatea duela deskribatzeko modua, duen guztia proxy bat denean.

Bi socket, bi helbide-familia

SOCKS5 eskaera batek helmuga hiru formetako batean izendatzen du: v4 helbide literala, v6 helbide literala edo proxyak ebatziko duen izen bat. Eskaerak proxyak non konektatu behar duen deskribatzen du, ez nolakoa den bezero-proxy konexioa.

Irakurri helbide mota horiek mezu bakar baten barruko hiru hautaketa independente gisa. IPv6 bidez iristeko moduko proxy batek IPv4 helmugako socket bat ireki dezake IPv4 irteera funtzionala duenean eta bere politikak eskaera baimentzen duenean. SOCKS5 zehaztapenak haiek definitzen ditu bezeroaren garraioari inolako erreferentziarik egin gabe.

SSH adibide kontrolatu bat

Har ezazu erabiltzeko baimena duzun SSH ostalari bat, IPv6n erantzuten duena eta berak v4n soilik dagoen HTTPS zerbitzu batera irits daitekeena. OpenSSHren birbidaltze dinamikoak SOCKS entzule lokal bat jartzen du zure makinan, saio-hasierako saioa v6 bidez doan bitartean.

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

Goiko ostalaria eta kontua adibideak dira, eta loopback loturak entzulea ordenagailu honetan mantentzen du. Ez ordeztu komodin-lotura batekin bulego batek autentifikaziorik gabeko proxy bat parteka dezan. ExitOnForwardFailure=yes badago birbidaltze hutsegite batek saioa amai dezan, atzealdean isilik dabilen komando bat utzi beharrean.

Saioa martxan dagoela, eskaerak itxura hau du:

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

Loopback konexioa ez da IPv4 internet bide bat. Zure makinatik ateratzen dena v6 bidezko saio-hasierako saioa da, eta urrutiko aldea da helmugako socket-a irekitzen duena. socks5h formak izen-ebazpena alde horri uzten dio ere, eta hori garrantzitsua da bezeroak bere IPv4 ebazte-biderik ez duenean.

Helmugak benetan zer ikusten duen

Helmugak birbidaltzailearen irteera-helbidea ikusten du. Ez da han zure ordenagailu eramangarriarena den helbiderik agertzen. Zerbitzu horretako iturri-baimenduen zerrendak birbidaltzailea izendatu behar du. Bere erregistroek ere trafikoa birbidaltzaileari egotziko diote. Idatzi hori aldaketa-erregistroan auditoriaren aurretik, bezeroen helbideen inguruan eraikitako baimenduen zerrenda lehen eskaeran huts egiten baitu.

Birbidaltzailea elkarrizketaren bi erdiak ikusgai dauden lekua ere bada, eta hori propietate erabilgarria da diagnostikoan eta karga da birbidaltzailea politikarik gabe partekatzen bada.

Hau ez da DNS64 ezta NAT64 ere

DNS64k v4 helmugak ordezkatzen dituzten erregistro sintetizatuekin erantzuten du, eta NAT64k paketeak berridazten ditu konfiguratutako bide batean zehar. Biak ere ez dute hemen gertatzen dena deskribatzen, non garraio-elkarrizketa bat amaitzen den eta beste bat hasten den eta helbide sintetizaturik emaitza azaltzen ez duen. Beraz, eskaera arrakastatsu batek ez du ezer esaten zure hornitzaileak zein itzulpen zerbitzu dituen, eta proxyak NAT arrunta exekuta dezake bere irteeran.

Bi mekanismoak sare berean egon daitezke, beraz deskribatu benetan egiaztatu duzuna, hurbilen entzuten dena izan beharrean.

Ezagutu irismena agindu aurretik

OpenSSHren birbidaltze dinamikoak TCP konexioak eramaten ditu, ez IP trafiko arbitrarioa, beraz UDPk, ICMPk eta proxya ignoratzen duen edozein protokolo-k beste onartutako diseinu bat behar dute. Mantendu SSH ostalari-gakoaren egiaztapena, zerbitzariaren birbidaltze-murrizketak eta HTTPS ziurtagiriaren balidazioa, proxyak parte-hartzaile fidagarri gehigarri bat baita, ez identitate-egiaztapenak ahultzeko arrazoi bat. Helburua VPN baten kanpoko garraioa proxyaren bidez eramatea bada, egiaztatu bi muturreek garraio hori onartzen dutela, edozein SOCKS entzulek birbidal dezakeela suposatu beharrean.

Horietako ezerk ez du bezeroa pila bikoitzekoa egiten, eta horietako ezer ez da beharrezkoa. Aplikazio bakar bat proxy bakar baten bidez zerbitzu bakar batera iristea lortzen du, eta hori baieztapen txikiagoa da eta askoz errazagoa egiaztatzen.