ASA: porta VPN e PAT statico DMZ su un solo IP pubblico
Un indirizzo pubblico, due servizi. Inventariate indirizzo, trasporto e porta per il listener VPN e il PAT della DMZ prima che uno rivendichi la voce dell'altro.
Due servizi, un indirizzo pubblico e un nome DNS che sembra riservare una porta. Non lo fa. Prima di pubblicare un server DMZ accanto alla voce VPN su un ASA, annotate le tuple di ingresso e controllatele in ordine; il primo campo che corrisponde a un servizio esistente è il punto in cui il piano si ferma. Tutto quanto segue presuppone che la VPN termini sull'appliance stessa, non su un server interno.
Scrivete i cinque campi prima di scrivere il comando
Per ogni voce pubblica, registrate la famiglia di indirizzi, l'indirizzo pubblico, il trasporto, la porta pubblica e il proprietario. Il proprietario è un servizio locale all'ASA oppure un server interno tradotto. Due voci possono condividere un indirizzo e restare tuple diverse, e due voci possono apparire diverse in uno schema mentre collidono sull'appliance.
Tenete una seconda colonna per la porta reale, quella su cui il server interno ascolta davvero. La porta pubblica e la porta reale sono scelte indipendenti, e nel momento in cui le unite in un'unica colonna perdete la capacità di rileggere la vostra stessa traduzione più avanti.
| Public entry | Owner | Real side |
|---|---|---|
| TCP 443 on the outside address | ASA VPN listener | Appliance-local, no translation |
| TCP 8443 on the outside address | Static PAT | DMZ server TCP 443 |
| UDP 443 on the outside address | Check the effective listeners | Possibly the VPN data path |
Leggete correttamente le posizioni reale e mappata
Partite dalla tupla che avete già, non dal server che volete aggiungere. Una suddivisione illustrativa mantiene la voce VPN approvata sulla TCP 443 pubblica e pubblica un server DMZ HTTPS sulla TCP 8443 pubblica mentre quel server continua ad ascoltare sulla 443:
Public TCP 443 -> ASA VPN listener
Public TCP 8443 -> DMZ server TCP 443
Nel comando distribuito, il servizio reale e il servizio mappato stanno in posizioni fisse, e invertirli descrive una mappatura diversa, non una rotta. È il modo più comune in cui una traduzione funzionante diventa un rompicapo: la configurazione è valida, punta semplicemente altrove.
La guida NAT di ASA 9.16 di Cisco documenta il PAT statico, l'uso dell'indirizzo di interfaccia e il significato di porta reale rispetto a mappata. Leggete la sezione relativa alla versione che eseguite davvero; un comando ricordato da una piattaforma più vecchia non è una configurazione attuale completa.
Contate il trasporto come parte della prenotazione
TCP 443 e UDP 443 sono tuple diverse, e quella differenza non vi regala la UDP. Una VPN può avere listener TLS e DTLS separati, e altri servizi configurati possono già occupare il trasporto che volete. Inventariate i listener effettivi e la politica di accesso invece di dare per scontato che la pagina web sia tutta la voce VPN.
Un secondo nome host che risolve sullo stesso indirizzo non risolve nemmeno una collisione a livello di trasporto. Il DNS è una mappatura nome-indirizzo, non un intermediario di porte, e pubblicare un server tramite PAT non è la stessa operazione che spostare il listener VPN su un'altra porta.
Se la voce VPN deve davvero spostarsi, quattro cose cambiano insieme: il profilo del client, l'URL pubblico, il filtraggio a monte e ogni trasporto che il deployment usa. Fatele in un'unica finestra invece che una alla volta. Tenete aperto un percorso di gestione separato verso l'appliance prima di toccare il servizio che usate per raggiungerla. Senza un secondo percorso, lo spostamento è un cambiamento da cui non potete tornare indietro dall'esterno.
Verificate dall'esterno con connessioni nuove
Permettete solo l'applicazione DMZ prevista secondo la politica di accesso effettiva, poi controllate l'ordine di traduzione corrispondente, il percorso di ritorno del server e il nome host sul certificato. Il PAT cambia la destinazione di rete; non concede l'accesso all'applicazione e non ripara un certificato che nomina un altro host.
Provate entrambi i servizi con connessioni nuove da un host esterno autorizzato: la VPN dovrebbe ancora stabilirsi e la richiesta DMZ dovrebbe raggiungere il listener previsto. Una sessione stabilita può conservare lo stato precedente, quindi non dimostra nulla su una mappatura che avete cambiato un minuto fa.
Chiudete il ciclo aggiornando l'inventario delle voci con ciò che avete distribuito, compreso ogni listener che avete scoperto invece di creare. La prossima persona che pubblicherà un servizio su quell'indirizzo partirà dalla vostra tabella, e una riga sbagliata lì costa più di un comando sbagliato qui.