21T22 Aruba Policy Domain 8.6 w 17 min [Konfiguracja]

Role ACL

Link do artykułu.

0:00 Wprowadzenie

0:20 Konfiguracja profilu polityki domenowej

1:40 Role

5:20 Omówienie środowiska testowego

5:45 Potwierdzenie działania acess list

9:23 Testowanie komunikacji

13:55 Pingowanie Minta

14:30 Zmiana roli na Mincie

17:00 Podsumowanie

Cześć! Chciałbyś zobaczyć, jak skonfigurować Policy Domain, czyli najnowszą technologię Aruby, dodaną w wersji 8.6, do tego, żeby można było w wielu kontrolerach stosować reguły w oparciu o rolę? Jeżeli tak, to zapraszam Cię do konfiguracji.

Pierwszym krokiem, żeby skonfigurować Policy Domain, jest przejście do części konfiguracji, na Mobility Masterze jesteśmy teraz-Managed Network. Na tym poziomie, przynajmniej w tej wersji funkcjonalności Policy Domain, trzeba dodać konfigurację profilu całej polityki domenowej. Wchodzimy w konfigurację Managed Network, Configuration, System, a następnie Profiles. Tu w tych profilach mamy taki zestaw profili Policy Domain. W tej wersji jest możliwość zdefiniowania tylko jednej takiej polityki. Mam już taką przygotowaną. Czyli w polityce musimy dodać listę kontrolerów, które będą współdziałały w ramach całej polityki domenowej. Czyli mamy w tym momencie jeden kontroler dodany, z końcówką 95:b7, to jest kontroler rapmc. 95:b7, to jest ten kontroler. Dodaliśmy ten kontroler w tej polityce z Radkiem po to, żeby potem przetestować całą funkcjonalność. Jedna uwaga, jeżeli chodzi o ograniczenia, ta polityka Policy Domain, jeżeli stosujesz klasę, powinna być najpierw zadefiniowana, a potem dopiero powinien być stworzony klaster kontrolerów. Nie na odwrót.

Wracamy do kolejnego kroku konfiguracji. Mamy już politykę na poziomie
Managed Network zrobioną, teraz możemy przejść już konkretnie do ról,
czyli przechodzimy do Roles & Policies. Mamy tutaj już stworzoną wcześniej rolę, specjalnie pod tę funkcjonalność, pod to pokazanie: NAP-domain-policy-role, czyli trzy reguły mamy tutaj zadefiniowane. Teraz pokażę Ci, jakie reguły są tutaj wykonane. Pierwsza reguła to jest reguła mówiąca, że jeżeli adres czy pakiet z dowolnego adresu IP będzie kierowany do użytkownika, który jest
w roli-i tutaj sprawdzimy, jaka to jest rola, przejdźmy do widoku zaawansowanego i zobaczmy, jaka to jest rola. Czyli jeżeli z dowolnego adresu IP będziemy szli do roli userrole i tu poniżej zobaczmy, jaka to jest rola: rola authenticated. Czyli widać, że Destination user role jest authenticated. Wtedy akcja jest deny_opt, czyli będziemy ruch odrzucać. Okej, czyli mamy tutaj już pierwszą regułę w oparciu o role, a to jest właśnie zaleta policy domain role, czyli że możemy kreować polityki, te access listy, w oparciu o nazwę roli.

Kolejną politykę, która tutaj jest stworzona, np. stosowania tego mechanizmu, jest ruch, który idzie od użytkownika userrole i ten użytkownik będzie w roli NAP-domain-policy-role. Czyli taki użytkownik nie będzie mógł dostać się do Facebooka. Tu jest alias założony i pod tym aliasem jest domena facebook.com. Jeżeli ruch nie kwalifikuje się ani w pierwszą ani w drugą regułę, trafia w regułę trzecią, przepuszczamy wszystko. Czyli w tym przykładzie będziemy pokazywać, że nasz ruch do użytkownika, który jest w roli authenticated od dowolnego adresu IP będzie dropowany, jak również ruch od użytkownika
w roli NAP-domain-policy-role będzie blokowany, jak będzie szedł na alias facebook.block. Okej, to teraz jeszcze przeglądnijmy ten alias. Żeby sprawdzić, jak wygląda alias, możemy zobaczyć tutaj na górze konfigurację aliasów. Alias stworzony facebook.block zawiera informację, że jeżeli będzie nazwa domenowa facebook.com, tu może być oczywiście lista, my umieściliśmy w tym przypadku jedną domenę, czyli facebook.com. Czyli to jest alias, którego używamy w naszej access liście.

Jeszcze na koniec, jaka rola jest tutaj powiązana. Czyli mamy role NAP-domain-policy-role, mamy ją powiązaną z naszą polityką. Zobaczmy sobie ten widok-Show Advanced View. Czyli mamy w roli NAP-domain-policy-role politykę NAP-domain-policy-role. Tak się nazywa polityka domyślna tworzona
z tej roli. Okej, czyli mamy już pełną konfigurację zrobioną, jeszcze teraz tylko omówienie testowego środowiska, którego będziemy używać. Mamy rapmc, kontroler, do którego spinamy zdalne rapy po IP seku te rapy mają różne sieci bezprzewodowe. Czyli jeżeli popatrzymy teraz na to, jakie sieci będziemy używać, to będziemy używać tutaj sieci Radka, czyli tutaj będzie sieć NAP-USER-Radek. Ta sieć ma domyślnie rolę authenticated, będziemy też używać sieci NAP-HASLO-Radek. Zobaczmy, jaką ona ma. Tutaj ma ustawioną też rolę authenticated. Ale możemy ją zmienić na rolę NAP-domain-policy-role. Czyli będziemy używać jednego użytkownika w roli NAP-domain-policy-role, a drugiego użytkownika w roli authenticated. Mam tutaj już gotową nagraną całą część, pokazującą, jak Policy Domain działa w moim środowisku, więc przejdźmy do tego, jak można potwierdzić działanie access list, które są oparte na nazwach ról. Mamy tutaj dwóch użytkowników podpiętych, jeden użytkownik, jak widzisz ma rolę authenticated, drugi ma NAP-domain-policy-role. Czyli mamy dwóch użytkowników w różnych rolach. I teraz do roli NAP-domain-policy-role mamy przypiętą access listę, czyli tę politykę, gdzie mamy ograniczenia w dostępie do Facebooka i mamy ograniczenia w dostępie do użytkownika w roli authenticated.

Okej, ruszajmy. Będziemy testować tutaj pingi na początku, czyli komunikację IP i CNP. Obaj użytkownicy są podpięci, jak widzisz przez rap AP-203R, jeden jest użytkownik podpięty do NAP-USER-Radek, a drugi jest do NAP-HASLO-Radek. Dwie różne sieci po to, żeby były dwie różne role przydzielone. To kontynuujmy. Mamy dwóch użytkowników. Teraz zobaczmy, jakich użytkowników, czy jaki adres IP, mamy u każdego z tych hostów, czyli ten Linux Mint będzie w sieci NAP-USER-Radek. On będzie miał adres IP-zaraz
sprawdzimy jaki-w sieci 10.234.234, czyli widzimy, że ten Mint będzie miał z końcówką 11 adres IP. Czyli mówimy tutaj o tym hoście, który jest w roli, sprawdźmy jeszcze, jaka to była sieć. Czyli to jest sieć NAP-USER-Radek, miał rolę, którą tutaj przed chwilą wyświetlaliśmy NAP-policy-domain-role, czyli to jest użytkownik, który będzie miał ograniczenia w pingowaniu do Facebooka. Spróbuj zapamiętać, że ten Linux będzie miał ograniczenia. Jedźmy teraz dalej do drugiego użytkownika. Drugi użytkownik będzie w Windowsie realizowany. Tutaj możemy zobaczyć, jaki adres IP ma ten użytkownik. Z końcówką 9. Czyli końcówka 9 ma rolę authenticated, końcówka 11 ma rolę NAP-policy-domain-role. Okej.

Teraz spróbujmy przetestować komunikację. Adresem IP tutaj na kontrolerze się nie przejmuj, to jest jakiś stary adres zapamiętany 192.168, tutaj mamy adres, jak przed chwilą widziałeś, 10.234.234. Oba urządzenia są w tej samej sieci, więc testowanie będzie typowo po L2, ale ponieważ cały ruch jest tunelowany do kontrolera, to mamy wpływ naszymi politykami na sposób realizacji tej polityki. Czyli jak widać, mam tutaj politykę, którą wcześniej pokazywałem NAP-domain-policy-role, już ją omówiliśmy, więc tutaj szybko ją przeskoczę. Zobaczmy teraz pingowanie. Ping będzie szedł teraz z Minta, to przypomnę: końcówka 11 jest tego hosta i pingujemy końcówkę 9, czyli Windowsa. Teraz zgodnie z naszą access listą, jeżeli pamiętasz to, co pokazywałem w pierwszej części tego odcinka, to blokujemy ruch od dowolnego
adresu IP do użytkownika authenticated, czyli jeżeli ten Mint próbuje zpingować Windowsa, to trafia w regułę blokowania dotyczącą roli. Czyli tutaj widać, że nie działa nam taki profil ruchu i drugi wpis, facebookowy z aliasem,
który pokazywałem wcześniej, blokuje ping do Facebooka od roli NAP-domain-policy-role. Czyli w tej roli jest ten Linux i widać, że ping nie przechodzi. Czyli widać, że access lista działa właściwie.

Zróbmy teraz inne ćwiczenie. Zmieńmy teraz rolę dla użytkownika linuksowego. A jeszcze zanim przejdziemy do zmiany roli, sprawdźmy, jakby to wyglądało z punktu widzenia Windowsa. Czyli mamy tutaj Windows w roli authenticated. Widać, że Windows jest w roli authenticated. Tu w roli authenticated nie mamy ograniczeń co do pingowania i mamy też założoną
access listę dla roli NAP-domain-policy-role, mówiącą, że blokujemy ruch ping, ale tylko od użytkownika, czyli z każdego adresu do użytkownika. W związku z tym nam ping od tego adresu 11, czyli z Minta nie szedł, ale Windows powinien odpowiadać. Dlatego, że Windows i ping od Windowsa będzie trafiał w trzecią regułę, która umożliwia przepuszczenie tego ruchu. Może to pokażę na regułach. Wróćmy na chwilę do reguły, którą mamy tutaj skonfigurowaną.

Mamy tutaj naszą politykę. Czyli mamy w tej polityce powiedziane, że jeżeli pingujemy od dowolnego adresu IP do użytkownika authenticated to ten ruch będzie dropowany i ta polityka jest dopięta do Minta, bo tę access listę stosujemy tylko w przypadku roli, którą ma ten Mint, czyli ta stacja końcowa Linuksa. Czyli jeżeli Linux będzie pingował użytkownika authenticated, to jego ruch będzie dropowany. Ale jeżeli popatrzysz sobie na rolę authenticated, która nie ma ograniczeń. Spójrzmy na tę rolę. Authenticated. Tutaj będzie cały ruch przepuszczany. Czyli widać, że tutaj mamy cały ruch za wyjątkiem icmpv6, cały ruch pozostały jest przepuszczany. Czyli Windows będzie mógł pingować Minta. Dlaczego się tak dzieje? Dlatego, że to rozwiązanie tych access list jest stanowe, ma znaczenie, z której strony ruch jest nawiązywany. Czyli Mint nie może pingować Windowsa, ale Windows może pingować Minta i wtedy odpowiedź będzie przepuszczana przez kontroler.

Okej, to wróćmy teraz do przykładu. Przypominam, że teraz patrzymy na Windowsa i pingujemy Minta, czyli końcówka 11 w sieci 234.234.11. Zobaczmy,
czy ping odpowiada. Jak widać zgodnie z oczekiwaniem ping odpowiada. Dobra, zobaczmy jeszcze Facebooka. Czyli jeżeli chodzi o Windowsa, tutaj jest rola authenticated bez ograniczeń, Facebook powinien odpowiadać. Zgodnie z oczekiwaniem Facebook odpowiada na Windowsie. Teraz zrobimy kolejną jeszcze zmianę przy tym sprawdzaniu, czyli zmienimy rolę na Mincie. Zmienimy rolę na authenticated i sprawdzimy, czy Facebook, jak i Windows, zaczyna odpowiadać. Jesteśmy na Mincie. Widzimy, że dalej Mint ma rolę NAP-domain-policy-role, to znaczy, że jeszcze nie będzie odpowiadał. Żeby zaczął odpowiadać, trzeba zmienić mu rolę.

Co zrobić, żeby zmienić rolę? Wystarczy go rozłączyć. Urządzenie końcowe automatycznie się podłączy i już będzie z nową rolą przez nas ustawioną. Żeby tę rolę zmienić, to wchodzimy w ustawienia sieci bezprzewodowej i domyślnie ustawiamy dla tej sieci bezprzewodowej rolę authenticated. Czyli sprawdzamy, w jakiej sieci bezprzewodowej był ten użytkownik, był w NAP-USER-Radek,
ustawienia tej sieci w zakładce access i tu ustawiamy domyślną rolę authenticated. Teraz wystarczy zatwierdzić, zapisać tę konfigurację, a następnie rozłączyć użytkownika. Sprawdźmy. Tu jest zapisanie. Okej. Radek próbuje zapingować przed rozłączeniem tej stacji końcowej, w związku z tym ta stacja nadal w roli NAP-policy-domain i widać, że ping nie przechodzi. Bo ta rola nadal jest NAP-policy-domain, która ma access listę zapiętą na sobie. Przechodzimy jeszcze raz do kontrolera, do klientów i wystarczy po prawej stronie nacisnąć tutaj ten kosz. Skasujemy, czy wyrzucimy tego klienta,
jego sesję z kontrolera. Urządzenie standardowo końcowe się spróbuje podłączyć jeszcze raz i będzie już w nowej, właściwej roli. Pingujemy cały czas
ze stacji końcowej. Widzimy, że pingi nie idą-i w pewnym momencie zaczynają pingi przechodzić. Czyli widać, że rola została przydzielona na kontrolerze i pingi są realizowane.

Na koniec możemy jeszcze zobaczyć, że mamy możliwość, już w nowej roli authenticated, zobaczenia, że komunikacja z facebook.com również przechodzi. Sprawdźmy. Widzimy, że pingowanie działa. Tu po prawej stronie też widzisz, że zmienił się typ roli, jest teraz rola authenticated po prawej stronie. Jak widzisz, doskonale ten mechanizm Policy Domain działa. Ważne jest to, że ten przykład, który widziałeś dotyczy jednego kontrolera, ale tak samo to działa, jeżeli będziesz miał tych kontrolerów wiele w całej domenie, którą skonfigurujesz do działania w ramach tej grupy ról. Co jest bez wątpienia bardzo wygodne.

Jeżeli jesteś ciekaw więcej informacji teoretycznych, dlaczego tak to zostało zrobione, jakie ma plusy, minusy ta technologia, jakie są ciekawostki z tym związane, to zapraszam Cię do mojego podcastu. Tam temat Policy Domain, tej części teoretycznej, bardziej rozwinę. Na dzisiaj to tyle. Dziękuję Ci za uwagę i do usłyszenia w przyszłym tygodniu.