Connexió només IPv6, servei IPv4: deixeu que un proxy SOCKS faci de pont

No necessiteu cap adreça de la família de destinació per arribar-hi, sempre que alguna cosa del camí estigui disposada a retransmetre. L'aplicació es connecta al proxy, i el proxy obre una segona connexió a la destinació. Són dos sockets amb famílies d'adreces independents, i res d'un protocol ni de l'altre no exigeix que coincideixin. Això és retransmissió a nivell d'aplicació, no un camí IPv4 natiu, i la distinció decideix què funcionarà i què no. Confondre les dues coses és com un portàtil acaba descrit com si tingués connectivitat IPv4 quan tot el que té és un proxy.

Dos sockets, dues famílies d'adreces

Una sol·licitud SOCKS5 anomena la destinació en una de tres formes: una adreça v4 literal, una adreça v6 literal o un nom perquè el proxy el resolgui. La sol·licitud descriu on s'ha de connectar el proxy, no com és la connexió client-a-proxy.

Llegiu aquests tipus d'adreça com tres eleccions independents dins d'un sol missatge. Un proxy abastable per IPv6 pot obrir un socket de destinació IPv4 sempre que tingui sortida IPv4 funcional i la seva política permeti la sol·licitud. L'especificació de SOCKS5 les defineix sense cap referència al transport del client.

Un exemple SSH controlat

Agafeu un amfitrió SSH que tingueu autoritzat a usar, que respongui per IPv6 i que pugui arribar ell mateix a un servei HTTPS que només existeixi a v4. El reenviament dinàmic d'OpenSSH posa un oient SOCKS local a la vostra màquina mentre la sessió d'inici de sessió va per v6.

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

L'amfitrió i el compte de dalt són exemples, i l'enllaç de loopback manté l'oient en aquest ordinador. No el substituïu per un enllaç comodí perquè una oficina pugui compartir un proxy sense autenticació. ExitOnForwardFailure=yes existeix perquè un reenviament fallit acabi la sessió en lloc de deixar una ordre silenciosa corrent en segon pla.

Amb la sessió en marxa, la sol·licitud té aquest aspecte:

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

La connexió de loopback no és un camí d'internet IPv4. El que surt de la vostra màquina és la sessió d'inici de sessió per v6, i és el costat remot qui obre el socket de destinació. La forma socks5h també delega la resolució de noms a aquell costat, cosa que importa quan el client no té cap camí propi de resolució IPv4.

Què ve realment la destinació

La destinació veu l'adreça de sortida del repetidor. Allà no hi apareix cap adreça que pertanyi al vostre portàtil. Una llista d'orígens permesos en aquell servei ha de nomenar el repetidor. Els seus registres també atribuiran el trànsit al repetidor. Escriviu-ho a l'acta de canvi abans de l'auditoria, perquè una llista d'orígens permesos construïda al voltant d'adreces de clients falla a la primera sol·licitud.

El repetidor també és el lloc on són visibles les dues meitats de la conversa, cosa que és una propietat útil durant el diagnòstic i una responsabilitat si el repetidor es comparteix sense política.

Això no és DNS64 ni NAT64

DNS64 respon amb registres sintetitzats que fan de substituts de destinacions v4, i NAT64 reescriu paquets al llarg d'un camí configurat. Cap dels dos no descriu què passa aquí, on una conversa de transport acaba i una altra comença i cap adreça sintetitzada no explica el resultat. Una sol·licitud reeixida, doncs, no diu res sobre quins serveis de traducció opera el vostre proveïdor, i el proxy pot fer NAT ordinari a la seva pròpia sortida.

Qualsevol dels dos mecanismes pot existir a la mateixa xarxa, així que descriviu el que heu verificat de veritat, no el que sona més proper.

Conèixer l'abast abans de prometre'l

El reenviament dinàmic d'OpenSSH transporta connexions TCP, no trànsit IP arbitrari, així que UDP, ICMP i qualsevol protocol que ignori el proxy necessiten un disseny diferent que estigui suportat. Manteniu la verificació de la clau de l'amfitrió SSH, les restriccions de reenviament del servidor i la validació del certificat HTTPS, perquè el proxy és un participant de confiança addicional, no una raó per debilitar les comprovacions d'identitat. Si l'objectiu és portar el transport exterior d'una VPN a través del proxy, verifiqueu que tots dos extrems admetin aquest transport en lloc de suposar que qualsevol oient SOCKS pot retransmetre'l.

Res d'això no fa que el client sigui de doble pila, i no cal. Fa que una aplicació arribi a un servei a través d'un repetidor, que és una afirmació més petita i molt més fàcil de verificar.