PowerShell: Alternativa ao Telnet para Testar Portas no Windows

O Telnet foi durante anos a ferramenta de eleição para testar portas TCP no Windows, mas hoje em dia está obsoleto e precisa de ser activado manualmente. O PowerShell, já instalado por defeito no Windows 10, Windows 11 e Windows Server 2016+, oferece uma alternativa mais moderna, mais segura e sem necessidade de activar funcionalidades adicionais. Neste artigo vamos explorar como usar o cmdlet Test-NetConnection e outros métodos para testar portas sem Telnet.

ℹ O Test-NetConnection está disponível no Windows 10, Windows 11 e Windows Server 2016+. Não precisa de activar nenhuma funcionalidade adicional.

⚠ O Telnet envia dados em texto simples (sem encriptação). Para diagnóstico de portas, o PowerShell é mais seguro e não requer activação de funcionalidades.

Neste artigo:

Introdução — Porque Substituir o Telnet

O Telnet Client não vem activado por defeito no Windows. Para o usar, é necessário ir ao Painel de Controlo, activar a funcionalidade em “Activar ou desactivar funcionalidades do Windows” e só depois é que o comando telnet fica disponível na linha de comandos. Este processo é incómodo, especialmente em ambientes de servidores onde não se quer instalar funcionalidades desnecessárias.

Além disso, o Telnet foi concebido numa era em que a segurança não era uma prioridade. Todo o tráfego — incluindo credenciais — é enviado em texto simples, sem qualquer tipo de encriptação. Embora para um simples teste de portas isto não seja problemático, a própria natureza do protocolo torna a sua presença no sistema um risco potencial.

O PowerShell resolve estes problemas. Já vem instalado em todos os sistemas Windows modernos, não requer activação de funcionalidades adicionais e oferece o cmdlet Test-NetConnection, que faz muito mais do que o Telnet alguma vez fez: além de testar portas TCP, verifica DNS, faz ping e apresenta informações detalhadas sobre a ligação.

Test-NetConnection — O Cmdlet Principal

O Test-NetConnection é o cmdlet do PowerShell dedicado ao diagnóstico de ligações de rede. Faz parte do módulo NetTCPIP, incluído por defeito no Windows 10, Windows 11 e Windows Server 2016+.

A sintaxe básica é simples:

Test-NetConnection -ComputerName kbase.pt -Port 443

Os parâmetros principais são:

Parâmetro Descrição Exemplo
-ComputerName Nome do host ou endereço IP a testar kbase.pt ou 192.168.1.10
-Port Número da porta TCP a testar 80, 443, 3389
-InformationLevel Nível de detalhe do output Detailed ou Quiet
-WarningAction Controla mensagens de aviso SilentlyContinue

Com -InformationLevel Detailed obtemos informações completas sobre a ligação, incluindo resolução DNS, ping e estado da porta:

# Output detalhado
Test-NetConnection -ComputerName kbase.pt -Port 443 -InformationLevel Detailed

Com -InformationLevel Quiet o cmdlet devolve apenas True ou False, ideal para usar em scripts:

# Output silencioso (True/False)
$resultado = Test-NetConnection -ComputerName kbase.pt -Port 443 -InformationLevel Quiet
if ($resultado) { Write-Host "Porta aberta" } else { Write-Host "Porta fechada" }

Testar Portas Específicas

Para testar portas específicas, basta indicar o número da porta no parâmetro -Port. Abaixo estão exemplos para as portas mais comuns:

Porta 80 (HTTP):

# Testar porta 80 (HTTP)
Test-NetConnection -ComputerName kbase.pt -Port 80

Porta 443 (HTTPS):

# Testar porta 443 (HTTPS)
Test-NetConnection -ComputerName kbase.pt -Port 443

Porta 25 (SMTP):

# Testar porta 25 (SMTP)
Test-NetConnection -ComputerName smtp.kbase.pt -Port 25

Porta 3389 (RDP):

# Testar RDP
Test-NetConnection -ComputerName 192.168.1.10 -Port 3389

Porta 22 (SSH):

# Testar porta 22 (SSH)
Test-NetConnection -ComputerName 192.168.1.20 -Port 22

Estes exemplos cobrem os cenários mais comuns: servidores web, servidores de email, acesso remoto e SSH. O output de cada comando mostra o endereço IP resolvido, o resultado do ping e se a porta TCP está acessível (TcpTestSucceeded: True).

Testar Múltiplas Portas

Quando precisamos de testar várias portas ao mesmo tempo, escrever comandos individuais é impraticável. O PowerShell permite automatizar este processo com um loop simples:

# Testar múltiplas portas
$portas = @(80, 443, 25, 3389, 22)
foreach ($porta in $portas) {
    $resultado = Test-NetConnection -ComputerName kbase.pt -Port $porta
    Write-Host "Porta $porta : $($resultado.TcpTestSucceeded)"
}

Para um output mais organizado em formato de tabela, podemos usar PSCustomObject:

# Output em formato de tabela
$portas = @(80, 443, 25, 3389, 22)
$resultados = foreach ($porta in $portas) {
    $teste = Test-NetConnection -ComputerName kbase.pt -Port $porta -WarningAction SilentlyContinue
    [PSCustomObject]@{
        Porta    = $porta
        Aberta   = $teste.TcpTestSucceeded
        Endereco = $teste.RemoteAddress
    }
}
$resultados | Format-Table -AutoSize

Este script testa todas as portas do array e apresenta os resultados numa tabela limpa com o número da porta, estado (aberta/fechada) e endereço IP resolvido. É particularmente útil para auditorias de segurança ou para verificar que todas as portas necessárias estão abertas após uma alteração de firewall.

Test-NetConnection vs Telnet

Embora ambos sirvam para testar portas TCP, há diferenças significativas entre as duas ferramentas. A tabela seguinte resume as principais:

Característica Test-NetConnection Telnet
Instalado por defeito ✓ Sim ✗ Não, precisa de activação
Resolução DNS automática ✓ Sim ✗ Não
Teste de ping integrado ✓ Sim ✗ Não
Output estruturado (objectos) ✓ Sim, devolve objectos ✗ Não, texto simples
Suporte para scripts ✓ Excelente (loops, pipelines) ✗ Limitado
Encriptação Não envia dados (apenas testa) Texto simples
Interface interactiva ✗ Não ✓ Sim
Velocidade Rápido (timeout configurável) Rápido

Em resumo, o Test-NetConnection é superior em quase todos os cenários de diagnóstico. O Telnet mantém uma vantagem: a sua interface interactiva permite não só testar a porta, mas também enviar comandos manuais (útil para falar com servidores SMTP, FTP ou HTTP a um nível baixo). No entanto, para um simples teste de “porta aberta/fechada”, o PowerShell é a escolha correcta.

Outros Métodos

Para além do Test-NetConnection, o PowerShell oferece outras formas de testar ligações de rede. Estes métodos são úteis em sistemas mais antigos ou quando precisamos de um controlo mais granular.

TcpClient (.NET):

# Alternativa com TcpClient (.NET)
$tcp = New-Object System.Net.Sockets.TcpClient
$tcp.Connect("kbase.pt", 443)
if ($tcp.Connected) { Write-Host "Porta aberta" }
$tcp.Close()

Este método usa a classe TcpClient do .NET directamente. É mais rápido que o Test-NetConnection porque não faz resolução DNS nem ping — apenas testa a porta TCP. Útil em scripts onde a velocidade é crítica.

Test-Connection (Ping):

# Testar conectividade com ping
Test-Connection -ComputerName kbase.pt -Count 4

O Test-Connection envia pacotes ICMP (ping) para verificar se um host está acessível. Não testa portas TCP, mas é útil para verificar a conectividade básica antes de testar portas específicas.

Resolve-DnsName (DNS):

# Resolver nome DNS
Resolve-DnsName -Name kbase.pt -Type A

O Resolve-DnsName resolve nomes DNS e apresenta os registos. É útil para verificar se o domínio resolve correctamente antes de testar a porta — se o DNS falha, o teste de porta também vai falhar.

Erros Comuns e Checklist

Quando um teste de porta falha, a causa nem sempre é óbvia. A tabela seguinte resume os erros mais comuns e as possíveis causas:

Sintoma Causa provável Solução
TcpTestSucceeded: False Porta fechada ou firewall a bloquear Verificar firewall local e remota; confirmar que o serviço está a correr
Timeout sem resposta Host inacessível ou firewall a descartar pacotes Fazer ping ao host; verificar rotas e regras de firewall
Erro de resolução DNS Nome não resolve para nenhum IP Usar Resolve-DnsName; verificar servidores DNS
Ligação recusada imediatamente Host alcançável mas porta não tem serviço activo Confirmar que o serviço está instalado e a correr no destino
Lentidão excessiva no teste DNS lento ou rota longa Testar com IP directo; verificar latência com Test-Connection

Checklist de diagnóstico:

  • Confirmar que o nome resolve correctamente com Resolve-DnsName
  • Verificar conectividade básica com Test-Connection (ping)
  • Testar a porta com Test-NetConnection -Port
  • Confirmar que o serviço está a correr no servidor de destino
  • Verificar regras de firewall no Windows (Defender) e em routers/switches
  • Testar com endereço IP em vez de nome para isolar problemas de DNS
  • Confirmar que não há VPN ou proxy a interferir com a ligação
  • Verificar se a porta não foi alterada para um valor não standard (ex: 8443 em vez de 443)

Artigos relacionados: