Dlaczego więcej organizacji nie korzysta z wewnętrznych NAT lub podobnych rozwiązań, aby umożliwić spinki do włosów NAT?

NAT od wewnątrz do wewnątrz, czyli sprzężenie zwrotne NAT, rozwiązuje problemy z NAT szpilki do włosów podczas uzyskiwania dostępu do serwera WWW na zewnętrznym interfejsie ASA lub podobnego urządzenia z komputerów na interfejsie wewnętrznym. Zapobiega to utrzymywaniu przez administratorów DNS zduplikowanej wewnętrznej strefy DNS, która ma odpowiednie adresy RFC1918 dla swoich serwerów, które są translowane NAT na adresy publiczne. Nie jestem inżynierem sieci, więc mogę coś przeoczyć, ale wydaje się, że konfiguracja i implementacja jest prosta. Asymetryczny routing może stanowić problem, ale można go łatwo złagodzić.

Z mojego doświadczenia wynika, że ​​administratorzy / inżynierowie sieci wolą, aby ludzie z systemu po prostu uruchamiali split-dns, zamiast konfigurować swoje zapory ogniowe, aby poprawnie obsługiwały spinki do włosów NAT. Dlaczego to?

Jest kilka powodów, dla których nie chciałbym tego zrobić:

• Po co zwiększać obciążenie routerów DMZ i zapory sieciowej, jeśli nie jest to konieczne? Większość naszych usług wewnętrznych nie znajduje się w strefie DMZ, ale w ogólnym obszarze korporacyjnym, a usługi pośrednictwa w strefie DMZ umożliwiają okazjonalny dostęp zdalny. Wykonanie nat od wewnątrz do wewnątrz zwiększa obciążenie strefy DMZ, co w naszym przypadku byłoby znaczące.
• Jeśli nie wykonasz DNAT + SNAT, dostaniesz routing asymetryczny, co jest bardzo trudne do prawidłowego wykonania. Więc SNAT i tracisz informacje o źródłowym IP. Jednak do celów rozwiązywania problemów przydatne jest łączenie źródłowych adresów IP z ludźmi. Lub czasami celowanie w celi w przypadku głupoty. „Hej, ten adres IP robi coś dziwnego w nieuwierzytelnionej usłudze X” „Och, spójrzmy na dzienniki serwera imap, kto to jest”.

Oczywiście nie ma na to jednoznacznej odpowiedzi , ale mogłem wymyślić kilka powodów:

1. Elegancja: NAT nie jest zbyt elegancki na początku, ale jest koniecznością z ograniczoną przestrzenią adresową IPv4. Jeśli mogę uniknąć NAT, zrobię to. W przypadku IPv6 problem w każdym razie zniknie.
2. Złożoność: szczególnie w przypadku, gdy nie masz tylko jednego „rdzenia” routera tworzącego wszystkie granice bezpieczeństwa, konfiguracje filtrów mogą być dość trudne. Albo to, albo będziesz musiał rozpowszechniać i utrzymywać reguły NAT na prawie wszystkich routerach.
3. Odwołanie: wszędzie tam, gdzie administratorzy zapory ogniowej są inni niż reszta zespołu administratorów serwera, dostęp do nich może być trudny. Aby mieć pewność, że zmiany nie zostaną opóźnione przez zaległości administratora zapory (lub wakacje), wybrana jest opcja utrzymania odpowiedzialności w tym samym zespole
4. Przenośność i powszechna praktyka: korzystanie z widoków DNS to „po prostu to, co wszyscy wiedzą, że jest zrobione”, aby rozwiązać ten problem. Nie każdy router brzegowy w prosty sposób obsługiwałby NAT pętli zwrotnej, mniej osób prawdopodobnie będzie wiedziało, jak poprawnie skonfigurować go w określonym środowisku. Podczas rozwiązywania problemów z siecią załoga musi być świadoma konfiguracji NAT spinki do włosów i wszystkich jej implikacji - nawet jeśli ścigają pozornie niezwiązany problem

Zastrzeżenie - jest to odpowiedź na przynętę płomieniową.

Częstym powodem, dla którego uważam, że takich rozwiązań jest unikany, jest irracjonalny strach / nienawiść do NAT ze strony inżynierów sieciowych . Jeśli chcesz zobaczyć przykłady dyskusji na ten temat, sprawdź te:

• http://packetpushers.net/show-86-connect-to-the-ipv6-internet-for-free-using-tunnelbroker-net/
• http://networkingnerd.net/2012/04/02/ipv6-nat-and-the-sme-a-response/ (blog Toma wciąż przyciąga raczej gorącą dyskusję o NAT / IPv6)
• http://libertysys.com.au/blog/nat-is-evil-but-not-bad (mój blog)

Z tego, co mogę powiedzieć, duża część tego strachu wynika z kiepskiej implementacji NAT przez Cisco (więc w tym sensie może to nie być irracjonalne), ale moim zdaniem „klasyczny” inżynier sieci jest tak dobrze wyszkolony w „NAT jest zły światopogląd, że nie widzi oczywistych przykładów takich jak ten, w których ma to sens i faktycznie upraszcza rozwiązanie.

Proszę bardzo - oddaj głos na treść swojego serca! :-)

Moim gościem jest:

1. Podział DNS jest łatwiejszy do zrozumienia.
2. NAT Hairpin zużywa zasoby na routerze, podczas gdy split-dns nie.
3. Routery mogą mieć ograniczenia przepustowości, których nie można uzyskać przez konfigurację split-dns.
4. Split-dns zawsze będzie lepiej działać, ponieważ unikasz routingu / kroków NAT.

Na plus od szpilki do włosów NAT,

• Po skonfigurowaniu to po prostu działa.
• Brak problemów z buforami DNS dla laptopów przenoszonych między siecią służbową a publicznym Internetem.
• DNS dla serwera jest zarządzany tylko w jednym miejscu.

W przypadku małej sieci o niskim wymaganiu ruchu do serwera wewnętrznego wybrałbym spinkę NAT. W przypadku większej sieci z wieloma połączeniami z serwerem, gdzie ważna jest przepustowość i opóźnienia, skorzystaj z split-dns.

Z mojego punktu widzenia zmieniło się to nieco między przejściem z Cisco Pix na ASA. Zgubiłem aliaspolecenie. I ogólnie dostęp do adresu zewnętrznego z interfejsu wewnętrznego zapory Cisco wymaga pewnego rodzaju oszustwa. Zobacz: Jak mogę uzyskać dostęp do mojego wewnętrznego serwera na zewnętrznym adresie IP?

Jednak nie zawsze musimy utrzymywać zduplikowaną wewnętrzną strefę DNS. Cisco ASA może przekierowywać zapytania DNS dotyczące adresów zewnętrznych na adresy wewnętrzne, jeśli skonfigurowano je w instrukcji NAT. Ale wolę zachować wewnętrzną strefę dla publicznej strefy DNS, aby mieć tę szczegółowość i móc zarządzać nią w jednym miejscu, a nie przejść do zapory.

Zazwyczaj jest tylko kilka serwerów, które mogą wymagać tego w środowisku (poczta, sieć, kilka usług publicznych), więc nie był to ogromny problem.

Mogę wymyślić kilka powodów:

1. Wiele organizacji podzieliło DNS już w wyniku tego, że nie chcą publikować wszystkich swoich wewnętrznych informacji DNS na świecie, więc nie jest to dodatkowy wysiłek, aby obsłużyć kilka serwerów, które są również ujawniane za pośrednictwem publicznego adresu IP.
2. Gdy organizacja i jej sieć stają się coraz większe, często oddzielają systemy obsługujące pracowników wewnętrznych od serwerów obsługujących urządzenia zewnętrzne, więc routing do zewnętrznych w celu użycia wewnętrznego może być znacznie dłuższą ścieżką sieciową.
3. Im mniej modyfikacji wprowadzają pakiety pośredniczące, tym lepiej, jeśli chodzi o opóźnienia, czas reakcji, obciążenie urządzenia i rozwiązywanie problemów.
4. (bardzo niewielkie, co prawda) Istnieją protokoły, że NAT nadal będzie działać, jeśli urządzenie NATing nie wykracza poza nagłówki pakietu i nie modyfikuje w nim danych za pomocą nowych adresów IP. Nawet jeśli jest to tylko przypadek pamięci instytucjonalnej, jest to nadal ważny powód, dla którego ludzie powinni go unikać, zwłaszcza jeśli mają do czynienia z protokołem, którego nie są w 100% pewni.

Gdybym miał użyć pętli zwrotnej NAT, byłbym trochę zaniepokojony tym, jak urządzenie NAT będzie obsługiwać sfałszowane adresy źródłowe. Jeśli nie sprawdzi, który interfejs przyszedł pakiet, mógłbym sfałszować adresy wewnętrzne z sieci WAN i wysłać pakiety na serwer z adresami wewnętrznymi. Nie mogłem uzyskać odpowiedzi, ale być może uda mi się narazić serwer na atak przy użyciu adresu wewnętrznego.

Skonfigurowałem sprzężenie zwrotne NAT, podłączono do przełącznika DMZ i wysyłałem pakiety z sfałszowanymi wewnętrznymi adresami źródłowymi. Sprawdź dziennik serwera, aby zobaczyć, czy zostały odebrane. Potem poszedłem do kawiarni i sprawdziłem, czy mój dostawca usług internetowych blokuje sfałszowane adresy. Jeśli stwierdzę, że mój router NAT nie sprawdza interfejsu źródłowego, prawdopodobnie nie użyłbym pętli zwrotnej NAT, nawet jeśli mój dostawca usług internetowych sprawdza.