Podkast 22T38 Wireguard Site-to-Site i Road Warrior

Więcej miejsc do posłuchania:

Spotify

WERSJA TEKSTOWA

Cześć. Witam Cię w dzisiejszym podkaście. Temat to konfiguracja Wireguarda w dwóch trybach jednocześnie, czyli pierwszy tryb Site-to-Site i drugi tryb Road Warrior, czyli remote access. Jeżeli chodzi ogólnie o koncepcję Wireguarda to ona się nie różni w przypadku tych dwóch typów dostępu. Podstawowe założenie jest takie, że musimy wygenerować klucze publiczne, prywatne, czyli parami generujemy dla każdej ze stron. Musimy wtedy klucze publiczne wpisać na przeciwległej stronie tego tunelu.

Zacznijmy od remote access. Mamy klienta na którym generujemy tą parę kluczy, publiczny i prywatny. Kopiujemy klucz publiczny i wklejamy w konfiguracji, w tym przypadku MikroTika, który terminuje ten dostęp zdalny. Jeśli chodzi o połączenie adresacji to tutaj jest bardzo prosty mechanizm. Narazie tutaj nie widziałem routingu dynamicznego. Ten temat będę jeszcze zgłębiał, więc jeśli będę miał nowe informacje, to dam znać. Natomiast jeśli chodzi o każdy z tuneli, to wpisuje się adresy, które są dostępne czy zezwolone przez dany tunel.

W przypadku gdy masz konfigurację MikroTika i dostęp zdalny, to na MikroTiku musisz wpisać, że adresacja IP, która będzie przyznawana dla klientów, czyli dla tych zdalnych pracowników będzie dopuszczona i będzie umożliwiała komunikację. Jeżeli chodzi o konfigurację Site-to-Site – czyli to jest taki scenariusz, gdzie mamy jakieś dane lokalizacje podłączone na stałe. Dla każdej z tych lokalizacji mamy jakąś adresację i Ci użytkownicy w danych lokalizacjach też mają potrzebę dołączenia się do jakieś sieci w centrali. Tutaj musimy teraz wzajemnie wpisać tą adresację. Na MikroTiku, który jest w danej lokalizacji, trzeba wpisać wszystkie sieci, które będą dostępne za tunelem Site-by-Site. Natomiast po stronie centralnej, trzeba wpisać wszystkie sieci, które będą dostępne od strony centralnej do danych lokalizacji, za poszczególnym tunelem. Dla każdego tunelu jest tworzony interfejs logiczny a dla każdego peer’a, czyli zestawienia połączenia, musi być zdefiniowana lista adresacji. Gdy konfigurujemy jednocześnie dostęp Site-to-Site, czyli zdalnych lokalizacji i pracowników zdalnych, przez centralę, to wtedy umożliwiamy tą komunikację o ile odpowiednie sieci wpiszemy na wszystkich poszczególnych routerach. W przypadku centrali nie ma tutaj najczęściej dodatkowej konfiguracji wymaganej ponieważ MikroTik ma wszystkie sieci lokalne, które są dostępne. Jeśli łączymy się z tym pracownikiem zdalnym do centrali, to widzimy automatycznie wszystkie sieci, które są do MikroTika lokalnie podłączone. Natomiast jeżeli tym zdalnym pracownikiem chcielibyśmy się podłączyć do sieci, która jest w danej lokalizacji, to o tyle ten ruch nam przejdzie, o ile mamy zdefiniowane odpowiednie sieci dla poszczególnych tuneli.

To, co odkryłem, jak robiłem taką konfigurację ostatnio i sprawdzaliśmy, dlaczego nam całość tej konfiguracji nie działa, to okazało się, że brakowało wpisu, na routerze, który był w zdalnej lokalizacji dla adresacji, która była przydzielana dla użytkowników zdalnych, terminowanych w centrali. Musisz tu dobrze sobie przemyśleć które sieci gdzie są, gdy robisz konfigurację tego typu. Następnie dla każdego MikroTika odpowiednio ręcznie wpisać poszczególne sieci.

Co z tego wynika? Dla mnie jeden prosty wniosek. Jest to bardzo dobra, rokująca technologia. Poziom konfiguracji jest dość prosty, natomiast mało skalowalny. Dzisiejsza dobra praktyka dostępu zdalnego mówi, że powinieneś realizować dostęp zdalny dla danej klasy użytkowników, czyli ich roli i ograniczyć dostęp do odpowiednich zasobów. Co to oznacza? Że jeżeli masz jedną pulę z danych użytkowników i oni mają mieć wspólny poziom dostępu, to spełniamy to wymaganie. Lecz w przypadku, gdy chcielibyśmy wszystkich pracowników podłączyć do naszej firmy i oni mieliby mieć ten sam dostęp, mimo, że pełnią różne role – jedni pracują w HR, inni w IT, prezes – każdy ma inny poziom potrzebnych uprawnień. Do innych systemów powinni mieć dostęp. W związku z tym, dla takiego przykładu, jeżeli chciałbyś to robić na Wireguardzie (w minimalistycznej wersji), powinieneś stworzyć konkretny dostęp dla każdego z tych użytkowników na osobnym wirtualnym interfejsie (interfejsie Wireguardowym). Co więcej, jeśli chodzi o generowanie zdalnego dostępu zwaszcza, ponieważ tutaj zakładamy, że mamy tych zdalnych użytkowników wielu, więcej pewnie niż lokalizacji. Obsługuję i mam np. 1000 użytkowników zdalnych. Wyobraź sobie teraz konfigurację każdego klienta indywidualnie, generowanie pary kluczy dla takiej sytuacji. To rozwiązanie nie jest dla tego scenariusza. Nie nadaje się.

Krótko powiem jaka może być alternatywa. Nie jest to temat dzisiejszego odcinka ale być może kiedyś nagram podkast na ten temat. Jeżeli chodzi o implementację zdalnego dostępu w przypadku remote access bądź Site-to-Site w IP-sec, jest możliwość w ramach protokołu IKE w wersji drugiej, przesyłania informacji o zdalnych sieciach za pomocą właśnie tego protokołu negocjacji informacji o połączeniu. IP-sec w tym zakresie instalacji grupowej i możliwości późniejszego przesyłania informacji o sieciach, wydaje się, że na dziś się lepiej skaluje niż Wireguard. Przynajmniej w dzisiejszej implementacji. Założenie podstawowe Wireguarda jest takie, że ma to być prosty protokół, najprostszy jak tylko jest to możliwe. Generujemy pary kluczy, przypisujemy do nich adresy IP i mamy powiązanie co z czym powinno się łączyć lub może się łączyć. Natomiast jeśli chodzi o automatyczne scenariusze implementacji, o skalowanie, to tego z założenia, przynajmniej narazie w Wireguardzie w ogóle nie widzę. W związku z tym ten protokół się po prostu nie nadaje do rozwiązań, które mają być mocno skalowane.

Wracając do tytułu dzisiejszego podkastu. Gdy masz jeden punkt zdalnego dostępu – załóżmy, że masz 5,10 pracowników i to jest jeden typ dostępu. Chociaż jeżeli jest różny to nawet dla 10 zachęcam Cię do tego, żeby zrobić osobny interfejs logiczny dla danej grupy użytkowników. Masz jedną lub dwie zdalne lokalizacje i masz w nich możliwość podłączenia tych sieci w sposób manualny, czyli wpiszesz odpowiednie sieci w odpowiednich miejscach konfiguracji.

Na dziś to tyle. Mam nadzieję, że było to dla Ciebie ciekawe. Jeżeli będę zdobywał nowe doświadczenia w tym zakresie, to oczywiście się tym z Tobą podzielę. W przypadku pytań co do treści lub zagadnień, które Cię ciekawią – pisz w komentarzu. Chętnie się z nimi zapoznam. Do zobaczenia już za tydzień.


Autor: Darek Koralewski

Od początku swojej kariery, czyli od 2004 roku, zajmuję się sieciami komputerowymi ze szczególnym uwzględnieniem ich bezpieczeństwa oraz sieciami programowalnymi. Mam na swoim koncie całą listę certyfikatów różnych producentów, dwa najważniejsze to te poświadczające najwyższy poziom wiedzy eksperckiej z zakresu rozwiązań Aruba ClearPass ACCX#901 oraz z projektowania sieci opartych o rozwiązania Aruba ACDX#1255. Więcej informacji możesz znaleźć na moich portalach społecznościowych.