Firewall na nuvem contra firewall do host para um servidor VPN

Permita a porta VPN na política da nuvem e o handshake ainda pode morrer na instância: o convidado executa o próprio filtro e a própria vinculação do listener, e qualquer um dos dois pode descartar o que a nuvem aprovou. O contrário também acontece, quando uma regra do host permite a porta e uma política acima a descarta primeiro. Dois proprietários, dois conjuntos de regras, um único caminho de pacotes. Percorra-o em ordem em vez de adivinhar na camada mais suspeita.

Comece pela borda e siga para dentro

A ordem é fixa: endpoint público, interface do recurso, política da nuvem anexada, endereço do convidado, listener do processo, regras locais de entrada. Cada etapa deixa o pacote passar ou encerra a investigação, e por isso começar pelo convidado é o que mais perde tempo.

O tráfego de cliente encaminhado é uma etapa separada, inspecionada depois de desencapsular o túnel. A camada da nuvem só vê o túnel externo, então pode aprovar uma conexão e ainda assim não ter nada a ver com uma requisição de serviço interna. Um túnel que conecta mas não alcança um host interno costuma apontar para o encaminhamento, não para uma porta fechada.

Leia a política da nuvem antes de tocar no convidado

Confirme a regra de entrada da porta VPN, o protocolo e o escopo de origem que corresponde ao seu cliente de teste. Verifique também a lista de controle de acesso da sub-rede: um segundo filtro com regras e padrões próprios. Os dois precisam permitir o fluxo antes de um pacote chegar à instância. Permissão em um e negação no outro é a forma habitual deste defeito.

Estreite o escopo até que signifique algo. Abrir a porta VPN para toda a internet é fácil de provar e difícil de defender, enquanto uma regra fixada a um endereço quebra quando o cliente de teste muda de rede. Anote o identificador da regra e o proprietário da política, para que a próxima mudança seja rastreável até uma pessoa.

Confirme o listener e depois a cadeia de entrada

Na instância, verifique se o processo VPN está vinculado ao endereço e à porta que você espera, por exemplo com ss -lntp 'sport = :1194'. Um daemon vinculado apenas a 127.0.0.1 aceita clientes locais e nada através do túnel, o que de fora parece exatamente uma porta filtrada.

Depois leia as regras locais na sintaxe que você usaria para alterá-las, como iptables -S INPUT ou nft list chain inet filter input. Uma regra escrita em um arquivo mas nunca carregada, ou um descarte padrão sem permissão correspondente, descarta pacotes em silêncio. Para um gateway que encaminha, verifique também as configurações de encaminhamento e de caminho inverso. São elas que decidem o que acontece com pacotes roteados através da instância e não endereçados a ela.

Com estado em uma camada, sem estado na seguinte

Os grupos de segurança lembram os fluxos que permitiram e deixam as respostas voltar. As listas de controle de acesso de sub-rede e muitos firewalls do host não mantêm esse estado, então uma regra que cobre apenas a direção de saída deixa a requisição passar e descarta a resposta. Nunca leve uma suposição sobre tráfego de retorno entre camadas sem ler a regra da segunda camada (second layer's rule).

Os contadores resolvem isso mais rápido do que ler cada regra da conta. Um contador que sobe significa que o pacote chegou e ali foi descartado, enquanto um congelado em zero significa que nunca chegou tão longe; iptables -vnL INPUT e nft list ruleset mostram esses números quando as regras foram carregadas com contadores.

Teste com uma sessão nova, não com uma viva

Deixe a rede de origem e o perfil de teste intactos enquanto compara visões, e abra uma conexão nova depois de cada mudança. Alcançar o console web na 443 não diz nada sobre se o daemon VPN está vinculado à 1194, então teste a porta de que você precisa. Uma sessão existente é a pior testemunha aqui. Ela continua funcionando enquanto cada novo login é recusado.

Antes de editar uma política remota, garanta um caminho de volta que não dependa do caminho que você está mudando. Depois abra uma segunda sessão de administração ao lado do teste VPN: uma estabelecida antes pode sobreviver à regra que bloqueia as novas. Anote os dois proprietários das políticas para que nenhuma reconstrução restaure metade do caminho; se as duas camadas concordam e o túnel ainda falha, capture na interface do convidado e confira o endereço e a porta que o cliente realmente usa.