Conexão só IPv6, serviço IPv4: deixe um proxy SOCKS fazer a ponte

Você não precisa de um endereço da família do destino para alcançá-lo, desde que algo no caminho esteja disposto a retransmitir. A aplicação conecta-se ao proxy, e o proxy abre uma segunda conexão ao destino. São dois sockets com famílias de endereços independentes, e nada em nenhum dos dois protocolos exige que coincidam. Isso é retransmissão em nível de aplicação, não um caminho IPv4 nativo, e a distinção decide o que funcionará e o que não funcionará. Confundir as duas coisas é como um laptop acaba descrito como tendo conectividade IPv4 quando tudo o que tem é um proxy.

Dois sockets, duas famílias de endereços

Uma requisição SOCKS5 nomeia o destino em uma de três formas: um endereço v4 literal, um endereço v6 literal ou um nome para o proxy resolver. A requisição descreve para onde o proxy deve conectar-se, não como é a conexão cliente-para-proxy.

Leia esses tipos de endereço como três escolhas independentes dentro de uma mesma mensagem. Um proxy alcançável por IPv6 pode abrir um socket de destino IPv4 sempre que tiver saída IPv4 funcional e sua política permitir a requisição. A especificação SOCKS5 define-os sem qualquer referência ao transporte do cliente.

Um exemplo SSH controlado

Pegue um host SSH que você tem autorização para usar, que responde em IPv6 e consegue ele mesmo alcançar um serviço HTTPS que só existe em v4. O encaminhamento dinâmico do OpenSSH coloca um ouvinte SOCKS local na sua máquina enquanto a sessão de login passa por v6.

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

O host e a conta acima são exemplos, e a ligação loopback mantém o ouvinte neste computador. Não a substitua por uma ligação curinga para que um escritório compartilhe um proxy sem autenticação. ExitOnForwardFailure=yes existe para que um encaminhamento falho encerre a sessão em vez de deixar um comando silencioso rodando em segundo plano.

Com a sessão em execução, a requisição fica assim:

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

A conexão loopback não é um caminho de internet IPv4. O que sai da sua máquina é a sessão de login por v6, e é o lado remoto que abre o socket de destino. A forma socks5h também delega a resolução de nomes a esse lado, o que importa quando o cliente não tem seu próprio caminho de resolução IPv4.

O que o destino realmente vê

O destino vê o endereço de saída do retransmissor. Nenhum endereço pertencente ao seu laptop aparece ali. Uma lista de origens permitidas nesse serviço precisa nomear o retransmissor. Seus registros também atribuirão o tráfego ao retransmissor. Escreva isso no registro de mudanças antes da auditoria, porque uma lista de permitidos construída em torno de endereços de clientes falha na primeira requisição.

O retransmissor também é o lugar onde as duas metades da conversa são visíveis, o que é uma propriedade útil durante o diagnóstico e um fardo se o retransmissor for compartilhado sem política.

Isto não é DNS64 nem NAT64

O DNS64 responde com registros sintetizados que substituem destinos v4, e o NAT64 reescreve pacotes ao longo de um caminho configurado. Nenhum deles descreve o que acontece aqui, onde uma conversa de transporte termina e outra começa e nenhum endereço sintetizado explica o resultado. Uma requisição bem-sucedida, portanto, não diz nada sobre quais serviços de tradução seu provedor opera, e o proxy pode executar NAT comum na própria saída.

Qualquer um dos dois mecanismos pode existir na mesma rede, então descreva o que você realmente verificou em vez do que soa mais próximo.

Conheça o alcance antes de prometê-lo

O encaminhamento dinâmico do OpenSSH transporta conexões TCP, não tráfego IP arbitrário, então UDP, ICMP e qualquer protocolo que ignore o proxy precisam de outro projeto suportado. Mantenha a verificação da chave de host SSH, as restrições de encaminhamento do servidor e a validação do certificado HTTPS, porque o proxy é um participante confiável adicional, não uma razão para enfraquecer as verificações de identidade. Se o objetivo é levar o transporte externo de uma VPN através do proxy, verifique que ambas as pontas suportam esse transporte em vez de presumir que qualquer ouvinte SOCKS pode retransmiti-lo.

Nada disso torna o cliente dual-stack, e nada disso é necessário. Faz com que uma aplicação alcance um serviço através de um retransmissor, o que é uma afirmação menor e muito mais fácil de verificar.