SonicWall E5500 cz. 3

Zgodnie z zapowiedziami czas na kolejną odsłonę mojej przygody z SonicWall E5500. Jak wspomniałem w poprzedniej części moja przygoda będzie krótsza niż się wcześniej zapowiadało, a poniższy wpis po części wyjaśni dlaczego...

Dałem słowo, że zajmę się interfejsem, a słowa należy dotrzymywać. Zatem dziś będzie o interfejsie zarządzającym tego urządzenia. Skupię się na dostępie webowym, bo o CLI za dużo nie ma co pisać.

Słowo wyjaśnienia – po co w ogóle rozpisywać się o interfejsie??? Przecież to tylko dodatek... Według mnie interfejs tego typu urządzeń jest bardzo ważnym czynnikiem, który może zdecydować o wyborze danego urządzenia. Nie twierdzę, że ktoś wybierze urządzenie X bo ma ładniejszy interfejs od urządzenia Y mimo, że to drugie oferuje dużo większą wydajność i jest dużo bardziej funkcjonalne. Uważam, że sporo urządzeń (SonicWall, Netasq, Fortigate) posiada dość zbliżone możliwości zarówno w zakresie funkcjonalności jak i wydajności, a interfejs jest czymś co może dany sprzęt wyróżnić i znacząco wpływa na wygodę danego rozwiązania.

Nie oszukujmy się – to właśnie interfejs będzie tym z czym potencjalny admin będzie się stykał na co dzień przez kilka miesięcy od wdrożenia :) UTM, to nie jest coś co wdrożymy, powiesimy w szafie i zapomnimy. To żyje razem z naszą siecią i wymaga ciągłej naszej uwagi...

Zatem jak to wygląda w naszym bohaterze – SonicWall E5500.

Po zalogowaniu domyślnie otwiera się zakładka status która jest pokazana poniżej:

Jak widać układ jest dość klasyczny - rozbudowane menu po lewej, w środkowej części zawartość. Na powyższym zrzucie można dodatkowo zobaczyć jakie elementy są licencjonowane ;)

Kolejny zrzut to widok interfejsów:

Jak widać możemy tu konfigurować istniejące interfejsy, dodawać nowe, zapoznać się ze statystykami itp... Jak na moje możliwości jest tutaj dość dużo. By nie powiedzieć za dużo - tu jakaś rozwijana lista, tu jakiś przycisk, tu przełącznik, tu coś tam coś.... Tu jeszcze nie jest źle....

A teraz czas na polityki:

Dodam tylko, że to jest jeden z 3 możliwych widoków dla polityk.

I ostatnie zdjęcie - dodawanie nowej polityki

Jak wygląda interfejs – wydać na zdjęciach powyżej. Bardziej zainteresowani mogą pobawić się wersją demo dostępną tutaj. A jakie są moje odczucia....

Najpierw będzie pozytywnie. Interfejs jest ładny, czytelny i w miarę nowoczesny. Widywałem lepsze (według mnie FortiGate), ale też dużo gorsze (Juniper).

Z takich „smaczków” które przypadły mi do gustu:

1) Załóżmy, że na interfejsie X0 mamy WAN od TP, na X1 WAN od Netii, a na X2 LAN z uruchomionym serwerem DHCP. Oba łącza WAN działają w trybie failover czyli jak jedno padnie ruch powinien być przekierowany na drugie. W takim razie jakie adresy DNS powinien rozdawać nasz DHCP??? Te od TP czy te od Netii??? Ja powszechnie wiadomo jeden operator „nie wpuści” ruchu do swojego DNS'a od konkurencji :) SonicWall bardzo sprytnie to rozwiązał i do konfiguracji serwera DHCP może być automatycznie wrzucany DNS z aktualnie aktywnego połączenia WAN. Super rozwiązanie

2) Przy tworzeniu polityk możemy „przy okazji” definiować na przykład obiekty, definiować własne serwisy itp... To wydaje się oczywiste, przecież tak powinno być, ale niestety nie zawsze jest... Jako przykład może tu posłużyć Juniper w przypadku którego obiekty (takie jak adresy czy usługi) definiuje się w konkretnym miejscu i koniec kropka. Jeżeli przy tworzeniu polityki przypomni nam się, że trzeba by jeszcze zdefiniować usługę to.... sory taki mamy klimat. Trzeba wyjść, zdefiniować usługę i stworzyć na nowo politykę. Wkurzające strasznie

3) ToolTip czyli baloniki czy jak zwał tak zwał. W każdym razie podpowiedzi. Bardzo praktyczne i wygodne. Generalnie spora zaleta. Problem polega na tym, że wyskakują wedle bardzo skomplikowanego algorytmu (sprawdzane pod Linuksem na Chrome i Firefox). Najeżdżamy na dane pole i tooltipa brak. Czekamy i czasem wyskoczy. A jak nie to pomerdamy myszką najedziemy jeszcze raz i tooltip wyskoczy. Albo i nie :)

4) Automagia czyli wyręczanie leniwych adminów z mozolnego tworzenia polityk. Na przykład podczas tworzenia nowej strefy możemy określić czy mają być automatycznie tworzone regułki zezwalające lub blokujące ruch z/do innych stref. Bardzo praktyczne, ale ja osobiście wolę mieć kontrolę nad tym co się dzieje i ręcznie tworzyć polityki.

5) Polityki zezwalające na zarządzanie urządzeniem na danym interfejsie są po prostu politykami :) Może brzmi to dziwnie, ale już wyjaśniam. W Juniper SSG przy konfiguracji interfejsu włączamy lub wyłączamy możliwość zarządzania interfejsem za pomocą SSH, HTTP, SNMP itd... I to tyle co możemy zrobić w kwestii ograniczania tego ruchu. Na przykład nie mamy możliwości ograniczenia ruchu SNMP tylko dla stacji monitorującej... Za to SonicWall ma duży plus.

A teraz czas na moje całkowicie subiektywne odczucia – interfejs jest przeładowany, przekombinowany i kompletnie nieintuicyjny. Zarządzanie całym urządzeniem było dla mnie nie lada wyzwaniem. Oto kilka przykładów:

1) „Wszystko jest polityką” - mamy zatem polityki access rules, app rules, ale mamy też NAT policy, route policy itp itd... Może to sprawiać wrażenie spójności – polityki są do wszytkiego. Pytam się jednak – po co? Po co dla prostego routingu zaprzęgać zaraz polityki? W Juniperach mamy destination routing, source routing (definiuje się je prosto łatwo i przyjemnie) i ostatni mechanizm do rzeczy ciężkich – policy based routing. Mi to zdecydowanie bardziej odpowiada. Proste rzeczy należy robić w prosty sposób :)

2) NAT też jest polityką – ciąg dalszy poprzedniej uwagi. Jeżeli chcemy zezwolić na ruch z X1 do X3 i zrobić NAT'a to musimy zrobić 2 osobne polityki. Czy na prawdę nie wystarczyłoby dodać checkbox'a "NAT"?

3) Logowanie ruchu na polityce – w przypadku Junipera jeżeli włączymy logowanie na danej polityce obok niej pojawia się magiczny guziczek po którego kliknięciu widzimy od razu ruch do niej wpadający. Super rozwiązanie. SonicWall zmusza nas do przejścia do „globalnego” loga i jego filtrowanie.... Wstrętnie to wymyślili :)

4) Jedną z rzeczy jakie chciałem zrobić podczas testów to zestawienie VPN (dokładnie route based VPN) z Juniper SSG i puszczenie ruchu pomiędzy tymi urządzeniami. Mimo poświęcenia kilku godzin nie udało mi się tego zrobić. Tunel zestawiony, polityki dodane, routing dodany a ruchu brak. Ja nie twierdzę, że tego nie da się zrobić, bo jestem pewien, że się da. Twierdzę jednak, że kiedy miałem na biurku Fortigate których też nie znam zrobiłem to bez problemu. To jest właśnie intuicyjność :)

Czas na podsumowanie – interfejs SoniWalla choć „ładny” i w miarę nowoczesny, zupełnie mi nie odpowiada. Jest przeładowany i przekombinowany. To źle kiedy komplikuje się proste rzeczy (nat, routing). To źle kiedy nie powiela się dobrych rozwiązań (przeglądanie logów). To źle kiedy umiarkowanie ogarnięty człowiek nie ogarnia interfejsu :)