Como Abrir Portas no Windows Utilizando o PowerShell

1. Identificando as portas necessárias#

Antes de liberar qualquer porta, você precisa saber quais portas o seu programa ou serviço utiliza e se elas são TCP ou UDP. Alguns serviços conhecidos, como VPN, já têm portas padronizadas:

Quando o programa não é conhecido ou não tem documentação clara sobre as portas, você pode descobrir isso rodando o netstat no computador onde ele já está em execução:

netstat -ano | findstr "7000 7001 9500 9501 9502"

O que esse comando faz: o netstat -ano lista todas as conexões e portas ativas na máquina, mostrando o protocolo (TCP ou UDP), o estado (ex: LISTENING) e o PID (identificador numérico do processo dono daquela porta). O findstr filtra a saída para mostrar só as linhas que contêm os números de porta que você está procurando — troque "7000 7001 9500 9501 9502" pelas portas do seu programa.

Para descobrir qual programa é esse processo a partir do PID encontrado:

tasklist /FI "PID eq <numero_do_pid>"

O que esse comando faz: o tasklist lista os processos em execução no Windows, e o parâmetro /FI "PID eq <numero>" filtra o resultado para mostrar apenas o processo com aquele PID específico — assim você confirma o nome do programa (ex: servidor.exe) associado à porta.

2. Criando as regras de firewall via PowerShell#

Com as portas e protocolos identificados, o comando básico para liberar uma porta de entrada é:

New-NetFirewallRule -DisplayName "VPN SSTP 443" -Direction Inbound -Protocol TCP -LocalPort 443 -Action Allow

O que cada parâmetro faz:

Liberando várias portas de uma vez#

Se você precisa abrir várias portas do mesmo programa, o jeito mais prático é usar um laço foreach:

$portas = 7000,7001,9500,9501,9502
foreach ($p in $portas) {
    New-NetFirewallRule -DisplayName "App TCP $p" -Direction Inbound -Protocol TCP -LocalPort $p -Action Allow
}

O que esse script faz: a primeira linha cria uma variável $portas contendo a lista de números de porta que você quer abrir. O foreach ($p in $portas) percorre essa lista item por item, executando o New-NetFirewallRule uma vez para cada porta — ou seja, ele cria uma regra individual para cada uma, com nomes como "App TCP 7000", "App TCP 7001" etc. Isso evita ter que digitar o mesmo comando várias vezes. Sempre rode como Administrador (PowerShell → botão direito → "Executar como administrador").

Conferindo se as regras foram criadas#

Get-NetFirewallRule -DisplayName "App TCP*" | Format-Table DisplayName, Enabled, Direction, Action

O que esse comando faz: o Get-NetFirewallRule -DisplayName "App TCP*" busca todas as regras cujo nome começa com "App TCP" (o * é um curinga). O | Format-Table pega esse resultado e organiza em formato de tabela, mostrando apenas as colunas úteis: nome, se está ativa (Enabled), direção e ação. Se todas aparecerem com Enabled: True, está tudo liberado.

3. Cenário 1: acesso via VPN — restringindo por segurança#

Se o acesso ao servidor vai acontecer por uma VPN (RadminVPN, WireGuard, OpenVPN, etc.), o ideal é não deixar a porta acessível para qualquer rede que o servidor enxergue — só para quem está dentro do túnel da VPN. Existem duas formas de fazer isso.

Opção 1 — Restringir por IP de origem#

New-NetFirewallRule -DisplayName "App TCP 7000" -Direction Inbound -Protocol TCP -LocalPort 7000 -RemoteAddress 10.8.0.0/24 -Action Allow

O que o -RemoteAddress faz: limita a regra para que só aceite conexões vindas de um IP específico ou de uma faixa de IPs (notação CIDR). No exemplo, 10.8.0.0/24 representa toda a sub-rede da VPN — troque pelo valor real da sua rede. Assim, mesmo que a porta esteja "aberta", só quem tiver um IP dentro dessa faixa consegue se conectar.

Opção 2 — Restringir pela interface de rede (recomendado)#

Em vez de mexer com IP, você pode liberar a porta apenas na placa de rede virtual da VPN. Isso funciona independente do IP que o cliente receber:

Get-NetAdapter | Where-Object {$_.InterfaceDescription -like "*Radmin*"}

O que esse comando faz: o Get-NetAdapter lista todos os adaptadores de rede do computador (físicos e virtuais). O Where-Object {$_.InterfaceDescription -like "*Radmin*"} filtra essa lista, mostrando só o(s) adaptador(es) cuja descrição contenha "Radmin" — assim você descobre o nome exato do adaptador virtual da VPN (troque "Radmin" pelo nome da sua VPN, se for outra).

Depois, use esse nome no parâmetro -InterfaceAlias:

$portas = 7000,7001,9500,9501,9502
$interfaceVPN = "Radmin VPN"   # ajuste pro nome exato do adaptador

foreach ($p in $portas) {
    New-NetFirewallRule -DisplayName "App TCP $p (VPN)" -Direction Inbound -Protocol TCP -LocalPort $p -InterfaceAlias $interfaceVPN -Action Allow
}

O que o -InterfaceAlias faz: restringe a regra para valer apenas no tráfego que passa por aquela interface de rede específica (nesse caso, o adaptador virtual da VPN). Mesmo que o servidor tenha outras conexões de rede (Wi-Fi, cabo, etc.), a porta só fica acessível por quem estiver dentro da VPN.

Quando é seguro liberar sem restrição? Se o servidor não tem IP público exposto — ou seja, só é acessível pela rede local e por um túnel de VPN — liberar a porta sem -RemoteAddress ou -InterfaceAlias não representa um risco grave, já que só quem já consegue alcançar o servidor (rede local ou VPN) vai conseguir usar a porta. O cuidado extra passa a valer se, no futuro, alguém configurar redirecionamento de porta no roteador ou o servidor ganhar um IP público direto — que é justamente o próximo cenário.

4. Cenário 2: acesso via IP público#

Se em vez de VPN você (ou quem for acessar o programa) vai se conectar diretamente pela internet, usando o IP público do servidor, o procedimento muda em dois pontos importantes: o firewall do Windows e o roteador.

4.1. No roteador: redirecionamento de porta (port forwarding)#

Diferente da VPN, o IP público normalmente pertence ao roteador, não ao servidor diretamente (a não ser que o servidor esteja em uma nuvem com IP público próprio). Isso significa que, além de liberar a porta no Windows Firewall, é preciso configurar o roteador para redirecionar (fazer port forward) o tráfego externo daquela porta para o IP local do servidor na rede. Esse passo é feito no painel administrativo do roteador (varia por fabricante) e não pelo PowerShell.

4.2. No Windows Firewall: atenção ao perfil de rede#

As regras criadas com New-NetFirewallRule valem, por padrão, para os três perfis de rede do Windows: Domain, Private e Public. Quando o acesso vem da internet, o tráfego chega pelo perfil Public — então é fundamental garantir que a regra realmente cobre esse perfil:

New-NetFirewallRule -DisplayName "App TCP 7000 (Internet)" -Direction Inbound -Protocol TCP -LocalPort 7000 -Profile Public -Action Allow

O que o -Profile Public faz: restringe (ou nesse caso, garante) que a regra se aplique ao perfil de rede "Público", que é o perfil que o Windows usa para conexões menos confiáveis, como a internet. Sem exposição de VPN ou rede local isolada de por meio, é esse perfil que entra em jogo quando o tráfego vem de fora.

4.3. Cuidados de segurança extras com IP público#

Expor uma porta diretamente para a internet é bem mais arriscado do que dentro de uma VPN, porque qualquer pessoa no mundo pode tentar se conectar nela, não só quem está na sua rede ou túnel. Alguns cuidados recomendados:

• Restrinja por IP sempre que possível, usando -RemoteAddress com o IP fixo de quem vai acessar (se for um IP fixo conhecido) — assim você mantém a porta aberta só para a internet, mas fechada para todo o resto.
• Use senhas fortes e autenticação no programa que está escutando na porta, já que ela ficará exposta publicamente.
• Evite abrir portas de gerenciamento (como RDP na porta 3389) diretamente para a internet sem VPN — prefira usar VPN mesmo para esses casos.
• Monitore tentativas de conexão periodicamente, já que portas expostas na internet costumam receber varreduras automatizadas de bots.

5. E as regras de saída (Outbound)?#

Não é necessário criar regras de saída na maioria dos casos. Por padrão, o Windows Firewall funciona assim:

• Entrada (Inbound): bloqueia tudo, exceto o que tiver regra explícita permitindo — por isso é preciso criar as regras acima.
• Saída (Outbound): permite tudo, exceto o que tiver regra explícita bloqueando — por isso normalmente não é preciso mexer nela.

Você pode confirmar a política padrão do seu servidor com:

Get-NetFirewallProfile | Select-Object Name, DefaultInboundAction, DefaultOutboundAction

O que esse comando faz: o Get-NetFirewallProfile retorna as configurações padrão de cada perfil de rede (Domain, Private, Public). O Select-Object filtra a saída para mostrar só o nome do perfil e as ações padrão de entrada e saída. Se o retorno mostrar DefaultOutboundAction : Allow nos três perfis, a saída já está liberada por padrão, e as respostas das conexões que os clientes iniciarem saem normalmente, sem necessidade de regra adicional.

6. Testando se a porta está realmente aberta#

Depois de criar as regras (e, se for o caso, configurar o redirecionamento no roteador), o teste final é feito a partir de outro computador — na mesma rede/VPN, ou de fora, se o cenário for de IP público — usando o Test-NetConnection:

Test-NetConnection -ComputerName <ip-do-servidor> -Port 7000

O que esse comando faz: o Test-NetConnection tenta abrir uma conexão TCP real com o IP e a porta informados, simulando o que o programa cliente faria. O resultado traz campos como RemoteAddress, RemotePort, InterfaceAlias (por qual interface de rede o teste saiu) e, o mais importante, TcpTestSucceeded. Se esse último campo vier como True, a porta está acessível corretamente.

Para conferir todas as portas de uma vez:

Test-NetConnection -ComputerName <ip-do-servidor> -Port 7001
Test-NetConnection -ComputerName <ip-do-servidor> -Port 9500
Test-NetConnection -ComputerName <ip-do-servidor> -Port 9501
Test-NetConnection -ComputerName <ip-do-servidor> -Port 9502

Nota sobre Test-NetConnection em portas UDP: esse cmdlet testa nativamente conexões TCP. Para UDP, como o protocolo não estabelece uma "conexão" da mesma forma, o teste é menos confiável — o ideal nesse caso é testar diretamente com o programa/cliente real.

Resumo#

Com esses passos, você consegue abrir, restringir e validar portas no Windows de forma segura e reproduzível usando apenas o PowerShell — seja o acesso feito por VPN ou diretamente pela internet com IP público.