|||

WireGuard RoadWarrior VPN [konfiguracja MikroTik]

Schemat połączeniowy VPN typu Site to Site i klienta (Linux) w RoadWarrior

W tym artykule pokażę, jak skonfigurować połączenie VPN między routerem MikroTik i urządzeniem klienckim z WireGuard. Przedstawione połączenie RoadWarrior spotykane jest w scenariuszach, w których chcemy wykorzystać IP domowe w miejscach publicznych, dla częściowej ochrony prywatności.

Konfigurację w formie video obejrzysz TUTAJ 🙂

Jak działają sieci RoadWarrior

Ogólnym założeniem sieci VPN RoadWarrior jest ochrona prywatności poprzez przedstawianie się w Internecie lokalizacją domową niezależnie od lokalizacji fizycznej. Dodatkowo komunikacja między urządzeniem klienckim a siecią domową jest stale szyfrowana co w praktyce uniemożliwia podsłuchanie ruchu. Sposób działania jest podobny do sieci Site to Site, z tą różnicą, że do tunelu kierujemy cały ruch, a nie tylko sieci lokalne.

Konfiguracja routera

Tworzenie interfejsu WireGuard

  1. Połącz się z routerem MikroTik wykorzystując WinBox.
  2. Utwórz konfigurację interfejsu WireGuard wybierając z menu bocznego WireGuard.
  3. W wyświetlonym oknie pozostając na karcie WireGuard naciśnij znak Ikona MikroTik Add.
  4. W razie potrzeby zmień nazwę dla interfejsu i port nasłuchiwania.
  5. Naciśnij OK.

Konfiguracja Peera

  1. Przejdź do zakładki Peers i naciśnij ikonę Ikona MikroTik Add
  2. W wyświetlonym oknie wskaż:
    – interfejs WireGuard
    – klucz publiczny klienta (znajdziesz go w szczegółach konfiguracji WireGuard)
    – dozwolone adresy (adres IP klienta z maską 32-bitową używany w komunikacji WireGuard)
  3. Naciśnij OK.
Przykładowy sposób na skopiowanie klucza publicznego.
Konfiguracja Peera na MikroTiku

Konfiguracja adresu IP

  1. Przejdź do menu IP > Addresses.
  2. Naciśnij ikonę Ikona MikroTik Add.
  3. Wypełnij formularz według wzoru i naciśnij OK.

Konfiguracja klienta

WireGuard działa na wielu platformach. W większości przypadków konfiguracja sprowadza się do podania klucza publicznego routera, adresu IP i portu nasłuchiwania routera oraz wygenerowania kluczy klienta i przesłania klucza publicznego dla administratora serwera WireGuard (w tym przypadku routera), aby wpisał go w konfiguracji peera. Pokażę, jak zestawić takie połączenie na linuksie.

Konfiguracja klienta WireGuard na Ubuntu

  1. Uruchom terminal lub połącz się z urządzeniem docelowym przez SSH.
  2. Zainstaluj WireGuard poleceniem apt install wireguard -y.
  3. Utwórz wirtualny interfejs WireGuarda poleceniem ip link add dev wg0 type wireguard.
  4. Dodaj konfigurację dla utworzonego interfejsu poleceniem ip address add dev wg0 10.255.254.2 peer 10.255.254.1.
  5. Zmodyfikuj maskę atrybucji dla nowo tworzonych plików poleceniem umask 077.
  6. Wygeneruj klucz prywatny i zapisz go do pliku poleceniem wg genkey > privatekey.
  7. Wygeneruj klucz publiczny z klucza prywatnego poleceniem wg pubkey < privatekey > publickey.
  8. Wyświetl klucz publiczny poleceniem cat publickey i wklej go do konfiguracji peera na MikroTiku.
  9. Skonfiguruj połączenie WireGuard poleceniem 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.
  10. Podnieś interfejs i zestaw połączenie poleceniem ip link set up dev wg0.
  11. Poleceniem wg show możesz sprawdzić stan konfiguracji WireGuarda.
  12. (Opcjonalnie) Zmień trasę domyślną kierując ruch z interfejsu fizycznego do tunelu WireGuard poleceniem route del default gw 10.253.253.254 ens3 && route add default gw 10.255.254.1 wg0

Protip

Polecenie z punktu 11 możesz dodać do skryptu zestawiającego połączenie WireGuard, dzięki temu nie będziesz musiał po każdym ustanowieniu połączenia zmieniać trasy domyślnej, aby kierować cały ruch internetowy przez tunel.

Test konfiguracji

Poleceniem ping 10.255.254.1 przetestuję działanie komunikacji z routerem wykorzystując tunel WireGuard.

Router MikroTik odpowiada na ping

Podobne wpisy

12 komentarzy

    1. Faktycznie, zapomniałem wspomnieć o dodaniu reguły zezwalającej na ruch przychodzący na porcie 13232 UDP dla interfejsu wg2. Otwiera się go tak jak w konfiguracji site to site.
      Jeśli chodzi o routing (trasę domyślną) to jest wymagany po stronie klienckiej, jeśli chcemy, aby cały ruch był kierowany przez tunel. Tutaj pokazałem tylko zestawienie takiego połączenia z routerem.
      Zaktualizuję artykuł o te informacje i dzięki za zwrócenie uwagi na te elementy. Dodam, że testowe środowisko się zestawiło, bo nie było reguły, która blokuje cały ruch.

      1. Byłbym wniebowzięty zobaczyć taką konfigurację z kilkoma interfejsami. Np. pierwszy interfejs „wg1” na routterze pierwszym i drugim jako połączenie site-to-site (adresy np. 192.168.6.1-2) oraz druki interfejs „wg2” do połączeń z zewnętrznej sieci np z telefonu czy laptopa ( adresacja dla site A 192.168.61.0/24 i dla site B 192.168.62.0/24). Dzięki temu Site A i B widzą się zawsze i z doskoku laptopem czy tel. można się podłączyć do site A lub siteB. Taki artykuł to byłby petarda. Dodatkowo IP Routy i Firewall ustawienia.

      2. Muszę powiedzieć że popełniłem taką konfigurację na fizycznych MT i niestety nie działa to. Jak tunel się zestawia i obie strony odpowiadają na pingi to komputery po drugiej stronie już nie odpowiadają. Nawet jak dodałem rulke Allow ALL 😀

        1. Zmieniłeś bramę domyślną na urządzeniu, które ma się łączyć w trybie RoadWarrior? Z punktu widzenia klienta są to nieznane adresy i w zależności czy chcesz kierować cały ruch przez tunel czy tylko korzystać z niego tylko w celu uzyskania dostępu do sieci lokalnej to musisz zmienić bramę domyślną lub dodać trasy do routingu z definicją adresacji za routerem.
          Zaktualizowałem artykuł o polecenie zmiany bramy domyślnej i udało mi się pingnąć komputer za routerem.

          1. Komentowałeś pod RoadWarrior, dlatego myślałem, że o nim mowa. Jeśli robiłeś wszystko zgodnie z artykułem http://netadminpro.pl/wireguard-site-to-site-vpn-konfiguracja-mikrotik/ to powinno działać, bo routing między sieciami jest konfigurowany bezpośrednio na routerach. Jeśli nie testowałeś tego lokalnie tylko między zdalnymi lokalizacjami to upewnij się, że Twój ISP nie blokuje ruchu przychodzącego niezainicjowanego przez Twoją sieć. Zwróć uwagę, że przy konfiguracji Site to Site każda ze stron niezależnie inicjuje połączenie.

          2. A wybacz bo juz sie zgubiłem szukam wszedzie odpowiedzi 😀

            Jak „upewnij się, że Twój ISP nie blokuje ruchu przychodzącego niezainicjowanego” ?

          3. To w takim przypadku kiedy jest closed lepiej użyć innego portu albo każdym MT łączyć się do serwera który ma wszystko odblokowane.

          4. Skoro masz closed, to najprawdopodobniej na każdym porcie będziesz tak miał, bo na 99% nie masz tzw. publicznego IP (dozwolonego wejścia ze świata). Najtaniej byłoby postawić serwer WireGuard na tanim VPSie i tak jak wspominałeś łączyć się routerami z tym serwerem. Niestety w przypadku WireGuarda nie jest tak łatwo. Jak mogłeś zauważyć, to komunikacja odbywa się z wykorzystaniem protokołu UDP. Dzięki temu komunikacja jest szybka, ale niestety ma to swoją cenę, bo w przeciwieństwie do TCP sesja nie jest podtrzymywana, więc zestawienie połączenia ze zdalnym serwerem nie rozwiąże problemu, bo on też by musiał inicjować połączenie z drugim sitem. Ten problem i potencjalne rozwiązanie masz opisany na stronie WireGuarda w sekcji TCP Mode https://www.wireguard.com/known-limitations/

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *