ASA: VPN-port og statisk DMZ-PAT på én offentlig IP

To tjenester, én offentlig adresse og et DNS-navn som føles som det reserverer en port. Det gjør det ikke. Før du publiserer en DMZ-server ved siden av VPN-posten på en ASA, skriv ned post-tuplene og kontroller dem i rekkefølge; det første feltet som samsvarer med en eksisterende tjeneste, er der planen stopper. Alt under forutsetter at VPN-en terminerer på selve enheten, ikke på en intern server.

Skriv de fem feltene før du skriver kommandoen

For hver offentlig post, noter adressefamilien, den offentlige adressen, transporten, den offentlige porten og eieren. Eieren er enten en ASA-lokal tjeneste eller en oversatt intern server. To poster kan dele en adresse og likevel være forskjellige tupler, og to poster kan se forskjellige ut på et diagram mens de kolliderer på enheten.

Hold en andre kolonne for den ekte porten, den den interne serveren faktisk lytter på. Den offentlige porten og den ekte porten er uavhengige valg, og i det øyeblikket du slår dem sammen i én kolonne, mister du evnen til å lese din egen oversettelse senere.

Les de ekte og de mappede posisjonene riktig

Start fra tupelen du allerede har, ikke fra serveren du vil legge til. En illustrerende oppdeling holder den godkjente VPN-posten på offentlig TCP 443 og publiserer en DMZ HTTPS-server på offentlig TCP 8443 mens den serveren fortsetter å lytte på 443:

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

I den utrullede kommandoen står den ekte tjenesten og den mappede tjenesten på faste posisjoner, og å bytte dem om beskriver en annen mapping snarere enn en ødelagt. Det er den vanligste måten en fungerende oversettelse blir en gåte: konfigurasjonen er gyldig, den peker bare et annet sted.

Ciscos ASA 9.16 NAT-veiledning dokumenterer statisk PAT, bruk av grensesnittadresse og betydningen av ekte versus mappet port. Les avsnittet for utgivelsen du faktisk kjører; en kommando husket fra en eldre plattform er ikke en komplett gjeldende konfigurasjon.

Regn transporten som en del av reservasjonen

TCP 443 og UDP 443 er forskjellige tupler, og den forskjellen gir deg ikke UDP-en gratis. En VPN kan ha separate TLS- og DTLS-lyttere, og andre konfigurerte tjenester kan allerede holde transporten du vil ha. Kartlegg de effektive lytterne og tilgangspolicyen i stedet for å anta at nettsiden er hele VPN-posten.

Et andre vertsnavn som løser til samme adresse løser heller ikke en kollisjon på transportnivå. DNS er en navn-til-adresse-mapping, ikke en portmegler, og å publisere en server via PAT er ikke samme operasjon som å flytte VPN-lytteren til en annen port.

Hvis VPN-posten virkelig må flyttes, endres fire ting sammen: klientprofilen, den offentlige URL-en, filtreringen oppstrøms og hver transport som utrullingen bruker. Gjør dem i ett vindu i stedet for én om gangen. Hold en separat administrasjonsvei til enheten åpen før du berører tjenesten du bruker for å nå den. Uten en andre vei er flyttingen en endring du ikke kan trekke tilbake utenfra.

Verifiser utenfra med ferske tilkoblinger

Tillat bare den tiltenkte DMZ-applikasjonen under den effektive tilgangspolicyen, og kontroller deretter den samsvarende oversettelsesrekkefølgen, serverens returvei og vertsnavnet på sertifikatet. PAT endrer nettverksdestinasjonen; det gir ikke applikasjonstilgang og reparerer ikke et sertifikat som navngir en annen vert.

Test begge tjenestene med nye tilkoblinger fra en autorisert ekstern vert: VPN-en skal fortsatt etablere, og DMZ-forespørselen skal nå sin tiltenkte lytter. En etablert sesjon kan beholde tidligere tilstand, så den beviser ingenting om en mapping du endret for et minutt siden.

Lukk sløyfen ved å oppdatere post-inventaret med det du rullet ut, inkludert enhver lytter du oppdaget i stedet for opprettet. Den neste personen som publiserer en tjeneste på den adressen, starter fra tabellen din, og en feil rad der koster mer enn en feil kommando her.