Routing i NAT

Wprowadzenie teoretyczne do lekcji nr 6

Dokument ten jest poświęcony instalacji usługi routingu i aktywacji NAT-u na naszym serwerze. Słowo "instalacja" to jednak lekkie wyolbrzymienie gdyż nic instalować nie będziemy (prócz jednego dodatku), a skorzystamy z funkcji wbudowanych w system. Zanim sobie rozpoczniemy uruchamianie routingu, chciałbym krótko wytłumaczyć czym on jest i co to jest NAT.
Routing to wyznaczanie trasy i wysyłanie nią pakietu danych w sieci komputerowej. W obrębie jednej sieci nie ma potrzeby na routing, gdyż komputery posiadają taką samą adresację i są w stanie skomunikować się ze sobą bezpośrednio (pomijając switcha, to inna bajka). Routing potrzebny jest już w przypadku różnych sieci, gdyż komputer z sieci 10.0.0.0/25 nie wie gdzie jest sieć 192.168.1.0/24. Jeżeli PC-ty są bezpośrednio spięte ze sobą to się widzą i wiedzą "gdzie są". Jeżeli używany jest switch lub hub to wtedy te urządzenia dbają o to aby skomunikować ze sobą komputery. Ale switch operuje na adresach MAC i pozwala na przesyłanie tylko w obrębie jednej sieci. Hub jest jeszcze mniej inteligentny i dubluje wszystkie pakiety. Oczywiście można by było wszystkie komputery na świecie zamknąć pod jedną adresacją i korzystać z samych switchy, ale… zabrakłoby adresów IP. No i każdy switch musiałby posiadać w swojej tablicy mac adresów, wszystkie komputery na świecie. Oczywiście byłoby to mało wydajne. Dlatego też powstał routing. Router nie wie jak dojść do danej sieci, ale wie, że może to wiedzieć router z którym jest spięty. I tak dalej i tak dalej. Routery są również wyposażone w bardzo ważną funkcję…
Network Address Translation – NAT, inaczej translacja adresów sieciowych. Jest to technika przesyłania ruchu sieciowego, która polega na zamianie źródłowych lub docelowych adresów IP. Oryginalnie używano tej techniki do omijania konieczności przypisywania nowych adresów IP każdemu hostowi kiedy sieć jest przeniesiona itd. Obecnie najpopularniejszą odmianą NAT-u jest One-to-Many albo też inaczej Maskarada IP. Jedną z definicji, którą podaje słownik PWN na temat maskarady jest "pozorowanie, udawanie czegoś". Maskarada IP oszukuje Internet, że łączymy się z jednego adresu IP, ukrywając przy tym adresację prywatną. Otóż w celu zaoszczędzenia adresów IP wydzielono pulę adresów prywatnych, które za żadne skarby nie mogą być używane w publicznym Internecie. Są one przeznaczone do użytku w obrębie jeden sieci LAN, a to oznacza, że wiele sieci może korzystać z tej samej adresacji. Dostęp do Internetu odbywa się właśnie dzięki maskaradzie IP. Nasz router otrzymuje publiczny adres IP od operatora. I w przypadku kiedy jakiś host z naszej sieci próbuje wysłać pakiet do Internetu, to router zamienia w tym pakiecie adres IP źródłowy z prywatnego np. 192.168.10.11 na publiczny np. 241.54.63.32. W momencie kiedy serwer otrzymuje ten pakiet to odpowiedź odsyła na adres publiczny. Router wie do którego hosta jest kierowana odpowiedź (np. na postawie portu) i zamienia IP docelowy z publicznego na prywatny konkretnego hosta. Warto również wiedzieć, że maskaradę najlepiej stosować gdy adres publiczny jest dynamicznie zmieniany przez operatora. W przypadku kiedy adres jest statyczny to najlepiej zastosować inną odmianę NAT-u – SNAT. Jednak można i zastosować maskaradę. Wręcz nawet częściej się z niej korzysta niż z SNAT-u. Znając już te podstawy możemy przejść do aktywacji usługi NAT-u. Na początku warto przypomnieć sobie informacje jakie będą nam potrzebne do tego: nazwa interfejsu sieciowego WAN, czyli tego podłączonego do Internetu. Zalecam dodatkowo zrobić aktualizację repozytoriów i pakietów (sudo apt update i sudo apt upgrade). Kiedy już mamy to wszystko zrobione, możemy przejść do clou tego dokumentu.

I. Uruchamianie usługi routingu i NAT-u.

ZANIM ROZPOCZNIESZ, ważne jest aby najpierw uruchomić serwer DHCP, a potem usługę Routingu. Oszczędzi to potem wielu problemów. Pierwszą istotną rzeczą jaką zrobimy to powiemy naszemu Linuxowi aby uruchomił przekierowywanie pakietów dla IPv4. Domyślnie system odrzuca wszelkie pakiety nieskierowane do niego. Tego oczywiście nie chcemy, gdyż spowoduje to blokadę ruchu między naszą siecią WAN i LAN. Pakietów nieskierowanych do systemu będzie bardzo dużo. Właściwie każde zapytanie klienta do Internetu jest pakietem nieskierowanym do serwera. Dlatego też musimy powiedzieć serwerowi, żeby takich pakietów nie odrzucał.

Zrobimy to za pomocą pliku /etc/sysctl.conf. Musimy go edytować z prawami administratora. Tak więc wpisujemy:
$ sudo nano /etc/sysctl.conf
Następnie odnajdujemy linijkę "#net.ipv4.ip_forward=1" i usuwamy znak "#" na początku aby odkomentować to polecenie. Zapisujemy plik i wychodzimy z edytora nano.

Teraz aby nasze zmiany odniosły skutek musimy je zatwierdzić odpowiednim poleceniem:
$ sudo sysctl -p
Po wprowadzeniu tej komendy, system zatwierdzi nasze zmiany i wyświetli w konsoli funkcje, które zostały aktywowane. Powinno być tutaj widać linijkę, z której "zdjęliśmy" komentarz.

Nadszedł czas na najważniejszy moment, czyli za pomocą programu iptables dodamy sobie regułę do kernelowego firewalla, która uaktywni nam maskaradę IP na interfejsie WAN serwera. Najpierw podam całą komendę, a potem wyjaśnię jej składniki:
$ sudo iptables -t nat -A POSTROUTING -o enp0s3 -j MASQUERADE
Pierwszy parametr, czyli -t nat określa w jakiej tabeli ma się znaleźć nasz wpis. Ponieważ za pomocą iptables możemy przekierowywać porty czy blokować połączenia to istnieją różne tablice, które mają inne właściwości. Np. do filtrowania pakietów użyjemy filter. My potrzebujemy usług NAT-u, więc korzystamy z dedykowanej do tego tablicy nat, która jest wywoływana kiedy serwer napotka nowe połączenie. Następnie mamy -A POSTROUTING, jest to opcja, która mówi firewallowi, że ta reguła którą dodajemy, ma zostać jedynie zastosowana do pakietów, które mają opuścić serwer (nie ma znaczenia czy do LAN-u czy do WAN-u). Wpis -o enp0s3 mówi, że reguła ta ma zadziałać tylko na pakietach, które mają zostać wysłane za pomocą danego interfejsu. W tym przypadku podajemy interfejs WAN, gdyż to on pośredniczy między Internetem, a interfejsem LAN serwera (a także klientami). Nie muszę chyba mówić, że nazwa interfejsu może się różnić od tej co ja podaję i należy ją sprawdzić samemu. Ostatnia reguła -j MASQUERADE, mówi, że jeżeli pakiet spełni wszystkie podane warunki, czyli przechodzi przez serwer, ma właśnie wyjść z serwera, wyjdzie przez interfejs enp0s3, to ma zostać na nim zastosowane odpowiednie działanie i w tym przypadku jest to maskarada.
Warto również wiedzieć, że reguły iptables działają na zasadzie łańcucha. Są takimi "ifami" w programowaniu. Firewall sprawdza po kolei każdy wpis i za każdym razem kiedy pakiet spełnia warunki tego wpisu to ten dokonuje na nim jakieś akcji. Może być to odrzucenie pakietu, może być zaakceptowanie, może być maskarada, może być ogólnie wszystko na co pozwala program. Po więcej informacji o iptables odsyłam do Internetu.

W tym momencie po wpisaniu poniższego polecenia, na naszym kliencie powinno pojawić się połączenie z Internetem:
$ sudo iptables -t nat -A POSTROUTING -o enp0s3 -j MASQUERADE
Iptables ma taką samą przypadłość jak polecenie ip. Otóż zmiany nie są wprowadzane na stałe. Oczywiście z punktu widzenia bezpieczeństwa, jest to zaleta. Gdyby coś poszło nie tak, to zawsze można zrestartować serwer i zmiany się odwrócą. My jednak potrzebujemy tego na stałe. Z pomocą przychodzi mały programik, który nazywa się iptables-persistent i dba on o to, aby reguły, które wprowadzimy zawsze po restarcie serwera były aplikowane do systemu.

Zainstalować program iptables-persistent można poleceniem:
$ sudo apt install iptables-persistent
UWAGA! Warto mieć na uwadze, że program już podczas instalacji będzie chciał zapisać wprowadzone przez nas reguły. Dlatego najpierw przed instalacją warto te reguły dodać. Dokładnie program zapyta się czy chcemy zapisać reguły dla IPv4 i IPv6. Najlepiej zgodzić się na obie propozycję. Po skończonej instalacji, można już korzystać z Internetu na stacjach klienckich.

Gdybyśmy dodali więcej reguł i chcieli je zapisać to możemy zrobić to ponownie poleceniem:
$ sudo iptables-save
Spowoduje ono prócz zapisania reguł, wyświetlenie ich wszystkich na ekranie.

II. Testowanie połączenia na stacji klienckiej.

Ostatnią rzeczą będzie sprawdzenie poprawności działania usługi routingu i NAT-u na stacji klienckiej. W tym celu po prostu pingujemy coś w internecie.

Pingi

Spróbujemy zatem puścić ping na stronę google.pl oraz serwer DNS Google 8.8.8.8. Wpisujemy zatem:
$ ping google.pl
a następnie:
$ ping 8.8.8.8
Jak widać w pierwszym przypadku polecenie ping mówi nam, że nie można odwzorować nazwy. Tym błędem się nie przejmujemy – sprawa jest prosta. Przy konfiguracji DHCP podaliśmy adres DNS jako adres serwera, tyle że… na serwerze nie ma jeszcze serwera DNS-owego. Dlatego najlepiej spingować samo IP np. 8.8.8.8. Tutaj jak widać połączenie jest, czyli wszystko działa. Gdyby nie działało to warto sprawdzić czy na serwerze lecą pingi. Jeżeli tak to należy dokładnie sprawdzić konfigurację serwera. Odpowiednie pliki itd.