4. NAT i proxy

Poza otoczeniem firmowym, jedną z największych zalet technologii ścian ogniowych jest możliwość połączenia wielu komputerów przez jeden interfejs zewnętrzny, często bez zgody, wiedzy czy nawet podejrzeń ze strony dostawcy internetowego. Ci którzy znają Linuksa nazywają to Maskaradą IP ( ang. IP Masquerading ), ale dla reszty świata jest ona znana pod nazwą Translacja Adresów Sieciowych, lub w skrócie NAT ( ang. Network Address Translation ).

4.1 Mapowanie wielu adresów w jeden

Najprostszym zastosowaniem NAT jest dokładnie to co robi jego odpowiednik - Linuksowa Maskarada IP. Zapisuje się to w jednej prostej regule:

map tun0 192.168.1.0/24 -> 20.20.20.1/32

Bardzo proste. Zawsze gdy pakiet wychodzi przez interfejs tun0 ze źródłowym adresem pasującym do maski CDIR 192.168.1.0/24, adres jest zamieniany jeszcze na stosie IP, tak by zawierał adres źródłowy 20.20.20.1 a dopiero wtedy zostaje wysłany do swojego celu przeznaczenia. System utrzymuje listę jakie zmapowane połączenia są w trakcie tak by mógł wykonać czynność odwrotną gdy nadejdzie odpowiedź ( skierowana do 20.20.20.1 ) i odesłać ją do oryginalnego nadawcy.

Jest jednak pewien minus reguły którą teraz wpisaliśmy. W wielu przypadkach, nie wiemy jaki mamy adres IP naszego zewnętrznego interfejsu ( jeśli używasz tun0 czy ppp0 i typowego ISP ), więc ustawienie tablicy NAT staje się raczej problematyczne. Na szczęście NAT jest na tyle mądry, że potrafi zaakceptować adres w postaci 0/32. Sygnalizuje to, że musi sprawdzić sobie sam jaki właściwie adres ma interfejs zewnętrzny i prawidłowo zmodyfikować pakiet. Spójrz niżej:

map tun0 192.168.1.0/24 -> 0/32

Możemy teraz załadować nasze reguły do ipnat i połączyć się ze światem zewnętrznym bez konieczności edytowania czegokolwiek. Musisz jednak uruchomić `ipf -y' by odświeżyć adres przypisany połaczeniu jeśli się rozłączysz i wdzwonisz ponownie, lub gdy wygaśnie Twoja dzierżawa na adres przydzielony przez DHCP.

Niektórzy z was mogą się zastanawiać, co dzieje się z portem źródłowym gdy wykonywane jest mapowanie. W przypadku naszej reguły, port źródłowy pakietu nie zostaje zmieniony w stosunku do oryginału. Są jednak przypadki gdy nie chcemy by tak się działo - może po drodze jest jeszcze jedna ściana ogniowa, lub wiele maszyn próbuje używać tego samego portu. Może to powodować kolizje i pakiet jest przepuszczany bez mapowania. ipnat pomaga w tym momencie, poprzez dostarczenie słowa kluczowego `portmap':

map tun0 192.168.1.0/24 -> 0/32 portmap tcp/udp 20000:30000

Nasza reguła wrzuca wszystkie mapowane połączenia ( które mogą używać protokołu tcp, udp lub jednocześnie tcp/udp ) w zakres portów od numeru 20000 do 30000.

Możemy jeszcze ułatwić sobie życie, używając polecenia `auto' by poinformować ipnat by sam określił sobie jakich portów może użyć i zaalokował je proporcjonalnie wśród adresów, używanych w puli:

map tun0 192.168.1.0/24 -> 0/32 portmap tcp/udp auto

Pamiętaj, że reguły mapujące odnoszą się tylko do protokołów, które określiłeś ( np. tcp, udp lub tcp/udp ), i nie odnoszą się do innych, takich jak ICMP czy IPsec ESP/AH. Dla nich, musisz dodać dodatkowe mapowania odnoszące się do wszystkich innych protokołów:

map tun0 192.168.1.0/24 -> 0/32 portmap tcp/udp 20000:30000
map tun0 192.168.1.0/24 -> 0/32

4.2 Mapowanie wielu adresów w przydzieloną pulę adresów

Innym częstym zastosowaniem NAT jest wzięcie małej, statycznie przydzielonej puli adresów i zmapowanie wielu komputerów w tą mniejszą przestrzeń adresową. Jest to proste do uzyskania przy użyciu tego co już wiesz o słowach kluczowych `map' i `portmap'. Zapiszmy to jak poniżej:

map tun0 192.168.0.0/16 -> 20.20.20.0/24 portmap tcp/udp 20000:60000

Zdarza się również, że zdalna aplikacja wymaga, by wszystkie połączenia przychodziły z tego samego IP. Możemy pomóc, instruując NAT by statycznie zmapował sesje z danej maszyny na pulę adresów i wykonał trochę magii z wybraniem portu. Robi się to, stosując słowo kluczowe `map-block', tak jak poniżej:

map-block tun0 192.168.1.0/24 -> 20.20.20.0/24

Tak jak słowo `map', `map-block' ma również swoją wersję `portmap'. Używa się jej albo ze słowem kluczowym `auto':

map-block tun0 192.168.1.0/24 -> 20.20.20.0/24 auto

lub ze słowem `ports', jeśli chcesz wskazać konkretne numery portów należące do określonych adresów IP:

map-block tun0 192.168.1.0/24 -> 20.20.20.0/24 ports 64

4.3 Mapowania jeden do jednego

Czasami zdarza się, że chcemy by komputer za ścianą ogniową z danym IP pojawiał się z innym IP. Jednym z takich przykładów może być labolatorium komputerowe, dołączone do różnych sieci, a mające wziąć udział w testach. Nie chcemy rekonfigurować całego labolatorium, ponieważ możemy postawić przed nim komputer wykonujący NAT i zmienić adresy w jednym miejscu. Można to wykonać za pomocą słowa kluczowego `bimap', od mapowania dwukierunkowego. Bimap posiada pewne dodatkowe zabezpieczenia zapewniające, że wie jaki jest stan połączenia, podczas gdy słowo `map' używane jest tylko do zaalokowania adresu i portu źródłowego oraz odpowiedniej modyfikacji pakietu.

bimap tun0 192.168.1.1/32 -> 20.20.20.1/32

spowoduje zmapowanie dla jednej maszyny.

4.4 NAT według Zasad

Często zdarza się, że musimy zapewnić funkcjonowanie NATu zależne od adresów źródłowych i przeznaczenia. Na przykład, chcemy prowadzić NAT dla wszystkich, oprócz określonej podsieci:

map tun0 from 192.168.1.0/24 ! to 5.0.0.0/20 -> 20.20.20.1/32

Można również zastosować taką konstrukcję:

map tun0 from 192.168.1.5/32 port = 5555 to 1.2.3.4/32 -> 20.20.20.2/32
map tun0 from 192.168.1.0/24 to 5.0.0.0/20 -> 20.20.20.2/32 portmap auto

4.5 Usługi fałszujące

A co to ma do rzeczy? Wiele. Powiedzmy że mamy serwer WWW pracujący na 20.20.20.5, a ponieważ staliśmy się ostatnio bardzo podejrzliwi co do bezpieczeństwa naszej sieci, chcemy by serwer nie pracował na porcie 80, ponieważ wymaga to krótkiego momentu pracy z przywilejami roota. Ale jak uruchomić go na mniej uprzywilejowanym porcie 8000 w świecie 'wszystko kropka com'? Jak ktokolwiek znajdzie nasz serwer? Możemy użyć usług przekierowania NATu by rozwiązać ten problem, instruując go by przemapował wszystkie połączenia przeznaczone dla 20.20.20.5:80 na 20.20.20.5:8000. Używa się do tego słowa kluczowego `rdr':

rdr tun0 20.20.20.5/32 port 80 -> 192.168.0.5 port 8000

Możemy również podać protokół, jeśli chcielibyśmy na przykład przekierować usługę UDP zamiast TCP ( która jest domyślna ). Na przykład, gdybyśmy chcieli zastawić zasadzkę na naszej ścianie ogniowej i udawać zainstalowanego Back Orifice dla Windows, możemy ochronić naszą sieć przez prostą regułę:

rdr tun0 20.20.20.0/24 port 31337 -> 127.0.0.1 port 31337 udp

Możliwe jest modyfikowanie zachowania słowa `rdr' w zależności od adresów źródłowego i docelowego:

rdr tun0 from 10.1.1.1/32 to 20.20.20.5/32 port = 80 -> 192.168.0.5 port 8001
rdr tun0 from 10.1.1.1/32 port = 12345 to 20.20.20.5/32 port = 80 -> 192.168.0.5 port 8002

Należy jednak zaznaczyć bardzo ważną sprawę. Nie możesz łatwo użyć tego jako lustra, tzn.:

rdr tun0 20.20.20.5/32 port 80 -> 20.20.20.6 port 80 tcp

Taka konstrukcja nie zadziała, jeśli .5 i .6 są w tym samym segmencie LAN. Funkcja `rdr' jest wykonywana na każdym pakiecie, który trafia do ściany ogniowej na określonym interfejsie. Gdy nadchodzi pakiet który pasuje do reguły, jego adres docelowy jest zmieniany, pakiet trafia do ipf w celu przefiltrowania i gdy tylko przetrwa boje z regułami filtra, jest wysyłany do kodu routującego Uniksa. Ponieważ pakiet pochodzi z tego samego interfejsu, którym będzie musiał opuścić system by dotrzeć do maszyny docelowej, system jest w kropce. Lustra po prostu nie działają. Nie działa również podawanie adresu interfejsu z którego pakiet właśnie nadszedł. Pamiętaj że adresy docelowe dla `rdr' muszą istnieć po drugiej stronie ściany ogniowej, w sieci do której prowadzi inny interfejs niż ten, którym wszedł pakiet pierwotny.

4.6 Transparentne proxy; W końcu przekierowanie do czegoś się przydaje.

Ponieważ właśnie instalujesz ścianę ogniową możesz zdecydować, że jest to dobry moment na zastosowanie proxy dla wielu wychodzących połączeń. Dzięki temu możesz jeszcze bardziej zacieśnić swoje reguły filtrowania chroniące sieć. Może się również zdarzyć tak, że natrafisz na sytuację, której proces mapowania NAT nie może aktualnie poprawnie obsłużyć. Taką sytuację można obejść następującą konstrukcją:

rdr xl0 0.0.0.0/0 port 21 -> 127.0.0.1 port 21

Ten wpis mówi, że każdy pakiet z interfejsu xl0 przeznaczony dla dowolnego adresu ( 0.0.0.0 ) na port ftp, zostanie przepisany tak by połączyć się z proxy, które pracuje na systemie wykonującym NAT na porcie 21.

Ten specyficzny przykład proxy FTP prowadzi do pewnych komplikacji, kiedy chodzi o serwery WWW czy inne automatycznie logujące się klienty, które nie wiedzą o wymaganiach komunikacji z proxy. Istnieją łaty dla ftp-gw z TIS Firewall Toolkit które w połączeniu z procesem NAT pozwalają na zapewnienie funkcjonalności, dzięki której można sprawdzić gdzie chciałeś wejść i wysłać cię tam automatycznie. Wiele paczek proxy pracuje obecnie również w środowisku transparentnego proxy ( na przykład Squid, znajdujący się pod adresem http://squid.nlanr.net, pracuje w porządku ).

Takie zastosowanie słowa kluczowego `rdr' jest często użyteczne gdy chcesz zmusić użytkowników do autoryzowania się na proxy ( na przykład, gdy chcesz by twoi inżynierowie mogli przeglądać strony WWW, ale wolałbyś żeby raczej ludzie z call-center tego nie robili ).

4.7 Filtrowanie przekierowanych usług

Wielu użytkowników chce połączyć filtrowanie i translację adresów, by zapewnić usługi tylko określonym komputerom za ich ścianą ogniową. Na przykład, by zapewnić dostęp do serwera WWW za twoją maszyną 20.20.20.5 ( która tak naprawdę ma adres 192.168.0.5 w sieci wewnętrznej ) Twojemu przyjacielowi który ma adres 172.16.8.2, możesz wpisać następujący wiersz do ipnat.rules:

rdr tun0 20.20.20.5/32 port 80 -> 192.168.0.5 port 8000

a następujący wiersz do ipf.rules:

pass in on tun0 proto tcp from 172.16.8.2/32 to 192.168.0.5/32 port = 8000 flags S keep state

Na pierwszy rzut oka może to wyglądać trochę dziwnie, ale dlatego że NAT odbywa się pierwszy, a w jego trakcie adres docelowy i port docelowy jest przepisywany zanim zajmie się nim kod filtrujący pakietu.

4.8 Magia ukryta w NAT; proxy aplikacji

Ponieważ ipnat dostarcza metody na przepisywanie pakietów w trakcie ich podróży przez ścianę ogniową, staje się wygodnym miejscem do wbudowania proxy poziomu aplikacji, zbudowanej pomiędzy tą aplikacją a ścianą ogniową. Na przykład: FTP. Możemy kazać naszej ścianie ogniowej sprawdzać pakiety, które przez nią przechodzą i gdy zauważy, że ma do czynienia z aktywną sesją FTP, dopisze sobie pewne tymczasowe reguły. Dzieje się to trochę na wzór keep state i sprawia, że połączenie FTP będzie działało. Realizujemy to reguła podobną do tej:

map tun0 192.168.1.0/24 -> 20.20.20.1/32 proxy port ftp ftp/tcp

Musisz pamiętać by umieścić wyrażenie `proxy' przed jakimikolwiek regułami `portmap', ponieważ w innym przypadku `portmap' wykona przepisanie pakietu zanim `proxy' będzie miało szansę na zajęcie się nim. Pamiętaj, że reguły ipnat działają na zasadzie pierwszy pasujący. Istnieją również proxy dla rcmd ( które, jak sądzimy, są berkeley'owskimi komendami r-*, i i tak powinny być zabronione, więc nie przyglądaliśmy im się ), oraz raudio dla strumieni Real Audio PNM. W każdym bądź razie obydwa proxy powinny zostać ustawione przed jakimikolwiek regułami `portmap', jeśli zamierzasz robić NAT.

4.9 Jeszcze więcej magii; NAT jako równoważenie obciążenia

Jeśli ipnat i tak już przepisuje nam pakiety, możemy użyć go do obsługi prostszych właściwości drogich urządzeń równoważących obciążenie. Będzie przypisywał mapowaniom wiele adresów docelowych - uzyskamy to stosując słowo kluczowe `round-robin':

rdr tun0 20.20.20.5/32 port 80 -> 192.168.0.5, 192.168.0.6, 192.168.0.7 port 8000