ASA: VPN-port och statisk DMZ-PAT på en enda publik IP

Två tjänster, en publik adress och ett DNS-namn som känns som om det reserverar en port. Det gör det inte. Innan du publicerar en DMZ-server bredvid VPN-posten på en ASA, skriv ned post-tuplarna och kontrollera dem i ordning; det första fältet som matchar en befintlig tjänst är där planen stannar. Allt nedan förutsätter att VPN:en terminerar på själva enheten, inte på en intern server.

Skriv de fem fälten innan du skriver kommandot

För varje publik post, notera adressfamiljen, den publika adressen, transporten, den publika porten och ägaren. Ägaren är antingen en ASA-lokal tjänst eller en översatt intern server. Två poster kan dela en adress och ändå vara olika tupler, och två poster kan se olika ut i ett diagram medan de kolliderar på enheten.

Håll en andra kolumn för den riktiga porten, den som den interna servern faktiskt lyssnar på. Den publika porten och den riktiga porten är oberoende val, och i samma stund som du slår ihop dem i en kolumn förlorar du förmågan att läsa din egen översättning senare.

Läs de riktiga och de mappade positionerna korrekt

Börja från tupeln du redan har, inte från servern du vill lägga till. En illustrativ uppdelning behåller den godkända VPN-posten på publik TCP 443 och publicerar en DMZ HTTPS-server på publik TCP 8443 medan den servern fortsätter lyssna på 443:

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

I det utrullade kommandot står den riktiga tjänsten och den mappade tjänsten på fasta positioner, och att byta plats på dem beskriver en annan mappning, inte en trasig. Det är det vanligaste sättet en fungerande översättning blir ett pussel: konfigurationen är giltig, den pekar bara någon annanstans.

Ciscos ASA 9.16 NAT-guide dokumenterar statisk PAT, användning av gränssnittsadress och betydelsen av riktig kontra mappad port. Läs avsnittet för den version du faktiskt kör; ett kommando som memorerats från en äldre plattform är inte en komplett aktuell konfiguration.

Räkna transporten som en del av bokningen

TCP 443 och UDP 443 är olika tupler, och den skillnaden ger dig inte UDP gratis. En VPN kan ha separata TLS- och DTLS-lyssnare, och andra konfigurerade tjänster kan redan hålla den transport du vill ha. Inventera de effektiva lyssnarna och åtkomstpolicyn i stället för att anta att webbsidan är hela VPN-posten.

Ett andra värdnamn som löser till samma adress löser inte heller en kollision på transportnivå. DNS är en namn-till-adress-mappning, inte en portmäklare, och att publicera en server via PAT är inte samma operation som att flytta VPN-lyssnaren till en annan port.

Om VPN-posten verkligen måste flyttas ändras fyra saker samtidigt: klientprofilen, den publika URL:en, filtreringen uppströms och varje transport som driftsättningen använder. Gör dem i ett fönster i stället för en i taget. Håll en separat administrationsväg till enheten öppen innan du rör tjänsten du använder för att nå den. Utan en andra väg är flytten en ändring du inte kan ångra utifrån.

Verifiera utifrån med färska anslutningar

Tillåt bara den avsedda DMZ-applikationen enligt den effektiva åtkomstpolicyn, kontrollera sedan den matchande översättningsordningen, serverns returväg och värdnamnet på certifikatet. PAT ändrar nätverksdestinationen; det ger ingen applikationsåtkomst och reparerar inte ett certifikat som namnger en annan värd.

Testa båda tjänsterna med nya anslutningar från en auktoriserad extern värd: VPN:en bör fortfarande etableras, och DMZ-begäran bör nå sin avsedda lyssnare. En etablerad session kan behålla tidigare tillstånd, så den bevisar ingenting om en mappning du ändrade för en minut sedan.

Stäng slingan genom att uppdatera postinventariet med det du rullade ut, inklusive varje lyssnare du upptäckte i stället för skapade. Nästa person som publicerar en tjänst på den adressen börjar från din tabell, och en felaktig rad där kostar mer än ett felaktigt kommando här.