Podkast 21T47 Łączenie Aruba Mobility Controller’a i Mobility Conductor’a [Konfiguracja]

WERSJA TEKSTOWA

Cześć, witam Cię w moim podkaście. Dzisiejszy temat to łączenie Mobility Controllera Aruby z Mobility Conductorem. Najczęściej, jeśli mówimy o scenariuszu korporacyjnym, w jednej lokalizacji – najczęściej głównej – mamy do wyboru dwa tryby. Najczęściej stosowany jest IP sec z shared key, czyli w oparciu o adres IP. To z tego powodu, że najczęściej wybieranym Mobility Conductorem jest wersja wirtualnego Appliance, w związku z tym stosujemy klasyczny IP-sec – IP do IP z opcją shared key, czyli z hasłem współdzielonym. Tak najczęściej to robimy. Jeśli potrzebujemy skonfigurować połączenie certyfikatami, to taki IPsec również jest możliwy do zestawienia. Natomiast mówiąc o campusie, o naszej zaufanej sieci, o tym środowisku, które w zasadzie w pełni kontrolujemy, to jest to opcja bezpieczna. Możesz to też zabezpieczyć w inny sposób – opierając o certyfikaty. Konfiguracja wtedy jest już trochę bardziej skomplikowana, nieco inna. Być może będzie wymagała dodatkowej generacji certyfikatów i zależna jest od platformy.

Tak jak wspomniałem konfiguracja wirtualnych maszyn, nie zawierających TPM-a jest inna. Jeżeli chcesz korzystać z TPM-a certyfikatów fabrycznych, to procedura jest również nieco inna. Ja pokazuję w najprostszej, najbardziej typowej wersji, konfigurację IPsec-a z preshared key, między kontrolerem Aruby a Mobility Conductorem, czyli takim nadrzędnym kontrolerem. Wszystkie z tych kontrolerów spinają się IPsec, nie ma innej możliwości, musi to być zrobione przez IP-sec, nawet jeżeli są w tym samym LAN-ie, w tej samej podsieci i tak musi być IPsec. Jeżeli chodzi o zestawianie się tego tunelu kontrolnego i generowanie konfiguracji, jeżeli pracujemy z kontrolerem zarządzanym przez Mobility Conductora, to nie mamy możliwości wykonać żadnej zmiany na tym kontrolerze. Jeśli zalogujemy się np przez SSH i chcemy na kontrolerze bezprzewodowym MC zmienić jakieś ustawienia, to dostaniemy informację, że wejście w tryb konfiguracyjny jest niemożliwe, bo jest zarządzany przez Mobility Conductor.

Opcje są dwie. Robić konfigurację z Mobility Conductora i jest to normalna, przewidziana przez producenta ścieżka, ale czasami zdarzają się takie sytuacje, że nam brakuje trochę konfiguracji. Np na interface jest zły adres IP lub konfiguracja portu jest nie taka – jest tagowany a ma być nietagowany, bądź cokolwiek innego, co błędnie wprowadziliśmy przy pierwszej, inicjalnej konfiguracji. W takim przypadku możemy wejść w tryb disaster recovery i na tym kontrolerze takie dane zmienić. Pamiętać jednak należy, że zależy jakie dane zmieniamy, ale są tzw dane lokalne i globalne – globalne zostaną nadpisane, jeśli podłączy się właściwie kontroler do Mobility Conductora. To jest element, nad którym warto się chwilę zastanowić, jakie podejmiemy poszczególne kroki. Jeśli wszystkie kroki konfiguracyjne zostały zrobione prawidłowo, nie powinno być potrzeby wchodzenia w tryb disaster recovery. Całą konfiguracje robimy wtedy z Mobility Conductora, trzeba go tylko najpierw odpowiednio przygotować.

Pierwszy krok, aby podłączyć Mobility Kontroler do Conductora jest taki, że trzeba podać te same dane do IPsec-a, czyli ten sam preshared key i podany adres IP, z jakiego mamy połączenie, czy do jakiego się będziemy łączyć pomiędzy kontrolerami.

Drugi krok – na Mobility Conductorze jest konieczność skonfigurowania grupy konfiguracyjnej. Musimy dodać, w jakiś sposób (są dwa) ten kontroler do jakiejś konfiguracji. Jeśli nic nie zrobimy, to żadna konfiguracja nie zostanie zapisana, bo Mobility Conductor nie wie, jaką konfigurację przypisać. Jeżeli włączymy automatyczne, domyślne parkowanie kontrolerów do jakiegoś katalogu, to oczywiście konfiguracja tego katalogu będzie używana. To się przydaje, jeżeli mamy jedną spójną konfiguracje dla np 100, 200, 300 tys. branchy, to wtedy przydaje się Autopark bo nie trzeba ręcznie dodawać kontrolerów. Jeśli chodzi natomiast o kontrolery w naszym kampusie, jest ich 4, 3, 2, to spokojnie możemy je dodać ręcznie i wtedy wpisujemy ręcznie grupę konfiguracyjną. Ten kontroler – do tej grupy konfiguracyjnej, ten do drugiej grupy konfiguracyjnej itd. – lub do tej samej, w zależności o tego, ile typów konfiguracji dla kontrolerów mamy przygotowane. Typowo, jeżeli kontrolery pracują w parze, w jednej funkcji, to dodajemy je do jednego folderu konfiguracyjnego. Jeżeli mamy np inne kontrolery w DMZ-cie to tworzymy inny folder konfiguracyjny i do takiego folderu dodajemy jeden, dwa lub więcej kontrolerów. Ponieważ mamy Mobility Conductora, to możemy te kontrolery łączyć w klastry, więc może ich być dużo więcej w danym katalogu, w zależności od modelu nawet do 12 sztuk.

Takie podstawowe kroki trzeba podjąć, żeby móc podłączyć Mobility Controllera, czy to fizycznego, czy wirtualnego, do Mobility Conductora. W razie pytań do tego tematu – pisz w komentarzu. Jeżeli chcesz przejrzeć materiał konfiguracyjny to najbliższy odcinek będzie o łączeniu Mobility Controllera z Mobility Conductorem. Polecenia możesz skopiować z bloga lub obejrzeć na YouTube w zależności od preferencji.

Na dziś to tyle, dziękuję Ci za uwagę i do usłyszenia już za tydzień.