ASA: porta VPN e PAT estático de DMZ num único IP público

Dois serviços, um endereço público e um nome DNS que parece reservar uma porta. Não reserva. Antes de publicar um servidor DMZ ao lado da entrada VPN num ASA, anote as tuplas de entrada e verifique-as em ordem; o primeiro campo que coincide com um serviço existente é onde o plano para. Tudo abaixo pressupõe que a VPN termina no próprio appliance, não num servidor interno.

Escreva os cinco campos antes de escrever o comando

Para cada entrada pública, registre a família de endereços, o endereço público, o transporte, a porta pública e o proprietário. O proprietário é um serviço local ao ASA ou um servidor interno traduzido. Duas entradas podem compartilhar um endereço e ainda assim serem tuplas diferentes, e duas entradas podem parecer diferentes num diagrama enquanto colidem no appliance.

Mantenha uma segunda coluna para a porta real, aquela em que o servidor interno realmente escuta. A porta pública e a porta real são escolhas independentes, e no momento em que você as junta numa única coluna perde a capacidade de reler a sua própria tradução mais tarde.

Leia corretamente as posições real e mapeada

Comece pela tupla que você já tem, não pelo servidor que quer adicionar. Uma divisão ilustrativa mantém a entrada VPN aprovada no TCP 443 público e publica um servidor DMZ HTTPS no TCP 8443 público enquanto esse servidor continua escutando na 443:

Public TCP 443  -> ASA VPN listener
Public TCP 8443 -> DMZ server TCP 443

No comando implantado, o serviço real e o serviço mapeado ficam em posições fixas, e invertê-los descreve um mapeamento diferente, não um quebrado. É a forma mais comum de uma tradução funcional virar um quebra-cabeça: a configuração é válida, ela apenas aponta para outro lugar.

O guia de NAT do ASA 9.16 da Cisco documenta o PAT estático, o uso do endereço de interface e os significados de porta real versus mapeada. Leia a seção da versão que você realmente executa; um comando lembrado de uma plataforma mais antiga não é uma configuração atual completa.

Conte o transporte como parte da reserva

TCP 443 e UDP 443 são tuplas diferentes, e essa diferença não lhe dá a UDP de graça. Uma VPN pode ter listeners TLS e DTLS separados, e outros serviços configurados podem já deter o transporte que você quer. Inventarie os listeners efetivos e a política de acesso em vez de supor que a página web é toda a entrada VPN.

Um segundo nome de host que resolve para o mesmo endereço também não resolve uma colisão em nível de transporte. O DNS é um mapeamento de nome para endereço, não um corretor de portas, e publicar um servidor via PAT não é a mesma operação que mover o listener VPN para outra porta.

Se a entrada VPN realmente precisar mudar, quatro coisas mudam juntas: o perfil do cliente, a URL pública, a filtragem a montante e cada transporte que a implantação usa. Faça-as numa única janela em vez de uma de cada vez. Mantenha um caminho de gestão separado até o appliance aberto antes de tocar no serviço que você usa para alcançá-lo. Sem um segundo caminho, o movimento é uma alteração da qual você não pode recuar de fora.

Verifique de fora com conexões novas

Permita apenas a aplicação DMZ pretendida sob a política de acesso efetiva e depois verifique a ordem de tradução correspondente, o caminho de retorno do servidor e o nome de host no certificado. O PAT muda o destino de rede; não concede acesso à aplicação e não repara um certificado que nomeia outro host.

Teste os dois serviços com conexões novas a partir de um host externo autorizado: a VPN deve continuar a estabelecer e o pedido DMZ deve chegar ao listener pretendido. Uma sessão estabelecida pode manter estado anterior, por isso não prova nada sobre um mapeamento que você alterou há um minuto.

Feche o ciclo atualizando o inventário de entradas com o que você implantou, incluindo qualquer listener que descobriu em vez de criar. A próxima pessoa que publicar um serviço nesse endereço começará pela sua tabela, e uma linha errada ali custa mais do que um comando errado aqui.