Conexiune doar IPv6, serviciu IPv4: lăsați un proxy SOCKS să facă puntea

Nu aveți nevoie de o adresă din familia destinației pentru a o atinge, atâta timp cât ceva de pe traseu este dispus să retransmită. Aplicația se conectează la proxy, iar proxy-ul deschide o a doua conexiune către destinație. Sunt două socketuri cu familii de adrese independente, și nimic din niciunul dintre protocoale nu cere ca ele să coincidă. Aceasta este retransmitere la nivel de aplicație, nu o cale IPv4 nativă, iar distincția decide ce va funcționa și ce nu. Confundarea celor două este modul în care un laptop ajunge descris ca având conectivitate IPv4 când tot ce are este un proxy.

Două socketuri, două familii de adrese

O cerere SOCKS5 numește destinația într-una din trei forme: o adresă v4 literală, o adresă v6 literală sau un nume pe care proxy-ul să îl rezolve. Cererea descrie unde trebuie să se conecteze proxy-ul, nu cum arată conexiunea client-la-proxy.

Citiți aceste tipuri de adresă ca trei alegeri independente într-un singur mesaj. Un proxy accesibil prin IPv6 poate deschide un socket de destinație IPv4 oricând are o ieșire IPv4 funcțională și politica sa permite cererea. Specificația SOCKS5 le definește fără nicio referire la transportul clientului.

Un exemplu SSH controlat

Luați un host SSH pe care aveți autorizare să îl folosiți, care răspunde pe IPv6 și poate el însuși atinge un serviciu HTTPS care există doar pe v4. Forwarding-ul dinamic al OpenSSH pune un ascultător SOCKS local pe mașina dumneavoastră în timp ce sesiunea de autentificare rulează prin v6.

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

Hostul și contul de mai sus sunt exemple, iar legarea loopback ține ascultătorul pe acest computer. Nu o înlocuiți cu o legare wildcard ca un birou să poată partaja un proxy neautentificat. ExitOnForwardFailure=yes există pentru ca un forwarding eșuat să încheie sesiunea în loc să lase o comandă silențioasă rulând în fundal.

Cu sesiunea activă, cererea arată astfel:

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

Conexiunea loopback nu este o cale de internet IPv4. Ce pleacă de pe mașina dumneavoastră este sesiunea de autentificare prin v6, iar partea îndepărtată este cea care deschide socketul destinației. Forma socks5h deleagă și rezolvarea numelor acelei părți, ceea ce contează când clientul nu are propria cale de resolver IPv4.

Ce vede de fapt destinația

Destinația vede adresa de ieșire a retransmițătorului. Nicio adresă care aparține laptopului dumneavoastră nu apare acolo. O listă de surse permise pe acel serviciu trebuie să numească retransmițătorul. Jurnalele sale vor atribui și ele traficul retransmițătorului. Scrieți asta în registrul de modificări înainte de audit, pentru că o listă de permisiuni construită în jurul adreselor clienților eșuează la prima cerere.

Retransmițătorul este și locul unde cele două jumătăți ale conversației sunt vizibile, ceea ce este o proprietate utilă în diagnosticare și o povară dacă retransmițătorul este partajat fără politică.

Acesta nu este DNS64 sau NAT64

DNS64 răspunde cu înregistrări sintetizate care înlocuiesc destinații v4, iar NAT64 rescrie pachete de-a lungul unei căi configurate. Niciunul nu descrie ce se întâmplă aici, unde o conversație de transport se termină și alta începe și nicio adresă sintetizată nu explică rezultatul. O cerere reușită nu spune deci nimic despre ce servicii de traducere operează furnizorul dumneavoastră, iar proxy-ul poate rula NAT obișnuit pe propria ieșire.

Ambele mecanisme pot exista în aceeași rețea, așa că descrieți-l pe cel pe care l-ați verificat cu adevărat, nu pe cel care sună cel mai aproape.

Cunoașteți amploarea înainte de a o promite

Forwarding-ul dinamic al OpenSSH transportă conexiuni TCP, nu trafic IP arbitrar, așa că UDP, ICMP și orice protocol care ignoră proxy-ul au nevoie de un alt design acceptat. Păstrați verificarea cheii hostului SSH, restricțiile de forwarding ale serverului și validarea certificatului HTTPS, pentru că proxy-ul este un participant de încredere suplimentar, nu un motiv să slăbiți verificările de identitate. Dacă scopul este să transportați transportul exterior al unui VPN prin proxy, verificați că ambele capete acceptă acel transport în loc să presupuneți că orice ascultător SOCKS îl poate retransmite.

Nimic din toate acestea nu face clientul dual-stack și nimic din ele nu este necesar. Face ca o aplicație să ajungă la un serviciu printr-un retransmițător, ceea ce este o afirmație mai mică și mult mai ușor de verificat.