Wszystko o NAT – mechanizmy translacji adresów sieciowych

Jeden adres – wiele problemów

Wszystko o NAT – mechanizmy translacji adresów sieciowych

Hierarchiczny NAT u operatora (CGN NAT) i użytkownika (CPE NAT)

Podstawowym problemem wykorzystania NAT jest konieczność identyfikacji użytkowników. Problem jest szczególnie istotny, gdy zachodzi potrzeba ustalenia, kto z zakresu prywatnej adresacji realizował połączenia z określonymi serwerami, w przypadku popełnienia przykładowo nadużycia czy przestępstwa. Zapytanie o informacje o konkretnym użytkowniku przeważnie jest dostarczane do operatora, który zarządza adresami publicznymi przydzielonymi użytkownikom. Operator wskazuje abonenta, którego zidentyfikował i wówczas na celowniku pozostaje ostatnie ogniwo, czyli nasza sieć, ukryta za maskaradą. Powstaje pytanie, czy jesteśmy w stanie wskazać, kto w danym czasie łączył się z określonymi zasobami w internecie?

Identyfikacja po adresie IP bez wdrożenia odpowiednich mechanizmów staje się trudna lub niemożliwa. To samo dotyczy NAT, który zostaje wdrożony na brzegu sieci firmowej. Jeżeli maskujemy użytkowników prywatnej sieci IPv4 jednym publicznym adresem IPv4, bez odpowiednich mechanizmów nie mamy możliwości wskazania odpowiedzialnego użytkownika czy komputera. W takich przypadkach konieczne okazuje się wdrożenie mechanizmu pozwalającego na realizowanie logowania połączeń wykonywanych przez wewnętrznych użytkowników. Część routerów będzie pozwalała na logowanie takich danych do serwera SYSLOG. Logowanie połączeń powinno następować przed potraktowaniem pakietów mechanizmem NAT. To, co jest interesujące z punktu widzenia ustalenia danych komputera, to adres IP źródłowy i docelowy, numer portu źródłowego i docelowego, ale także informacje o czasie nawiązania połączenia. Jeżeli wewnątrz sieci stosujemy serwer DHCP, koniecznością jest logowanie także powiązań MAC z IP w ramach wewnętrznego przydziału adresów IP.

Wszystko o NAT – mechanizmy translacji adresów sieciowych

Zastosowanie NAT 464 w procesie migracji do IPv6

Jeżeli mowa o nadużyciach, warto pamiętać o czarnych listach, na które czasami trafiają użytkownicy za niezgodne z regulaminami lub prawem działania. W przypadku, gdy dowolny z użytkowników za NAT zostanie sprawcą niezgodnego z regulaminem czy prawem zachowania, administrator docelowych serwerów może zablokować publiczne IP zewnętrznego interfejsu NAT. Skutkuje to zablokowaniem komunikacji dla wszystkich prywatnych adresów IP do danego serwera, maskowanych danym adresem IP. Uniknięcie tej sytuacji jest trudne i najczęściej mało skuteczne. Pewnym rozwiązaniem tego problemu może być zwiększenie liczby adresów publicznych, zapewniających maskaradę dla określonej grupy adresów prywatnych.

Logowanie adresacji wewnętrznej oraz mapowania portów pomoże nam jednak nie tylko w przypadku konieczności rozwiązania spraw naruszenia prawa. Przyda się także w analizowaniu i rozwiazywaniu problemów ze źródłami spamu czy atakami DoS (Denial of Service).

Problem z NAT44 może być jednak bardzo poważny przy niektórych aplikacjach. W teorii aplikacje powinny być niezależne od warstwy sieciowej, co spowodowałoby brak wpływu NAT na komunikację. W rzeczywistości tak nie jest i wiele aplikacji ma odniesienie do adresu IP (FTP, SIP, IPSec i inne). Rozwiązaniem dla aplikacji przechodzących przez NAT, pracujących w trybie punkt-punkt może być mechanizm NAT Traversal.


TOP 200