22T38 Wireguard Łączenie Site-to-Site z Road Warriorr [konfiguracja Mikrotik]
Wireguard Road Warrior Site-to-Site Static Routing
Więcej miejsc do posłuchania:
Link do artykułu.
Transkrypcja
Cześć. Chciałbyś się dowiedzieć jak łączyć konfigurację zdalnego dostępu i Wireguard Site-to-Site. Jeżeli tak, to w tym odcinku pokażę jak to zrobić a odrazu powiem, że mi to nie zadziałało odrazu.
Zacznijmy od topologii. Czyli mamy tutaj tą samą architekturę, którą omawialiśmy w poprzednim odcinku ale dla przypomnienia: mamy tutaj system Linuxowy, który jest klientem w dostępie zdalnym. On się łączy przez tunel Wireguarda, do interfejsu publicznego eth1 na MikroTiku 1 i tworzy sobie to połączenie z interfejsem logicznym na MikroTiku 1 – WG2. Oprócz tego mamy połączenie pomiędzy MikroTikiem 1 a 2 i tu interfejsy logiczne z jednej i drugiej strony nazywają się WG1. Natomiast całość wspomniana łączy się przez moją sieć VAN i ta sieć VAN to jest adresacja 10.253.253.0 z maską 24 bity. Teraz jeżeli chodzi o test, jaki będę przeprowadzał to zapinguję z tego systemu Linux-owego poszczególne hosty w dwóch lokalizacjach, czyli lokalizacja pierwsza – MikroTik1 to będzie VPC11 i to jest sieć 10.0.10.0 z maską 24 bity a host ma końcówkę 11 w tej sieci. Po prawej stronie mamy LAN podłączony do MikroTika2. Adresacja 10.0.20, maska 24 bity i VPC22 z końcówką 22. Jeżeli nam ping będzie prawidłowo działał z oboma hostami tzn. że cały koncept tych tuneli i routingu działa właściwie. To sprawdźmy najpierw czy fingujemy ze strony Linuxa odpowiednie systemy. Najpierw LAN pierwszy 10.0.10.11. Ping prawidłowo przechodzi czyli tunel jest zestawiony i routing również jest zestawiony. No to zobaczmy teraz hosta VPC22 czyli 20 i końcówka 22 i również nam przechodzi ruch z naszego hosta Linuxowego.
To teraz zobaczmy jaka jest konfiguracja na tym kliencie, czyli najpierw zobaczmy wg show. Mamy tutaj zdefiniowany tradycyjnie jak to jest dla WIreguarda – zobaczysz to samo na poszczególnych MikroTikach – interfejs logiczny najpierw, który jest powiązany oczywiście z kluczem publicznym i prywatnym i oprócz tego definicja peer’a do którego się łączy. Adres IP to jest adres IP interfejsu VAN, który mamy jak wspomniałem w sieci 10.253.253.0 z maską 24 bity. Łączymy się do MikroTika1, czyli on ma adres z końcówką 103. Na porcie 13.232. Jeżeli chodzi o definicję dopuszczonych sieci to możemy tutaj, czy ten system będzie akceptował pakiety dla tego tunelu, dla wszystkich sieci i wtedy definiujesz to właśnie w ten sposób 10.0.0.0 z maską 0 i nic tu więcej jeżeli chodzi o samą konfigurację Wireguarda nie ma. To co jeszcze tutaj będziemy sprawdzać ale to za chwilę to routing. Narazie jednak przejrzymy konfigurację dla poszczególnych komponentów. Czyli omówiony mamy Linux, teraz przejdźmy do MikroTika1 i sprawdźmy jego konfigurację dla Wireguarda. MikroTik1, konfiguracja Wireguarda, mamy najpierw w zakładce Wireguard zdefiniowane dwa logiczne interfejsy. W samych interfejsach nie ma nic szczególnego. Mamy nazwę tego interfejsu, mamy MTU – ono oczywiście powinno być odpowiednio mniejsze, bo jak nakładamy tunel to żeby się mieściło nam w typowej ramce ethernetowej. Mamy tutaj numer portu na którym nasłuchuje ten proces czy ta usługa. Klucz prywatny, klucz publiczny i nic tu więcej w zasadzie nie ma oprócz statystyk w samej definicji interfejsu.
Podobnie jest dla interfejsu WG2, tutaj również nie mamy nic więcej oprócz wcześniej omówionych parametrów. Bardziej istotne i ciekawsze są parametry w zak≥ładne peers. Czyli przełączamy się na peers i tutaj mamy zdefiniowany. Przypomnę, że WG1 to jest nasz Site-to-Site. Czyli mamy tu oczywiście podstawowe informacje już pokazane. Czyli klucz publiczny tego peera, czyli tej naszej drugiej strony tego tunelu, mamy zdefiniowany adres IP naszego sąsiada z którym ten tunel będziemy spinać, jaki port będziemy używać i jakie sieci są dozwolone przez ten tunel. Jeżeli chcemy w szczegółach zobaczyć to możemy otworzyć. Te same informacje w innej troszeczkę formie. To co tutaj jest ważne do sprawdzenia to czy dopuszczone sieci i adresy są zgodne z naszą koncepcją sieci. Teraz jeżeli chodzi o sieć 10.0.20.0 z maską 24 bity, przypomnę, że jesteśmy na MikroTiku 1 – to, to jest sieć, która jest LAN-em na MikroTiku 2, czyli mówimy, że jeżeli przyjdzie pakiet do MikroTIka 1 i wg routingu powinien ten pakiet być skierowany do tunelu Wireguarda Site-to-Site to o ile on dotyczy sieci 10.0.20.0 z maską 24 bity to zostanie ten pakiet przesłany. Jeżeli tej sieci, w tym miejscu odpowiednio nie zidentyfikujesz, nie powiesz jakie są dostępne przez ten tunel te sieci to pakiet zostanie odrzucony. I druga sieć, którą tutaj widzisz to jest definicja sieci WIreguarda, czyli jeżeli bym chciał pingować interfejs WIreguardowy na Mikrotiku 2 to muszę tutaj tą definicję zadać. Ja to robiłem pod kontem testowania połączenia przygotowując to całe środowisko i dlatego tą sieć dodałem. Jeżeli nie potrzebujesz pingować sobie sieci połączeniowej, tego wpisu nie musisz robić. I to jest tyle, nic tutaj więcej w samej konfiguracji peera nie ma. Jeżeli chodzi o WG2 – tu przypomnę, że WG2 to jest ten remote access. Czyli ten Linux podłączony. To w zasadzie jedyna różnica jest taka, że nie definiuje tutaj end pointa, czyli jeżeli mówimy o zdalnym dostępie, to mamy świadomość tego, że adresy publiczne IP systemów, które będą używać tego Wireguarda jako zdalnego dostępu będą się zmieniać. W związku z tym nie ma co tu w konfiguracji na MikroTiku 1 ograniczać adresów peerów ponieważ one będą dynamiczne i nie jesteśmy w stanie ich zidentyfikować wcześniej. Jeżeli chodzi o dostępne sieci, które mam tutaj zdefiniowane, no to mówię, że przez ten tunel będą możliwe do przesłania pakiety dla sieci 10.255.254.0 z maską 24 bity. To jest sieć, która służy do połączenia Linuxa i innych systemów zdalnych z moim MikroTikiem 1. Dla tego tunelu muszę zadefiniować taką adresację, dla pakietów które mają być od wewnątrz, czyli od LAN-u pierwszego, czy od LAN-u drugiego wysyłane do Linuxa. Dlatego jest taka definicja tutaj tej sieci. To mamy omówiona konfigurację WireGuarda na MikroTiku 1.
Na MikroTiku 2 podobna konfiguracja dla WG1. Nic tutaj specjalnie na samym interfejsie logicznym się nie zmienia. Jeżeli chodzi o peery jest analogiczna konfiguracja. Zmienia się tylko end point, czyli wskazujemy adres publiczny IP. Przypominam, że 10.253.253.0 z maską 24 bity to jest u mnie VAN i definiujemy tego end pointa, który będzie podłączony do tego routera. Oprócz tego tutaj zdefiniowałem troszeczkę inne sieci i już Ci wytłumaczę dlaczego. Oczywiście muszę tutaj powiedzieć, że sieć dla MikroTika 1 dostępna przez tunel Site to Site to jest sieć 10.0.10.0 z maską 24 bity. Oprócz tego wskazałem sieć połączeniową tak jak poprzednio do moich testów, które prowadziłem. Czyli to jest adres MikroTika 1 interfejsu IP i tego tunelu Site – to – SIte i na końcu mam definicję adresu sieci dla systemu, którym jest Linux. To po to, żebym mógł tam sobie również pakiety wysyłać do tego systemu Linuxowego. Ta cała idea tego odcinka i tej konfiguracji to jest połączenie tych dwóch typów dostępu i dwóch różnych tuneli, tak żeby wszystko ze sobą się łączyło. Więc to jest tyle jeżeli chodzi o konfiguracje. Wydaje mi się, że tutaj jest w miarę oczywista ale jeżeli będziesz miał do tego pytania to pisz śmiało w komentarzu. Czyli omówiliśmy sobie konfigurację Wireguarda na Linuxie, na MikroTiku 1 i na MikroTiku 2. Czyli wszystkie te logiczne interfejsy WG1, WG2 na poszczególnych urządzeniach
Teraz możemy przejść do konfiguracji dotyczącej routingu. Jeżeli chodzi o routing no to możemy też zacząć od omówienia Linuxa. Zobaczmy jak routing został zdefiniowany na Linuxie. Mamy tutaj taką konfigurację klienta. Jakbyś chciał zrobić Split Tunneling. Czyli definiujemy tylko konkretne sieci, które mają być dostępne za danym tunelem. W moim przypadku w tej naszej architekturze to będzie sieć 10.0..20.0 i sieć 10.0.10.0. Obie te sieci mają wskazanego Gate waya 10.255.254.1, czyli jest to Gate way na MikroTiku 1. Czyli WG2 interfejs logiczny jest wskazany jako Gate way dla obu sieci. Sieć 10.0.10.0 z maską 24 bity i 10.0.20.0 z maską 24 bity. To jest wystarczająca konfiguracja do tego, żeby skierować wszystkie pakiety, które idą do sieci lokalnych MikroTika 1 i 2 przez tunel. Jeżeli tym chciał coś innego jeszcze tam pingować np interfejs WG1 na MikroTiku 2 to tutaj dodatkowo w tym Linuxie musiałbym trasę dla tego interfejsu dodać. Alternatywnie mógłbyś tu oczywiście zdefiniować domyślną trasę dla wszystkich pakietów dla Gate waya 10.255.254.1 czyli wtedy definiowałbyś scenariusz, że cały ruch, który chcesz realizować, przesyłać dla tego hosta będzie przechodził przez tunel i będzie kierowany do MikroTika 1. Tu w zależności od tego jak chcesz wykonać swoją konfigurację. Najczęściej wykonuje się ją jednak trybie speed tunneling, czyli tutaj do tego, do tej konfiguracji tablicy routingu jeszcze powinna być definicja domyślnej trasy, która kieruje na Gatewaya WAN-owego. W moim przypadku byłby to adres 10.253.253.254 czyli w tej sieci Gateway.
Przejdźmy dalej. Mamy omówiony routing na Linuxie, teraz routing na MikroTiku 1. Tu zwróć uwagę jakie sieci chcemy osiągnąć. Na pewno chcemy wskazać trasę dla Linuxa – czyli tą – i na pewno tą czyli czyli tą po drugiej stronie tego tunel logicznego i chcemy oczywiście wskazać LAN dla MikroTika 2. Czyli sieć 10.0.20.0 z maską 24 bity. No to zobaczmy na MikroTika 1 i patrzymy na routing, tablicę routingu. Chyba się trzeba ponownie zalogować. Widzimy tablicę routingu na MikroTiku 1. To co mamy tutaj zdefiniowane to domyślna trasa na WAN-ie, ponieważ tu statycznie został przypisany adres IP na WAN-ie to statycznie jest trasa domyślna do internetu wpisana. Ona nas mniej tutaj interesuje natomiast dalej są rzeczy, które nas interesują jak najbardziej. Czyli sieć lokalna, która jest podpięta do MikroTika 1, czyli 10.0.10.0 z maską 24 bity, dostępna przez interfejs LAN. No oczywiście MikroTik 1 o niej wie ponieważ jest bezpośrednio ta sieć do niego podłączona. Mamy statycznie zdefiniowaną sieć 10.20.0 i wskazującą na interfejs WG1. Czyli sieć LAN która jest po stronie MikroTika 2 jest skonfigurowana w taki sposób, że router wszystkie pakiety które do tej sieci są kierowane będzie wysyłał przez swój interfejs WG1. WG1 przypomnę to jest interfejs logiczny dla tunelu Site-to-Site. Mamy tutaj jeszcze oczywiście maskę sieci WAN-owej. Ona też nas tutaj mniej interesuje, tutaj w tym przypadku dynamiczna. Mamy tutaj maskę dla sieci 10.255.254.0, 24. To jest sieć dla połączeń Remote Access. Czyli dla wszystkich hostów, które byśmy chcieli podłączać przez Wireguarda do MikroTIka 1, to ta tablica routingu będzie nam umożliwiała. I co tu mamy jeszcze. Mamy tutaj jeszcze sieć 10.255.255.0 z maską 30 i to jest sieć połączeniowa tunelu Site-to-Site dla naszego połączenia między MikroTikiem 1 a MikroTikiem 2. No i to jest cała tablica routingu, która jest potrzebna do tego, żeby wszystkie sieci działały pomiędzy hostami, które wcześniej omówiliśmy.
Teraz możemy przejść do MikroTika 2 i zobaczyć jak tutaj będzie wyglądała tablica routingu. Też ponownie się trzeba zalogować. No i mamy tak: domyślną trasę dla WAN-u, ona jest mało dla nas istotna. Mamy zdefiniowaną statycznie sieć LAN dla MikroTika 1 przez interfejs WG1, mamy tutaj lokalną sieć na MikroTiku 2 przez interfejs LAN. Mamy tutaj sieć WAN-owską w maską 24 bity bo mamy WAN podłączony i tak jak poprzednio 10.255.254.0 tj. sieć, która jest powiązana z dostępem zdalnym, czyli ten Linux wspomniany jest podłączony właśnie w tej sieci. I kierujemy na Gate waya 10.255.255.1. Tu zadefiniowałem w inny troszeczkę sposób Gate waya jak widzisz bo wcześniej był wskazany interfejs, tutaj zdefiniowałem adres IP i jak sobie zobaczysz ten adres IP jest bezpośrednio tłumaczony na interfejs. Czyli 10.255.255.1. To jest ten interfejs WG1. Czyli wszystkie pakiety, które idą z VPC 22 i będą dotyczyły sieci tutaj Linuxowej, czyli tej 10.255.254.0 z maską 24 bity będą wysyłane na ten interfejs jako Gate waya. No i to jest wszystko jeżeli chodzi o konfigurację routingu. Czyli jeżeli chodzi o skonfigurowanie całości tej topologii to pamiętaj, że najpierw trzeba zadefiniować wszystkie interfejsy dla Wireguarda czy remote access Site-to-Site, następnie trzeba skonfigurować wszystkie sieci, które są dozwolone dla poszczególnych tuneli od każdej ze stron i następnie trzeba skonfigurować routing, który tutaj akurat w tym przykładzie był routingiem statycznym.
Planuje też zrobić taki odcinek, pokazujący jak routing dynamiczny można skonfigurować właśnie w takiej topologii wielu tuneli i poszczególnych sieci, które są zdalnie dostępne przez logiczne interfejsy. Jeżeli będziesz miał jakieś pytania do tego to oczywiście pisz w komentarzu. W tym odcinku to tyle, jeżeli masz jakieś pytania co do tej konfiguracji to zachęcam Cię napisz w komentarzu. Za dzisiaj Ci dziękuje za uwagę i do zobaczenia już za tydzień.