ASA: VPN-port og statisk DMZ-PAT på éin offentleg IP

To tenester, éin offentleg adresse og eit DNS-namn som kjennest som det reserverer ein port. Det gjer det ikkje. Før du publiserer ein DMZ-tenar ved sida av VPN-posten på ein ASA, skriv ned post-tupla og kontroller dei i rekkjefølgje; det første feltet som samsvarar med ei eksisterande teneste, er der planen stoggar. Alt nedanfor føreset at VPN-en terminerer på sjølve eininga, ikkje på ein intern tenar.

Skriv dei fem felta før du skriv kommandoen

For kvar offentleg post, noter adressefamilien, den offentlege adressa, transporten, den offentlege porten og eigaren. Eigaren er anten ei ASA-lokal teneste eller ein omsett intern tenar. To postar kan dela ei adresse og likevel vere ulike tuplar, og to postar kan sjå ulike ut på eit diagram medan dei kolliderer på eininga.

Hald ein andre kolonne for den ekte porten, den den interne tenaren faktisk lyttar på. Den offentlege porten og den ekte porten er uavhengige val, og i det augneblunken du slår dei saman i éin kolonne, mistar du evna til å lese di eiga omsetjing seinare.

Les dei ekte og dei mappa posisjonane rett

Start frå tupelen du allereie har, ikkje frå tenaren du vil leggje til. Ei illustrerande oppdeling held den godkjende VPN-posten på offentleg TCP 443 og publiserer ein DMZ HTTPS-tenar på offentleg TCP 8443 medan den tenaren held fram med å lytte på 443:

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

I den utrulla kommandoen står den ekte tenesta og den mappa tenesta på faste posisjonar, og å bytte dei om skildrar ein annan mapping, ikkje ein øydelagd. Det er den vanlegaste måten ei fungerande omsetjing blir eit gåte på: konfigurasjonen er gyldig, han peikar berre ein annan stad.

Ciscos ASA 9.16 NAT-vegleiing dokumenterer statisk PAT, bruk av grensesnittadresse og tydinga av ekte kontra mappa port. Les avsnittet for utgåva du faktisk køyrer; ein kommando hugsa frå ein eldre plattform er ikkje ein komplett gjeldande konfigurasjon.

Rekn transporten som ein del av reservasjonen

TCP 443 og UDP 443 er ulike tuplar, og den skilnaden gjev deg ikkje UDP-en gratis. Ein VPN kan ha separate TLS- og DTLS-lyttarar, og andre konfigurerte tenester kan alt halde transporten du vil ha. Kartlegg dei effektive lyttarane og tilgangspolicyen i staden for å gå ut frå at nettsida er heile VPN-posten.

Eit andre vertsnamn som løyser til same adresse løyser heller ikkje ein kollisjon på transportnivå. DNS er ein namn-til-adresse-mapping, ikkje ein portmeklar, og å publisere ein tenar via PAT er ikkje same operasjon som å flytte VPN-lyttaren til ein annan port.

Viss VPN-posten verkeleg må flyttast, endrar fire ting seg saman: klientprofilen, den offentlege URL-en, filtreringa oppstraums og kvar transport som utrullinga brukar. Gjer dei i eitt vindauge i staden for ein om gongen. Hald ein separat administrasjonsveg til eininga open før du rører tenesta du brukar for å nå ho. Utan ein andre veg er flyttinga ei endring du ikkje kan trekkje tilbake utanfrå.

Stadfest utanfrå med ferske tilkoplingar

Tillat berre den tiltenkte DMZ-applikasjonen under den effektive tilgangspolicyen, og kontroller deretter den samsvarande omsetjingsrekkjefølgja, returvegen til tenaren og vertsnamnet på sertifikatet. PAT endrar nettverksdestinasjonen; det gjev ikkje applikasjonstilgang og reparerer ikkje eit sertifikat som namngjev ein annan vert.

Test båe tenestene med nye tilkoplingar frå ein autorisert ekstern vert: VPN-en skal framleis etablere, og DMZ-førespurnaden skal nå sin tiltenkte lyttar. Ein etablert sesjon kan halde tidlegare tilstand, så han provar ingenting om ein mapping du endra for eit minutt sidan.

Lukk sløyfa ved å oppdatere post-inventaret med det du rulla ut, inkludert kvar lyttar du oppdaga i staden for oppretta. Den neste personen som publiserer ei teneste på den adressa, startar frå tabellen din, og ei feil rad der kostar meir enn ein feil kommando her.