Wireguard Routing Statyczny Zdalny Dostęp i Zdalne Lokalizacje to kolejne kroki konfiguracji do realizacji połączenia wielu tunelu zdalnego dostępu (Road Warrior) oraz zdalnych lokalizacji z odpowiednimi regułami routingu statycznego.
Konfigurację w formie video obejrzysz TUTAJ 🙂
1. Konieczne kroki do uruchomienia Wireguard’a:
- Stworzenie logicznego interfejsu dla tunelu Wireguard
- Przypisanie portu dla danego tunelu oraz kluczy publicznego i prywatnego
- Konfiguracja peer’a dla tunelu z przypisaniem odpowiedniego klucza publicznego
- Przypisanie dozwolonych sieci dostępnych za tunelem
- Przypisanie trasy routingu dla każdego urządzenia połączonego Wireguard’em
Konfigurację którą dzisiaj przedstawię dotyczy tylko właściwiej konfiguracji punktu 4 oraz 5 z powyższej listy kroków.
Jeżeli chcesz się dowiedzieć jak skonfigurować kroki 1,2,3, to zapraszam do poniższych 2 artykułów na ten temat:
WireGuard Site to Site VPN [konfiguracja MikroTik]
WireGuard RoadWarrior VPN [konfiguracja MikroTik]
2. Topologia
Sieć 10.253.253.0/24 w przedstawionym środowisku pełni rolę sieci WAN, na tej sieci będą uruchomione 2 tunele:
1. Interfejs WG1 – Tunel Wireguard Site-to-Site
2. Interfejs WG2 – Tunel Road Warrior (Remote Access) dla zdalnych użytkowników
Uruchomiona jest również maskarada (NAT) na interfejsie eth1 Mikrotika 1.
2. Konfiguracja klienta na Linxu’e
Pełna konfiguracja klienta Linux’a dostępna jest tutaj:
WireGuard RoadWarrior VPN [konfiguracja MikroTik]
W kontekście 4 koniecznego kroku naszej konfiguracji w moim środowisku skonfigurowałem:
wg set wg0 private-key ./privatekey peer <tu wklej klucz publiczny routera MikroTik> allowed-ips 0.0.0.0/0 endpoint 10.253.253.103:13232
Konkretnie parametr allowed-ips 0.0.0.0/0 oznacza, że pakiet do dowolnej sieci będzie zaakceptowany do wysłania przez tunel.
Tworząc konfigurację masz wybór 2 opcji gdzie będziesz ograniczał ruch przesyłany tunelem:
1. Firewall
2. Konfiguracja Interfejsu
W tym artykule pokazuję tworzenie reguł na interfejsie Wireguard’a. W przypadku klienta dostępu zdalnego, nie ograniczyłem dostępu do sieci na Mikrotik’ach, żeby pokazać jak zaplanować wpisy routing’u.
Czyli prawidłowo podłączony klient będzie mógł wysłać pakiet do dowolnej sieci.
Teraz konieczne trasy routingu:
W moim przykładzie dodam 2 trasy dla 2 dostępnych sieci po stronie Mikrotik 1 i Mikrotik2:route add -net 10.0.20.0/24 gw 10.255.254.1route add -net 10.0.10.0/24 gw 10.255.254.1
Opcjonalnie możesz usunąć istniejącą trasę domyślną i dodać nową kierującą na adres tunelu Mikrotika1:route del default gw 10.253.253.254 ens3 && route add default gw 10.255.254.1 wg0
Przy dodawaniu specyficznych sieci wybierasz tryb Split-Tunnel, czyli przez tunel będziesz osiągał jedynie sieci zdalne w centrali i zdalnych lokalizacjach. Przy korzystaniu z internetu będziesz używał lokalnego łącza, w ten sposób nie obciążasz centralnych zasobów przeglądając YouTube’a.
Jeżeli jednak chcesz na firewall’u centralnym w firmie kontrolować ruch użytkowników zdalnych, w takim przypadku powinieneś wybrać opcję kierowania ruchu jako trasy domyślnej do tunelu Wireguard.
3. Konfiguracja Mikrotik 1
Pełna konfiguracja Mikrotika 1 dostępna jest tutaj:
WireGuard RoadWarrior VPN [konfiguracja MikroTik]
WireGuard Site to Site VPN [konfiguracja MikroTik]
W tym punkcie pokażę tylko jak zmodyfikowałem konfigurację Mikrotika 1 żeby dostosować konfigurację do topologii 2 tuneli. Poniższa konfiguracja dotyczy punktu 4 oraz 5 koniecznych kroków.
3.1 Wireguard Peers
WG1 jest interfejsem dla tunelu Site-to-Site z Mikrotikiem2, w związku z tym na Mikrotiku 1 dopuszczam sieć LAN na Mikrotiku 2 (10.0.20.0/24) oraz sieć 10.255.255.2/32.
Druga sieć służy mi do sprawdzania komunikacji, nie jest potrzebna do połączenia klientów z sieciami zdalnymi.
Na interfejsie WG2 służącym do terminowania użytkowników zdalnych dopuszczam sieć w której otrzymują adresu użytkownicy Road Warrior.
Jak widzisz na powyższych obrazkach dopuszczone sieci dla każdego z interfejsów Wireguard się różnią się i powinny być dobrze przemyślane.
3.2 Routing
Tablica Routingu na Mikrotiku 1 przedstawia się następująco:
Zauważ że część sieci jest już w tablicy routingu jako DAC, czyli dynamiczne wpisy w tablicy routingu, przykładem jest sieci 10.0.10.0/24
Wynika to z posiadania interfejsu w sieciach automatycznie dopisanych do tablicy routingu. Sieć 10.0.10.0/24 jest siecią lokalną w której Mikrotik 1 posiada interfejs LAN i przez ten interfejs będzie wysyłał pakiety do wspomnianej sieci.
Inaczej ma się sytuacja z siecią 10.0.20.0/24 ta sieć została dodana manualnie jako statyczna trasa przeze mnie i wskazany interfejs tunelu wg1 do wysyłania pakietów adresowanych do tej sieci.
4. Konfiguracja Mikrotik 2
Pełna konfiguracja Mikrotika 2 dostępna jest tutaj:
WireGuard RoadWarrior VPN [konfiguracja MikroTik]
WireGuard Site to Site VPN [konfiguracja MikroTik]
Podobnie jak w przypadku Mikrotika 1, wymagane są tylko pewne modyfikacje punktów 4 i 5 koniecznych kroków
4.1 Wireguard Peer
W przypadku Mikrotik 2 jest tylko jeden peer, czyli Mikrotik 1
Dla tego routera dodałem do wcześniej istniejących sieci jedną dodatkową, sieć 10.255.254.0.24, jest to sieć w której otrzymują adresy klienci zdalnego dostępu.
Dzięki temu pakiety kierowane do linuxa w mojej topologii są akceptowane w połączeniu tunelowym Wireguard’a.
Oprócz tego wpisane są jeszcze:
1. Sieć LAN Mikrotik 1 – 10.0.10.0/24
2.Sieć połączeniowa tunelu Site-to-Site – 10.255.255.1/32 służąca tylko do celów diagnostycznych
4.2 Routing
W przypadku Mikrotika 2 dodatkowo wymagana była tylko trasa prowadząca do sieci dla klientów zdalnych, w moim przypadku klient linux:
Zwróć uwagę że w tym przypadku wpisałem adres IP bramy, a nie nazwę interfejsu. Jest to alternatywny sposób tworzenia wpisów w tablicy routingu.
Podsumowanie
Konfiguracja zdalnego dostępu użytkowników oraz łączenia lokalizacji nie różni się znacznie, jedyna różnica to w przypadku użytkowników nie definiujemy zdalnego publicznego adresu IP.
Pozostała część komunikacji jest taka sama.
To co trzeba wykonać żeby uruchomić środowisko łączące różne typy dostępu, to odpowiednio zezwolić wymaganym sieciom na dostęp do tuneli, oraz przypisać trasy routingu.
Opisany statyczny routing może się sprawdzić w przypadku uczenia się koncepcji i topologii kilku sieci, jednak przy większym środowisku wymagany będzie routing dynamiczny.
Na dzień konfigurowania dostępnej funkcjonalności Wireguard’a na Mikrotiku, nie wydaje się sensowne stosowanie tej funkcjonalności na większą skalę, z powodu braku narzędzi, przede wszystkim konfiguracji tras dla klientów zdalnych.
Dla przykładu w OpenVPN’e jest możliwość konfiguracji od strony serwera tras routingu na klientach, to jest podstawowa funkcjonalność przy większej liczbie klientów zdalnych.
Jeżeli masz jakieś pytania do artykułu :Wireguard Routing Statyczny Zdalny Dostęp i Zdalne Lokalizacje, to napisz w komentarzu. Jestem ciekaw Twojej opinii.
