Lidhje vetëm IPv6, shërbim IPv4: lëreni një proxy SOCKS të bëjë urën

Nuk ju nevojitet një adresë nga familja e destinacionit për ta arritur, për sa kohë diçka në rrugë është e gatshme të përcjellë. Aplikacioni lidhet me proxy-n, dhe proxy-i hap një lidhje të dytë drejt destinacionit. Këto janë dy soketa me familje adresash të pavarura, dhe asgjë në asnjërin prej protokolleve nuk kërkon që ato të përputhen. Kjo është përcjellje në nivel aplikacioni, jo një rrugë IPv4 vendëse, dhe pikërisht ky dallim përcakton çfarë do të funksionojë dhe çfarë jo. Ngatërrimi i të dyjave është arsyeja pse një laptop përshkruhet sikur ka lidhje IPv4, ndërsa gjithçka që ka është një proxy.

Dy soketa, dy familje adresash

Një kërkesë SOCKS5 e emërton destinacionin në njërën nga tri format: një adresë v4 fjalëpërfjalë, një adresë v6 fjalëpërfjalë, ose një emër që proxy-i duhet ta zgjidhë. Kërkesa përshkruan ku duhet të lidhet proxy-i, jo si duket lidhja klient-me-proxy.

Lexoni këto lloje adresash si tri zgjedhje të pavarura brenda një mesazhi. Një proxy i arritshëm përmes IPv6 mund të hapë një soket destinacioni IPv4 sa herë që ka dalje IPv4 funksionale dhe politika e tij e lejon kërkesën. Specifikimi SOCKS5 i përcakton ato pa asnjë referencë ndaj transportit të klientit.

Shembull SSH i kontrolluar

Merrni një host SSH që ju lejohet ta përdorni, i cili përgjigjet në IPv6 dhe vetë mund të arrijë një shërbim HTTPS që ekziston vetëm në v4. Përcjellja dinamike e OpenSSH vendos një dëgjues SOCKS lokal në makinën tuaj ndërsa sesioni i identifikimit kalon përmes v6.

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

Host-i dhe llogaria më sipër janë shembuj, dhe lidhja loopback e mban dëgjuesin në këtë kompjuter. Mos e zëvendësoni me një lidhje me karaktere të gjera që një zyrë të mund të ndajë një proxy pa vërtetim. ExitOnForwardFailure=yes ekziston që një përcjellje e dështuar të mbyllë sesionin në vend që të lërë një komandë të heshtur duke u ekzekutuar në sfond.

Me sesionin në punë, kërkesa duket kështu:

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

Lidhja loopback nuk është një rrugë interneti IPv4. Ajo që del nga makina juaj është sesioni i identifikimit përmes v6, dhe është pala e largët ajo që hap soketin e destinacionit. Forma socks5h gjithashtu ia delegon zgjidhjen e emrave asaj pale, gjë që ka rëndësi kur klienti nuk ka rrugën e vet të zgjidhësit IPv4.

Çfarë sheh në të vërtetë destinacioni

Destinacioni sheh adresën e daljes së përcjellësit. Asnjë adresë që i përket laptopit tuaj nuk shfaqet atje. Një listë e lejuar burimesh në atë shërbim duhet të emërtojë përcjellësin. Regjistrat e tij do t'ia atribuojnë trafikun përcjellësit gjithashtu. Shkruajeni këtë në regjistrin e ndryshimeve përpara auditimit, sepse një listë e lejuar e ndërtuar rreth adresave të klientëve dështon në kërkesën e parë.

Përcjellësi është gjithashtu vendi ku dy gjysmat e bisedës janë të dukshme, gjë që është një veti e dobishme gjatë diagnozës dhe një barrë nëse përcjellësi ndahet pa politikë.

Kjo nuk është DNS64 ose NAT64

DNS64 përgjigjet me regjistra të sintetizuar që zëvendësojnë destinacione v4, dhe NAT64 i rishkruan paketat përgjatë një rruge të konfiguruar. Asnjëri nuk përshkruan atë që ndodh këtu, ku një bisedë transporti mbaron dhe një tjetër fillon dhe asnjë adresë e sintetizuar nuk e shpjegon rezultatin. Prandaj një kërkesë e suksesshme nuk thotë asgjë për atë se cilat shërbime përkthimi operon ofruesi juaj, dhe proxy-i mund të ekzekutojë NAT të zakonshëm në daljen e tij.

Të dy mekanizmat mund të ekzistojnë në të njëjtin rrjet, prandaj përshkruani atë që keni verifikuar vërtet, jo atë që tingëllon më afër.

Njihni shtrirjen përpara se ta premtoni

Përcjellja dinamike e OpenSSH mbart lidhje TCP, jo trafik IP arbitrar, prandaj UDP, ICMP dhe çdo protokoll që e injoron proxy-n kanë nevojë për një projekt tjetër të mbështetur. Ruani verifikimin e çelësit të hostit SSH, kufizimet e përcjelljes të serverit dhe validimin e certifikatës HTTPS, sepse proxy-i është një pjesëmarrës shtesë i besuar, jo një arsye për të dobësuar kontrollet e identitetit. Nëse qëllimi është të mbartet transporti i jashtëm i një VPN përmes proxy-t, verifikoni që të dy skajet e mbështesin atë transport në vend që të supozoni se çdo dëgjues SOCKS mund t'i përcjellë atë.

Asgjë nga kjo nuk e bën klientin me dy shtresa, dhe asgjë nga kjo nuk nevojitet. Bën që një aplikacion të arrijë një shërbim përmes një përcjellësi, që është një pohim më i vogël dhe shumë më i lehtë për t'u verifikuar.