Base de conhecimento

ICMP - Pings IPv4 e Teste de Intervalo de Portas IPv4 NAT

Teste de intervalo de portas NAT

Para funcionar conforme o esperado, o aplicativo que você deseja executar através do sistema NAT IPv4 deve atender aos seguintes requisitos:
- O aplicativo deve ser dual-stack (ou seja, suportar conectividade IPv4 e IPv6);
- Deve ser capaz de ouvir nos formatos de endereço IPv6 e IPv4 (ou seja, [::]::0 e 0.0.0.0/0, os endereços catch-all para IPv6 e IPv4);
- Específico apenas para uso UDP: deve enviar um fluxo contínuo de pacotes sobre UDP.

Quase todos os aplicativos escritos para Linux suportam conectividade dual-stack. Exceções notáveis e conhecidas incluem:
- SOCKS 4 e SOCKS 4a (é compatível com SOCKS 5);
- Docker apenas com versões anteriores à 27.0.1 (lançada em 24 de junho de 2024). Algumas distribuições ainda implementam a versão anterior 26, principalmente Debian 12 e 13, por exemplo; O Ubuntu 24.04 LTS está confirmado para suportar o Docker na versão 27.5, por exemplo, tornando-o uma alternativa utilizável;
- Kubernetes (apenas versões anteriores a dezembro de 2021). O Debian 10 não tem suporte, o primeiro suporte está no Debian 11.
- Outros softwares anteriores a 2017/2018.

O endereço IP NAT IPv4 informado nas calculadoras de porta NAT que temos não precisa ser fornecido ao aplicativo no VPS. Basta que o aplicativo esteja mapeado para ouvir endereços catch-all. O tráfego enviado em um determinado intervalo de portas será automaticamente dividido pela nossa ponte NAT e, sempre que não for possível acessar diretamente pelo endereço IPv6, será roteado automaticamente pelo IP IPv4.

Exemplos de teste para TCP e UDP

Lembre-se: as portas são sempre pré-abertas automaticamente no intervalo determinado para você. Você não precisa nos enviar um ticket.

Exemplo para TCP: tente alterar /etc/ssh/sshd_config para uma porta dentro do intervalo de portas previsto do seu VPS.
Certifique-se de que “PubkeyAuthentication” esteja definido como Não e sem comentários (sem o #) e que “PasswordAuthentication” esteja definido como Sim e sem comentários. Salve. Agora faça:

sudo systemctl restart sshd [para Debian, AlmaLinux, Rocky Linux, Fedora] ou
sudo systemctl restart ssh [para Ubuntu]

para que o serviço SSH seja reiniciado. Certifique-se de que ele esteja escutando em ambos os formatos antes de qualquer teste.

Depois disso, você pode tentar fazer login usando PuTTY, MobaXterm ou qualquer cliente SSH, inserindo o IPv4 do servidor global, o usuário Linux do VPS (root) e a porta específica que você acabou de colocar no serviço SSH, e tudo funcionará perfeitamente.

Isso foi testado em um cliente MobaXterm no Windows e em uma conexão somente IPv4, com socat como tecnologia subjacente, em 29-10-2024, no AlmaLinux 9.4 e Debian 12.

Exemplo para UDP: instale o netcat-openbsd, disponível nos sistemas Debian ou Ubuntu. Após a instalação, certifique-se de que não deseja executar nenhum outro comando antes do netcat e execute o seguinte comando:

nc -6 -u -l -p [número da sua porta]

onde [número da sua porta] será o intervalo de portas exclusivo para UDP que você tem no seu VPS para NAT IPv4 (consulte o artigo da Base de Conhecimento para o cálculo da porta NAT IPv4).

O processo começará a escutar, por IPv6, na porta que você escolheu, e permanecerá assim.

Depois disso, tente enviar qualquer coisa (texto, mensagem, etc.) via UDP:

No Windows Powershell
$message = “Test UDP”; $udpClient = New-Object System.Net. Sockets.UdpClient; $udpClient.Connect(“116.xxx.xxx.xxx”, [número da sua porta]); $bytes = [Text.Encoding]::ASCII.GetBytes($message); $udpClient.Send($bytes, $bytes.Length); $udpClient.Close()

No Linux
echo “Teste UDP” | nc -u -w1 116.xxx.xxx.xxx [número da sua porta]

onde “116.xxx.xxx.xxx” é o IPv4 global público no nível do servidor que você possui, e [número da sua porta] será o número da porta exclusiva do UDP, que deve ser exatamente o mesmo número da porta que seu processo está escutando no VPS, E TAMBÉM o mesmo número da porta do seu intervalo de portas UDP.

Se você receber “Test UDP” no seu VPS, tudo está funcionando.

Isso foi testado em 29-10-2024, em um cliente MobaXterm no Windows e um acesso somente IPv4, através de um VPS com Debian 12. O Socat também é a tecnologia subjacente.

Não podemos garantir que o pacote “nc” em sistemas baseados em RHEL seja tecnicamente equivalente ao netcat-openbsd disponível no Debian e no Ubuntu (não foi testado), também devido ao seu hábito de reverter alterações, mas podemos garantir que o pacote netcat-traditional não é adequado para esta tarefa, pois não suporta o parâmetro -6 para escuta IPv6.

Em relação à conectividade ICMP sobre IPv4

O ping ICMP IPv4 de saída no MultiVPS, fora do intervalo de portas alocado, não é suportado, devido a uma especificidade técnica - a implementação DNS64 executada, tanto no servidor principal como no serviço público de fallback. O cabeçalho do pacote é alterado no processo, e o DNS64 precisa primeiro traduzir o pedido para um nome de domínio adequado, o que significa que não é reconhecível IP-para-IP.

O ping de um IPv4 é, portanto, suportado se esse IPv4 estiver contido como um nome de domínio.

O ICMP sobre IPv6-para-IPv6 direto é sempre suportado em todos os protocolos, independentemente do ping ser para um IP ou para um domínio.

Se quiser calcular as portas NAT IPv4 em seu VPS, clique aqui.