ASA: port VPN a statický PAT pro DMZ na jedné veřejné IP

Dvě služby, jedna veřejná adresa a jméno DNS, které vypadá, že si rezervuje port. Nerezervuje. Než publikujete server DMZ vedle záznamu VPN na ASA, zapište si n-tice záznamů a zkontrolujte je v pořadí; první pole, které odpovídá existující službě, je místo, kde se plán zastaví. Vše níže předpokládá, že VPN končí na samotném zařízení, ne na vnitřním serveru.

Napište pět polí, než napíšete příkaz

U každého veřejného záznamu zaznamenejte rodinu adres, veřejnou adresu, transport, veřejný port a vlastníka. Vlastník je buď služba lokální na ASA, nebo přeložený vnitřní server. Dva záznamy mohou sdílet adresu a přesto být různé n-tice a dva záznamy mohou na diagramu vypadat různě, zatímco se na zařízení srážejí.

Držte druhý sloupec pro skutečný port, ten, na kterém vnitřní server opravdu naslouchá. Veřejný port a skutečný port jsou nezávislé volby a ve chvíli, kdy je slijete do jednoho sloupce, ztratíte schopnost později přečíst vlastní překlad.

Čtěte skutečné a mapované pozice správně

Začněte od n-tice, kterou už máte, ne od serveru, který chcete přidat. Ilustrativní rozdělení ponechává schválený záznam VPN na veřejném TCP 443 a publikuje server DMZ HTTPS na veřejném TCP 8443, zatímco tento server dál naslouchá na 443:

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

V nasazeném příkazu stojí skutečná služba a mapovaná služba na pevných pozicích a jejich prohození popisuje jiné mapování, ne rozbité. To je nejběžnější způsob, jak se funkční překlad změní v hádanku: konfigurace je platná, jen ukazuje jinam.

Průvodce ASA 9.16 NAT od Cisco dokumentuje statický PAT, použití adresy rozhraní a význam skutečného versus mapovaného portu. Přečtěte si sekci pro verzi, kterou skutečně provozujete; příkaz zapamatovaný ze starší platformy není úplná současná konfigurace.

Počítejte transport jako součást rezervace

TCP 443 a UDP 443 jsou různé n-tice a tento rozdíl vám tu UDP nedá zdarma. VPN může mít samostatné listenery TLS a DTLS a jiné nakonfigurované služby už mohou držet transport, který chcete. Zapište efektivní listenery a přístupovou politiku, místo abyste předpokládali, že webová stránka je celý záznam VPN.

Druhé jméno hostitele, které se překládá na stejnou adresu, také neřeší kolizi na úrovni transportu. DNS je mapování jména na adresu, ne zprostředkovatel portů, a publikování serveru přes PAT není stejná operace jako přesun listeneru VPN na jiný port.

Pokud se záznam VPN opravdu musí přesunout, mění se najednou čtyři věci: profil klienta, veřejná URL, filtrování výše po cestě a každý transport, který nasazení používá. Udělejte je v jednom okně, ne jeden po druhém. Než se dotknete služby, kterou se k zařízení dostáváte, nechte otevřenou samostatnou cestu pro správu. Bez druhé cesty je přesun změna, kterou zvenčí nevrátíte.

Ověřujte zvenčí čerstvými připojeními

Povolte pouze zamýšlenou aplikaci DMZ podle efektivní přístupové politiky, poté zkontrolujte odpovídající pořadí překladu, návratovou cestu serveru a jméno hostitele v certifikátu. PAT mění síťové určení; nedává přístup k aplikaci a neopravuje certifikát, který jmenuje jiného hostitele.

Otestujte obě služby novými připojeními z autorizovaného vnějšího hostitele: VPN by se měla stále navázat a požadavek DMZ by měl dorazit k zamýšlenému listeneru. Navázaná relace může držet dřívější stav, takže nic nedokazuje o mapování, které jste změnili před minutou.

Uzavřete smyčku aktualizací inventáře záznamů tím, co jste nasadili, včetně každého listeneru, který jste objevili, ne vytvořili. Další člověk, který na této adrese publikuje službu, začne od vaší tabulky, a špatný řádek tam stojí víc než špatný příkaz tady.