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

To tjenester, én offentlig adresse og et DNS-navn, der føles som om det reserverer en port. Det gør det ikke. Før du publicerer en DMZ-server ved siden af VPN-posten på en ASA, skriv post-tuplerne ned og kontrollér dem i rækkefølge; det første felt, der matcher en eksisterende tjeneste, er der, hvor planen stopper. Alt nedenfor forudsætter, at VPN'en terminerer på selve enheden, ikke på en intern server.

Skriv de fem felter, før du skriver kommandoen

For hver offentlig post skal du notere adressefamilien, den offentlige adresse, transporten, den offentlige port og ejeren. Ejeren er enten en ASA-lokal tjeneste eller en oversat intern server. To poster kan dele en adresse og stadig være forskellige tupler, og to poster kan se forskellige ud på et diagram, mens de kolliderer på enheden.

Hold en anden kolonne til den rigtige port, den den interne server faktisk lytter på. Den offentlige port og den rigtige port er uafhængige valg, og i det øjeblik du slår dem sammen i én kolonne, mister du evnen til at læse din egen oversættelse senere.

Læs de rigtige og de mappet positioner korrekt

Start fra den tuple, du allerede har, ikke fra den server, du vil tilføje. En illustrativ opdeling holder den godkendte VPN-post på offentlig TCP 443 og publicerer en DMZ HTTPS-server på offentlig TCP 8443, mens den server bliver ved med at lytte på 443:

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

I den udrullede kommando står den rigtige tjeneste og den mappet tjeneste på faste positioner, og at bytte dem om beskriver en anden mapping snarere end en ødelagt. Det er den mest almindelige måde, en fungerende oversættelse bliver til et puslespil på: konfigurationen er gyldig, den peger bare et andet sted hen.

Ciscos ASA 9.16 NAT-vejledning dokumenterer statisk PAT, brug af interface-adresse og betydningen af rigtig versus mappet port. Læs afsnittet for den udgivelse, du faktisk kører; en kommando husket fra en ældre platform er ikke en komplet aktuel konfiguration.

Regn transport med som en del af reservationen

TCP 443 og UDP 443 er forskellige tupler, og den forskel giver dig ikke UDP'en gratis. En VPN kan have separate TLS- og DTLS-lyttere, og andre konfigurerede tjenester kan allerede holde den transport, du vil have. Kortlæg de effektive lyttere og adgangspolitikken i stedet for at antage, at websiden er hele VPN-posten.

Et andet hostnavn, der opløser til samme adresse, løser heller ikke en kollision på transportniveau. DNS er en navn-til-adresse-mapping, ikke en port-mægler, og at publicere en server via PAT er ikke den samme handling som at flytte VPN-lytteren til en anden port.

Hvis VPN-posten virkelig skal flyttes, ændres fire ting sammen: klientprofilen, den offentlige URL, filtreringen opstrøms og hver transport, som udrulningen bruger. Gør dem i ét vindue i stedet for én ad gangen. Hold en separat administrationsvej til enheden åben, før du rører den tjeneste, du bruger til at nå den. Uden en anden vej er flytningen en ændring, du ikke kan trække tilbage udefra.

Verificér udefra med friske forbindelser

Tillad kun den tilsigtede DMZ-applikation under den effektive adgangspolitik, og kontrollér derefter den matchende oversættelsesrækkefølge, serverens returvej og hostnavnet på certifikatet. PAT ændrer netværksdestinationen; det giver ikke applikationsadgang og reparerer ikke et certifikat, der nævner en anden host.

Test begge tjenester med nye forbindelser fra en autoriseret ekstern host: VPN'en bør stadig etablere, og DMZ-anmodningen bør nå sin tilsigtede lytter. En etableret session kan beholde tidligere tilstand, så den beviser intet om en mapping, du ændrede for et minut siden.

Luk kredsen ved at opdatere post-inventaret med det, du udrullede, inklusive enhver lytter, du opdagede frem for oprettede. Den næste person, der publicerer en tjeneste på den adresse, starter fra din tabel, og en forkert række der koster mere end en forkert kommando her.