Conexión solo IPv6, servicio IPv4: deje que un proxy SOCKS haga de puente

No necesita una dirección de la familia de destino para alcanzarlo, siempre que algo en la ruta esté dispuesto a retransmitir. La aplicación se conecta al proxy, y el proxy abre una segunda conexión al destino. Son dos sockets con familias de direcciones independientes, y nada en ninguno de los dos protocolos exige que coincidan. Eso es retransmisión a nivel de aplicación, no una ruta IPv4 nativa, y la distinción decide qué funcionará y qué no. Confundir las dos cosas es cómo un portátil acaba descrito como si tuviera conectividad IPv4 cuando todo lo que tiene es un proxy.

Dos sockets, dos familias de direcciones

Una solicitud SOCKS5 nombra el destino de una de tres formas: una dirección v4 literal, una dirección v6 literal o un nombre para que el proxy lo resuelva. La solicitud describe dónde debe conectarse el proxy, no cómo es la conexión cliente-a-proxy.

Lea esos tipos de dirección como tres elecciones independientes dentro de un mismo mensaje. Un proxy alcanzable por IPv6 puede abrir un socket de destino IPv4 siempre que tenga salida IPv4 funcional y su política permita la solicitud. La especificación de SOCKS5 las define sin ninguna referencia al transporte del cliente.

Un ejemplo SSH controlado

Tome un host SSH que tenga autorización para usar, que responda en IPv6 y que pueda alcanzar por sí mismo un servicio HTTPS que solo exista en v4. El reenvío dinámico de OpenSSH coloca un oyente SOCKS local en su máquina mientras la sesión de inicio de sesión va por v6.

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

El host y la cuenta de arriba son ejemplos, y el enlace de loopback mantiene el oyente en este equipo. No lo sustituya por un enlace comodín para que una oficina comparta un proxy sin autenticación. ExitOnForwardFailure=yes existe para que un reenvío fallido termine la sesión en lugar de dejar un comando silencioso ejecutándose en segundo plano.

Con la sesión en marcha, la solicitud se ve así:

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

La conexión de loopback no es una ruta de internet IPv4. Lo que sale de su máquina es la sesión de inicio de sesión por v6, y es el lado remoto quien abre el socket de destino. La forma socks5h también delega la resolución de nombres a ese lado, lo que importa cuando el cliente no tiene su propia ruta de resolución IPv4.

Lo que el destino ve realmente

El destino ve la dirección de salida del retransmisor. Ninguna dirección que pertenezca a su portátil aparece allí. Una lista de origen permitido en ese servicio tiene que nombrar al retransmisor. Sus registros también atribuirán el tráfico al retransmisor. Escríbalo en el registro de cambios antes de la auditoría, porque una lista de permitidos construida en torno a direcciones de cliente falla en la primera solicitud.

El retransmisor es también el lugar donde son visibles las dos mitades de la conversación, lo que es una propiedad útil durante el diagnóstico y una carga si el retransmisor se comparte sin política.

Esto no es DNS64 ni NAT64

DNS64 responde con registros sintetizados que representan destinos v4, y NAT64 reescribe paquetes a lo largo de una ruta configurada. Ninguno describe lo que ocurre aquí, donde una conversación de transporte termina y otra comienza y ninguna dirección sintetizada explica el resultado. Una solicitud exitosa, por tanto, no dice nada sobre qué servicios de traducción opera su proveedor, y el proxy puede ejecutar NAT ordinario en su propia salida.

Cualquiera de los dos mecanismos puede existir en la misma red, así que describa el que verificó realmente en lugar del que suena más cercano.

Conozca el alcance antes de prometerlo

El reenvío dinámico de OpenSSH transporta conexiones TCP, no tráfico IP arbitrario, así que UDP, ICMP y cualquier protocolo que ignore el proxy necesitan un diseño compatible distinto. Mantenga la verificación de la clave de host SSH, las restricciones de reenvío del servidor y la validación del certificado HTTPS, porque el proxy es un participante de confianza adicional, no una razón para debilitar las comprobaciones de identidad. Si el objetivo es llevar el transporte exterior de una VPN a través del proxy, verifique que ambos extremos admitan ese transporte en lugar de suponer que cualquier oyente SOCKS puede retransmitirlo.

Nada de esto hace que el cliente sea de doble pila, y nada de ello hace falta. Hace que una aplicación llegue a un servicio a través de un retransmisor, lo que es una afirmación más pequeña y mucho más fácil de verificar.