20T42 – Clearpass Routing [Konfiguracja]

Więcej miejsc do posłuchania:

Koncepcja VRF na Clearpass’e 6.9.3

Pewnie jesteś nieco zaskoczony (ja byłem) jak się dowiedziałem, że w Clearpassie zastosowano koncepcję VRF.

Na początek któtkie przypomnienie Clearpass posiada 2 interfejsy opisane jako MGMT (do zarządzania) oraz DATA (do świadczenia usług).

Nie daj się zmylić, taki podział był faktycznie ale w starszych wersjach Clearpass’a, na porcie MGMT nie można było obsługiwać zapytań Radius.

Od wersji 6.1 w domyślenej konfiguracji wszystkie usługi są dostępne na obu portach.

Jednocześnie warto pamiętać, że nie można skonfigurować tylko portu DATA, konieczne jest skonfiugrowanie zawsze portu MGMT.

To dobra oraz jednocześnie zła wiadomość. Dlaczego?

Opis problemu

Mając 2 równorzędne porty trzeba w jakiś sposób zorganizować routing.

Jeżeli wykonujesz implementację bazując tylko na jednym skonfiugrowanym procie MGMT, to nie ma tutaj żadnych zaskoczeń serwer działa jak każdy inny.

W przypadku korzystania z dwóch portów, a takie są dobre praktyki, powinieneś zaplanować komunikację administracyjną na porcie MGMT, a uwierzytelnianie na porcie DATA.

Koncepcja bardzo słuszna, tylko że można się zdziwić w niektórych scenariuszach.

Mój scenariusz:

Mam 2 Clearpass’y podłączone ze sobą przez router’y. Interfejsy na kadym Clearpass’e należą do innej sieci.

To jest bardzo typowy model rzeczywistego wdrożenia. Ruch pomiędzy sieciami przypisanymi do interfejsu MGMT oraz DATA jest blokowany ma routerze.

Właśnie realizując takie wdrożenie spotkałem się z probemem, który opisuję dla Ciebie :).

Zestawiam klaster z przedstawionych Clearpass’ów na etapie gdy mam skonfigurowany tylko interfejs MGMT. Wszystko działa prawidłowo.

Następnie dodaję konfiugrację interfesju DATA na clearpass2.netadminpro.pl

I otrzymuję infomację już podczas rekonfiguracji, ze Clearpass2 utracił połączenie z Clearpass1.

Po chwili sprawdzam status klastra na stronie głównej obu Clearpass’ów i widzać wyraźnie, utratę komunikacji w klastrze:

Zrozumieć zasadę działania

Żeby zrozumieć co się właśnie wydażyło, poczytałem jak działa routing w rozwiazaniu Clearpass od wersji 6.1.

Na Clearpassie 6.9.3 na jakim obecnie pracuję, mamy 2 VRF’y i w każdym znich mamy domyślną bramę.

To oznacza że Clearpass w jakiś sposób musi określać którym VRF’em będzie obsługiwał daną sesję.

3 Reguły Wyboru VRF’a – Klient ->Clearpass

1. Połączenie przychodzi na interfejs MGMT, to odpowiedź na tę sesję będzie wychodziła z tego samego interfejsu
2. Sesja jest odbierana na interfejs DATA, to odpowiedź na tę sesję będzie wychodziła z tego samego interfejsu
3. Jeżeli interfesj DATA nie jest skonfiugurowany cały ruch będzie wychodził interfejsem MGMT

Dlatego mimo że nie ma komunikacji wewnątrz klastra, to dostęp administracyjny nadal zachowałem.

3 Reguły Wyboru VRF’a – Clearpass->Clearpass

1. Sieć docelowa jest z zakresu sieci interfejsu MGMT, ten interfejs zostanie wybrany do wysłania pakietów
2. Sieć docelowa jest z zakresu sieci interfejsu DATA, ten interfejs zostanie wybrany do wysłania pakietów
3. Sieć docelowa nie spełnia warunku 1 lub 2, pakiety będą wysyłane przez interfejs DATA

Ten 3 punkt jest właśnie powodem wystąpienia problemu z komunikacją w klastrze, w momencie ustawienia adresu IP na Clearpass2 DATA ten serwer próbuje wysyłać ruch synchronizacji klastra przez interfejs DATA.

Ten interfejs w moim środowisku nie ma połaczenia z Clearpass1 MGMT.

Komunikacja klastra

Do prawidłowej komunikacji w klastrze wymagane jest połączenie Subscriber’ów (podrzędnych członków klastra) do Publishera (czyli boss całego klastra :))

W moim środowisku Clearpass-NAP-1 jest Publisherem, a Clearpass-NAP-2 jest Subscriberem.

Ruch z podrzędnych Clearpass’ów w klastrze może wychodzić z dowolnego interfejsu, ale musi trafić na interfejs MGMT Publisher’a, czyli w moim przypadku Clearpass1.

Rozwiązanie

Czy taka konfiguracja jest nieprawidłowa?

Nie, producent musiał przyjąć jakieś podstawowe zasady kierowania ruchem.

Nie da się przewidzieć wszystkich możliwych scenariuszy implementacji, to pozostawiono nam, ekspertom od Clearpass’a 🙂

Jak zatem zmienić kierowanie ruchem na Clearpass’e?

Cel do osiągnięcia

Moim celem jest kierowanie całego ruchu dotyczącego klastra, z interfejsów MGMT Clearpass2 na MGMT Clearpass1 i symetrycznie w drugą stronę.

Konfiugracja

Do zmiany zasad kierowani ruchem trzeba zalogować się do CLI do Clearpass’a i sprawdzić jakie reguły są skonfigurowane

Polecenie:

network ip list

Krótki opis co widzimy:

IP Rule Information – Reguły sterowanie ruchem, tutaj będę za chwilę dodawał reguły pod mój scenariusz
Route Information for Table main – główna tablica routingu
Route Information for Table static – tablica routings związana z wpisami statycznymi
Route Information for Table mgmt – tablica routingu dla interfesju mgmt
Route Information for Table data – tablica routingu dla interfesju data

Z głównej tablicy możemy wyczytać, że domyślna trasa jest przez interfesj eth1, czyli nasz interface DATA. To zgadza się z opisanymi wcześniej regułami kierowania ruchem.

Dla każdego Clearpass’a dodam teraz regułę statyczną, odpowiednio do zdalnego Clearpassa:

Clearpass-NAP-1

network ip add mgmt -d 10.17.17.130

Clearpass-NAP-2

network ip add mgmt -d 10.253.253.130

Po sprawdzeniu komunkacji klastra widać powrót komunikajcji między serwerami

Sprawdzę jeszcze zapisane reguły:

Clearpass-NAP-1

network ip list

Clearpass-NAP-2

network ip list

Podsumowanie

Domyślne kierowanie ruchem wychodzącym z serwera Clearpass nie było zgodne z moim scenariuszem użycia, można zachowanie Clearpass’a dostosować w zależności od potrzeb.

W innym projekcie spotkałem inny objaw tego samego problemu, mianowicie wystąpił asymetryczny routing, pokazujący na Publisher’e komunikację prawidłową w klastrze, a na Subcriber’e błąd komunikacji.

W zależności który ruch może dotrzeć do którego serwera objaw może być rózny.

To co jest wspólne dla tego problemu, to rozłączenie klastra lub jego części po zmianie ustawień interfejsu DATA.

Spoktałem się też z problemem niewpisania do tablicy „Route Information for Table data” tras, pomimo ustawienia adresu IP na interfejsie DATA. Ten problem można rozwiązać ponownie zmieniając ustawienia IP dla tego interfejsu.

To co jest mylące w takim scenariuszu, to że adres IP jest ustawiony i wszystko działa, a dopiero przy późniejszej zmienie tracimy komunikację klastra.

Jeżeli chcesz się upewnić czy wszystko jest jak zaplanowałeś, możesz kontrolnie sprawdzić tablicę routingu na Clearpass’e w pokazany sposób.