sysops.it

Outsourcing IT pozwoli ci prowadzić biznes taniej

info@sysops.it
+48 666 930 111

Nowości z bloga

TCP Fast Open

Opis modyfikacji stosu TCP, która może przyspieszyć prędkość ładowania popularnych stron od 4% do 41%.

Wyszukiwarki i Sphinx

Słowo wstępu o Sphinksie - silniku wspierającym wyszukiwanie pełnotekstowe.

Kwestia IPv6 NAT w Linuksie

IPv6 NAT w Linuksie - walka ideologii z rzeczywistością.

Kwestia IPv6 NAT w Linuksie

IPv6 NAT

Technologia NAT (Network Address Translation) w wielkim skrócie to modyfikacja informacji o adresie IP w ramach nagłówka pakietu IP podczas procesu routowania. Najprostszym rodzajem NAT jest translacja adresu IP jeden-do-jednego, określony w RFC 2663. W linuksie NAT realizowany jest poprzez mechanizmy wbudowane w kernel oraz userlandowe narzędzie iptables. NAT jest wykorzystywany przez administratorów do zadań typu np.:

  • zamiany adresów źródłowych (SNAT) oraz specjalny przypadek zwany maskarada (masquerade)
  • zamiany adresów docelowych (DNAT)
  • przekierowania portów (np. trasparent proxy)
  • mapowania całych bloków adresów IP (NETMAP)

Trzeba ponadto mieć świadomość, że istnieje wiele różnych rodzajów i określeń obecnych w świecie NATów (PAT, NAPT, jeden-do-jednego, jeden-do-wielu, itp.) w zależności od producenta, zastosowania, implementacji oraz nawet konkretnego urządzenia.

Historia

W latach 90-tych NAT stał się popularnym sposobem na radzenie sobie z konsekwencjami kończących się adresów IPv4. IP w wersji 4 przewiduje obecność 2^32 (4,294,967,296) adresów IP z czego, dodatkowo, duże bloki są zarezerwowane i niedostępne do publicznego użytku. Sieci korporacyjne oraz mniejsze sieci „ukrywały się” za adresami publicznymi przypisując hostom adresy z puli prywatnej (10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12). W ten sposób można zrealizować skalowanie wyczerpującego się zasobu jakim są adresy IPv4 – nie każdy host w sieci prywatnej potrzebuje publicznego adresu, większości wystarczy prywatny IP. Niezbędny do łączności ze światem adres publiczny, współdzielony jest z innymi hostami w sieci.

W międzyczasie, IANA (organizacja zajmująca się globalną alokacją adresów IP) oraz jej lokalne odpowiedniki zaczęły akcje informacyjne zachęcające do wdrożeń IPv6 jako protokołu następnej generacji.

Administratorzy przyzwyczajeni do wykorzystywania NAT w sieciach korporacyjnych napotkali na przeszkodę – w linuksie brak było wsparcia dla NAT w protokole IPv6. Konstruowanie sieci w sposób znany im dotychczas nie był możliwy. Powodów takiego stanu rzeczy było kilka. Deweloperzy odpowiedzialni za rozwój podsystemu netfilter w linuksie mieli ideologiczne przeciwwskazania do implementacji NAT w IPv6. Krytyka tej techniki wynika głównie ze złamania zasady punkt-punkt . Oportuniści wprowadzenia NAT do IPv6 wychodzili z założenia, ze adresów IPv6 jest tak dużo, że brak jest uzasadnienia wprowadzania techniki NAT, która jest swojego rodzaju kompromisem i wprowadza więcej złego niż dobrego.

Potwierdzeniem tego faktu jest post z marca 2005 Haralda Welte ówczesnego przewodniczącego podsystemu netfilter w linuksie, który pisze zdecydowanie:

> When is support NAT table for Ip6tables?

Only over my dead body. We will never implement ipv6-to-ipv6 network address translation as long as I have any say in netfilter/iptables development. NAT is evil and causes horrible breakage of end-to-end on the internet. IPv6 has enough addresses and therefore no justification for NAT.

Czas jednak płynął i ideologia sieciowo „czystego” internetu miała coraz większe problemy broniąc swoich racji. Coraz częściej pojawiały się głosy mówiące, że NAT dla IPv6 może jednak być przydatny. Pomijam głosy traktujące NAT jako element zwiększający bezpieczeństwo sieciowe – w założeniach to nigdy nie była technologia celująca w bezpieczeństwo, było to jedynie jej skutkiem ubocznym. Przykładowe argumenty „za” to:

  1. niezależność adresacji
    • adresy wykorzystywane wewnątrz sieci korporacyjnej oraz listy dostępu, tj. ACLki na poszczególnych węzłach sieci nie muszą być modyfikowane gdy ISP zmieni globalny prefix IPv6
    • zmiana samego ISP również nie pociąga za sobą readresacji węzłów oraz modyfikacji list ACL w ramach sieci
    • nie ma potrzeby przekonywać własnego ISP żeby przeroutował posiadane adresy PI (Provider Independent)
  2. ukrycie wewnętrznej topologii sieciowej
  3. elastyczność i dowolność podczas realizacji multihomingu , tj. wykorzystywania wielu ISP jednocześnie wedle zdefiniowanych kryteriów (np. ruch HTTP via ISP1, reszta via ISP2)

Z biegiem czasu potrzeba wykorzystania NAT w przypadku IPv6 się jeszcze zwiększała oraz doprowadziła do ciekawych wniosków:

  • potrzeba NAT IPv6 dla operatorów sieci korporacyjnych stała się faktem
  • dostawcy zaczęli implementować IPv6 NAT na własną rękę żeby zaspokoić potrzebę operatorów
  • IPv6 NAT powstaje i deweloperzy kernela oraz organizacje standaryzacyjne nie mogą temu zapobiec (przykładem jest Terry Moës i jego niezależna implementacja)

W lipcu 2011 gdy Harald Welte nie był już przewodniczącym netfiltera napisał żartobliwie:

I am quite at ease not participating in netfilter/iptables anymore while the discussion about IPv6 NAT becomes an issue again: I always indicated "over my dead body", and now that I am no longer in charge, nobody will have to kill me ;)

Ostatecznie (Patrick McHardy jako przewodniczący netfiltera), wraz z kernelem linuksa w wersji 3.7 dodana została funkcjonalność IPv6 NAT ucinając wszelkie ideologiczne spory o zasadność, potrzebę oraz konsekwencje takiego posunięcia. Nierówna walka ideologii z rzeczywistością została zakończona.

NAT IPv6
Dodano dn. 26 stycznia 2013 roku przez rob.