ASA: port VPN i statyczny PAT DMZ na jednym publicznym IP

Dwie usługi, jeden publiczny adres i nazwa DNS, która wydaje się rezerwować port. Nie rezerwuje. Zanim opublikujesz serwer DMZ obok wpisu VPN na ASA, zapisz krotki wpisów i sprawdź je po kolei; pierwsze pole zgodne z istniejącą usługą to miejsce, w którym plan się zatrzymuje. Wszystko poniżej zakłada, że VPN kończy się na samym urządzeniu, a nie na serwerze wewnętrznym.

Zapisz pięć pól, zanim napiszesz polecenie

Dla każdego publicznego wpisu zapisz rodzinę adresów, adres publiczny, transport, port publiczny i właściciela. Właścicielem jest usługa lokalna ASA albo przetłumaczony serwer wewnętrzny. Dwa wpisy mogą dzielić adres i nadal być różnymi krotkami, a dwa wpisy mogą wyglądać inaczej na schemacie, jednocześnie kolidując na urządzeniu.

Trzymaj drugą kolumnę dla rzeczywistego portu, tego, na którym serwer wewnętrzny faktycznie nasłuchuje. Port publiczny i port rzeczywisty to niezależne wybory, a w momencie, gdy łączysz je w jedną kolumnę, tracisz możliwość późniejszego odczytania własnego tłumaczenia.

Czytaj poprawnie pozycje rzeczywiste i mapowane

Zacznij od krotki, którą już masz, a nie od serwera, który chcesz dodać. Przykładowy podział zostawia zatwierdzony wpis VPN na publicznym TCP 443 i publikuje serwer DMZ HTTPS na publicznym TCP 8443, podczas gdy ten serwer nadal nasłuchuje na 443:

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

W wdrożonym poleceniu usługa rzeczywista i usługa mapowana stoją na stałych pozycjach, a zamiana ich miejsc opisuje inne mapowanie, nie zepsute. To najczęstszy sposób, w jaki działające tłumaczenie staje się zagadką: konfiguracja jest poprawna, po prostu wskazuje gdzie indziej.

Przewodnik NAT ASA 9.16 firmy Cisco opisuje statyczny PAT, użycie adresu interfejsu oraz znaczenie portu rzeczywistego i mapowanego. Przeczytaj sekcję dla wersji, którą naprawdę uruchamiasz; polecenie zapamiętane ze starszej platformy nie jest pełną bieżącą konfiguracją.

Licz transport jako część rezerwacji

TCP 443 i UDP 443 to różne krotki, a ta różnica nie daje ci UDP za darmo. VPN może mieć osobne listenery TLS i DTLS, a inne skonfigurowane usługi mogą już zajmować transport, którego chcesz. Zinwentaryzuj efektywne listenery i politykę dostępu, zamiast zakładać, że strona internetowa to cały wpis VPN.

Druga nazwa hosta rozwiązująca się na ten sam adres też nie rozwiązuje kolizji na poziomie transportu. DNS to mapowanie nazwy na adres, a nie broker portów, a publikowanie serwera przez PAT to nie ta sama operacja co przeniesienie listenera VPN na inny port.

Jeśli wpis VPN naprawdę musi się przenieść, cztery rzeczy zmieniają się razem: profil klienta, publiczny URL, filtrowanie po stronie nadrzędnej i każdy transport, którego używa wdrożenie. Zrób je w jednym oknie, a nie po kolei. Przed dotknięciem usługi, której używasz do dotarcia do urządzenia, utrzymuj otwartą osobną ścieżkę zarządzania. Bez drugiej ścieżki przeniesienie jest zmianą, z której nie możesz się wycofać z zewnątrz.

Weryfikuj z zewnątrz świeżymi połączeniami

Zezwól tylko zamierzonej aplikacji DMZ w ramach efektywnej polityki dostępu, a następnie sprawdź pasujący porządek tłumaczenia, ścieżkę powrotną serwera i nazwę hosta w certyfikacie. PAT zmienia cel sieciowy; nie przyznaje dostępu do aplikacji i nie naprawia certyfikatu, który nazywa inny host.

Przetestuj obie usługi nowymi połączeniami z upoważnionego hosta zewnętrznego: VPN powinien nadal się zestawiać, a żądanie DMZ powinno dotrzeć do zamierzonego listenera. Ustanowiona sesja może zachować wcześniejszy stan, więc nic nie dowodzi o mapowaniu zmienionym minutę temu.

Zamknij pętlę, aktualizując inwentarz wpisów tym, co wdrożyłeś, w tym każdym listenerem, który odkryłeś, a nie utworzyłeś. Następna osoba, która opublikuje usługę na tym adresie, zacznie od twojej tabeli, a błędny wiersz tam kosztuje więcej niż błędne polecenie tutaj.