Dla zrozumienia, dlaczego EdgeOS zachowuje się w taki, a nie inny sposób, dlaczego i jakich adresów IP użyć we wpisach w regułach firewalla, dlaczego NAT konfiguruje się właśnie tak, a nie inaczej, i tak dalej, niezbędne jest zrozumienie kluczowego zagadnienia – w jakiej kolejności realizowane są kolejne operacje na pakietach. Bo przecież inaczej będziemy pisać reguły FW, jeżeli ruch najpierw podlega translacji adresów i/lub portów, a dopiero później jest dopasowywany do reguł zapory, niż w sytuacji, gdy zachodzi kolejność odwrotna, czyli najpierw dopasowanie reguły filtra, a następnie realizacja podmiany adresacji i/lub numerów portów.
Najpierw trzęsienie ziemi
Tak, wiem, że to zagadnienie brzmi co najmniej jak wiedza tajemna. I pewnie jak Wam pokażę przykład, jak diagram przepływu pakietów wygląda u jednego z konkurentów Ubiquiti, to wydacie cichsze albo i głośniejsze jęknięcie. Nie dziwi mnie to, bo tym diagramem można by straszyć młodych (niektórych starszych też) administratorów sieci:
Ale spokojnie, to nie film Alfreda Hitchcocka. Na szczęście tak dla Was, jak i dla mnie, bo pewnie nigdy w życiu nie udałoby mi się przekazać istotnej wiedzy w oparciu o taki rysunek. Ubiquiti przygotowało znacznie przyjaźniejsze schematy.
Ruch przychodzący interfejsem WAN
Przypadek pierwszy, czyli przepływ pakietów, które przychodzą interfejsem WAN. Jak widać, pierwszą kluczową operacją jest DNAT (Destination NAT), czyli translacja adresów docelowych. Dopiero po niej podejmowana jest decyzja o routingu.
Dalsze przetwarzanie pakietów zależy od miejsca docelowego: czy jest to ruch przechodzący przez router i mający opuścić go interfejsem LAN (lewa gałąź schematu), czy ruch lokalny kierowany do routera (prawa gałąź schematu). W zależności od tego aplikowane są reguły firewall’a – odpowiednio IN lub LOCAL:
Ruch przychodzący interfejsem LAN
Schemat dla ruchu przychodzącego interfejsem LAN jest lustrzanym odbiciem poprzednika.
Pozwolę sobie zwrócić uwagę na jeden aspekt, który może rodzić kłopoty. Otóż reguła OUT firewalla aplikowana jest przed realizacją SNAT (Source NAT), czyli translacją adresów źródłowych. Czemu to istotne? Rozważmy takie zagadnienie: zgodnie z dobrą praktyką chcemy profilaktycznie zaaplikować regułę, która zapobiegłaby wyjściu na świat pakietów z adresacją prywatną zdefiniowaną w RFC1918. Czyli ochoczo sporządzamy trzy wpisy, które wycinają ruch z adresami źródłowymi 10.0.0.0/8, 172.16.0.0/12 oraz 192.168.0.0/16 i aplikujemy na interfejsie WAN w kierunku OUT, po czym… zaraz, a gdzie wcięło internet? Z internetem wszystko jest okej. Tu jest właśnie ten haczyk – FW jest realizowany przed „maskaradą”.
Po krzyku
Czy było tak strasznie, jak się zapowiadało? Mam nadzieję, że nie. I jak zawsze zachęcam do dyskusji, zadawania pytań oraz zapisania się do grupy Ubiquiti Polska na FB.
Komentarze