ASA: porto VPN e PAT estático de DMZ nunha soa IP pública

Dous servizos, unha dirección pública e un nome DNS que parece reservar un porto. Non o fai. Antes de publicar un servidor DMZ xunto á entrada VPN nun ASA, anote as tuplas de entrada e compróbeas en orde; o primeiro campo que coincide cun servizo existente é onde se detén o plan. Todo o seguinte asume que a VPN termina no propio dispositivo, non nun servidor interno.

Escriba os cinco campos antes de escribir o comando

Para cada entrada pública, rexistre a familia de direccións, a dirección pública, o transporte, o porto público e o propietario. O propietario é un servizo local do ASA ou un servidor interno traducido. Dúas entradas poden compartir unha dirección e seguir sendo tuplas distintas, e dúas entradas poden verse diferentes nun diagrama mentres chocan no dispositivo.

Manteña unha segunda columna para o porto real, o que o servidor interno escoita de verdade. O porto público e o porto real son eleccións independentes, e no momento en que os xunta nunha soa columna perde a capacidade de ler a súa propia tradución máis adiante.

Lea correctamente as posicións real e mapeada

Parta da tupla que xa ten, non do servidor que quere engadir. Unha división ilustrativa mantén a entrada VPN aprobada no TCP 443 público e publica un servidor DMZ HTTPS no TCP 8443 público mentres ese servidor segue escoitando no 443:

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

No comando despregado, o servizo real e o servizo mapeado ocupan posicións fixas, e invertelos describe un mapeamento distinto, non un roto. Esta é a forma máis común de que unha tradución funcional se converta nun crebacabezas: a configuración é válida, simplemente apunta a outro sitio.

A guía de NAT de ASA 9.16 de Cisco documenta o PAT estático, o uso da dirección de interface e os significados de porto real fronte a mapeado. Lea a sección da versión que realmente executa; un comando recordado dunha plataforma anterior non é unha configuración actual completa.

Conte o transporte como parte da reserva

TCP 443 e UDP 443 son tuplas distintas, e esa diferenza non lle regala a de UDP. Unha VPN pode ter listeners TLS e DTLS separados, e outros servizos configurados poden xa ter o transporte que vostede quere. Inventarie os listeners efectivos e a política de acceso en lugar de supor que a páxina web é toda a entrada VPN.

Un segundo nome de host que resolve á mesma dirección tampouco resolve unha colisión a nivel de transporte. DNS é un mapeamento de nome a dirección, non un corredor de portos, e publicar un servidor mediante PAT non é a mesma operación que mover o listener VPN a outro porto.

Se a entrada VPN ten que moverse de verdade, catro cousas cambian á vez: o perfil do cliente, a URL pública, o filtrado augas arriba e cada transporte que usa o despregamento. Fágaas nunha soa ventá en lugar de unha por unha. Manteña aberta unha ruta de xestión separada cara ao dispositivo antes de tocar o servizo que usa para chegar a el. Sen unha segunda ruta, o movemento é un cambio do que non pode volver atrás desde fóra.

Verifique desde fóra con conexións novas

Permita só a aplicación DMZ prevista baixo a política de acceso efectiva e logo comprobe a orde de tradución correspondente, a ruta de retorno do servidor e o nome de host do certificado. O PAT cambia o destino de rede; non concede acceso á aplicación nin repara un certificado que nomea outro host.

Probe ambos os servizos con conexións novas desde un host externo autorizado: a VPN debería seguir establecéndose e a petición DMZ debería chegar ao seu listener previsto. Unha sesión establecida pode conservar estado anterior, así que non demostra nada sobre un mapeamento que cambiou hai un minuto.

Pecha o bucle actualizando o inventario de entradas co que despregou, incluído calquera listener que descubriu en lugar de crear. A seguinte persoa que publique un servizo nesa dirección comezará pola súa táboa, e unha fila equivocada alí custa máis que un comando equivocado aquí.