Conexión só IPv6, servizo IPv4: deixe que un proxy SOCKS faga de ponte

Non precisa un enderezo da familia de destino para chegar a el, sempre que algo no camiño estea disposto a retransmitir. A aplicación conéctase ao proxy, e o proxy abre unha segunda conexión ao destino. Son dous sockets con familias de enderezos independentes, e nada en ningún dos dous protocolos esixe que coincidan. Iso é retransmisión a nivel de aplicación, non un camiño IPv4 nativo, e a distinción decide que funcionará e que non. Confundir as dúas cousas é como un portátil acaba descrito como se tivese conectividade IPv4 cando todo o que ten é un proxy.

Dous sockets, dúas familias de enderezos

Unha solicitude SOCKS5 nomea o destino nunha de tres formas: un enderezo v4 literal, un enderezo v6 literal ou un nome para que o proxy o resolva. A solicitude describe onde se debe conectar o proxy, non como é a conexión cliente-a-proxy.

Lea eses tipos de enderezo como tres eleccións independentes dentro dunha mesma mensaxe. Un proxy alcanzable por IPv6 pode abrir un socket de destino IPv4 sempre que teña saída IPv4 funcional e a súa política permita a solicitude. A especificación de SOCKS5 defíneos sen ningunha referencia ao transporte do cliente.

Un exemplo SSH controlado

Tome un host SSH que teña autorización para usar, que responda en IPv6 e que poida alcanzar por si mesmo un servizo HTTPS que só exista en v4. O reenvío dinámico de OpenSSH coloca un oínte SOCKS local na súa máquina mentres a sesión de inicio de sesión vai por v6.

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

O host e a conta de arriba son exemplos, e a ligazón de loopback mantén o oínte neste equipo. Non a substitúa por unha ligazón comodín para que unha oficina comparta un proxy sen autenticación. ExitOnForwardFailure=yes existe para que un reenvío fallido termine a sesión en lugar de deixar un comando silencioso executándose en segundo plano.

Coa sesión en marcha, a solicitude ten este aspecto:

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

A conexión de loopback non é un camiño de internet IPv4. O que sae da súa máquina é a sesión de inicio de sesión por v6, e é o lado remoto quen abre o socket de destino. A forma socks5h tamén delega a resolución de nomes a ese lado, o que importa cando o cliente non ten a súa propia ruta de resolución IPv4.

O que o destino ve realmente

O destino ve o enderezo de saída do repetidor. Ningún enderezo que pertenza ao seu portátil aparece alí. Unha lista de orixe permitida nese servizo ten que nomear o repetidor. Os seus rexistros tamén atribuirán o tráfico ao repetidor. Escríbao no rexistro de cambios antes da auditoría, porque unha lista de permitidos construída arredor de enderezos de clientes falla na primeira solicitude.

O repetidor é tamén o lugar onde son visibles as dúas metades da conversa, o que é unha propiedade útil durante o diagnóstico e unha carga se o repetidor se comparte sen política.

Isto non é DNS64 nin NAT64

DNS64 responde con rexistros sintetizados que representan destinos v4, e NAT64 reescribe paquetes ao longo dun camiño configurado. Ningún describe o que ocorre aquí, onde unha conversa de transporte remata e outra comeza e ningún enderezo sintetizado explica o resultado. Unha solicitude exitosa, xa que logo, non di nada sobre que servizos de tradución opera o seu provedor, e o proxy pode executar NAT ordinario na súa propia saída.

Calquera dos dous mecanismos pode existir na mesma rede, así que describa o que verificou realmente en lugar do que soa máis próximo.

Coñeza o alcance antes de prometelo

O reenvío dinámico de OpenSSH transporta conexións TCP, non tráfico IP arbitrario, así que UDP, ICMP e calquera protocolo que ignore o proxy necesitan un deseño compatible distinto. Manteña a verificación da clave de host SSH, as restricións de reenvío do servidor e a validación do certificado HTTPS, porque o proxy é un participante de confianza adicional, non unha razón para debilitar as comprobacións de identidade. Se o obxectivo é levar o transporte exterior dunha VPN a través do proxy, verifique que ambos os extremos admiten ese transporte en lugar de supoñer que calquera oínte SOCKS pode retransmitilo.

Nada disto fai que o cliente sexa de dobre pila, e nada diso é necesario. Fai que unha aplicación chegue a un servizo a través dun repetidor, o que é unha afirmación máis pequena e moito máis fácil de verificar.