VPN: WireGuard & MikroTik
Konfiguracja zdalnego dostępu do sieci lokalnej.

 Połączenie zdalne klienta z siecią lokalną można zrealizować w ramach technologii VPN (Virtual Private Network) na wiele sposobów. Jednym z nowszych metod jest projekt WireGuard, który ma też dodatkową zaletę, że jest od wersji 7 os-a Mikrotika bezpośrednio w nim zaimplentowany. Co samo w sobie abstrachując od wielu zalet przedstawionych poniżej jest nie małym wyróżnieniem dla twórców tego projektu. WireGuard charakteryzuje się:

  • małym obciążęniem procesora
  • wysoką wydajnością, a co za tym idzie szybkim zestawianiem połączeń
  • silne szyfrowanie z dodatkową opcją utrudnienia kwantowej deszyfracji (ChCha20, Curve25519)  
  • łatwości wdrożenia (brak rozróżnienia stron serwer <-> klient)
  • możliwość sterowania ruchem pakietów (w efekcie końcowym "klient" nie obciąża nam wszystkimi swoimi pakietami głównego łącza "serwera", a jedynie wybranym przez nas określonym IP, zakresem IP, grupą IP itd.) Przy czym konfiguracja po stronie klienta o tym decyduje (Client Allowed Address)
  • porty na których są zestwaine połączenia VPN generują się automatycznie lub dowolnie je wybieramy w zakresie do 65535. Dodatkowo nie ujawniają się podczas skanowania portów. Więc zwiększa to radykalnie bezpieczeństwo przez utradnienie chociażby zwykłego siłowego ataku, ataków typu DDoS itd.

    Poniżej przedstawiam schemat ideowy praktycznego zastosowania szyfrowanego kanału VPN w internecie łączącego ze sobą router oraz mobilną stację roboczą (smartfon). Router MikroTika ma następującą konfigurację sieciową WAN IP= 1.2.3.4, LAN IP = 172.30.30.1/30, VPN IP = 172.30.31.209/30, a zdalnej stacji roboczej (smartfona) bedącej podłączonej do internetu z dynamicznie nadawanym zewnetrznym numerem IP WAN = 6.7.8.9 oraz nadanym na stałe przez nas numer IP VPN-a = 172.30.31.210/30.


 Konfigurację routera MikroTik-a zaczynamy od stworzenia interfejsów VLAN, których ilość wynika z urządzeń jednocześnie łaczących się z nim wypisując w terminalu komendę(y):

        /interface/wireguard/add listen-port=12345 name=wg_1 mtu=1300 comment="VPN test 1"


oraz po wybraniu Apply zostaną uzupełnione automatycznie klucze Private Key i Public Key.


Wartości nastepujących pól:

  • listen-port jest dowolną cyfrą z zakresu od 1024 do 65535 (cyfra szesnastobitowa, liczona od zera z wyłaczeniem pierwszych 1024 portów zarezerwowanych dla systemu operacyjnego), name (wg_1) to dowolna nazwa interefejsu sieciowego,
  • comment to dowolny komentarz (VPN test 1), 
  • MTU (Maximum Transmission Unit) domyślnie przez WireGuard ustawiony jest na 1420 bajtów choć dla protokołu Ethernet za standardową wartość przyjmuje się 1500 bajtów, ale maksymalnie jest w stanie pomieścić 64 [KB]. Ja wpisałem liczbę 1300, która dla połaczeń mobilnych opartych o sieć GSM może się okazać wręcz konieczna. Poznamy to miedzy innymi po pojawiających się w logach komunikatach typu:

        "Handshake for peer did not complete after 5 seconds, retrying"

Możemy wylistować stworzone kanały WireGuard poleceniem:

        /interface/wireguard/print

    W kolejnym kroku ustawiamy adres IP wraz z maską oraz siecią dla naszego połączenia wg_1 komendą:

        /ip/address add address=172.30.31.209/30 interface=wg_1 comment="WireGuard 1"


gdzie pod adresem IP 172.30.31.209/30 kryje się brama wraz z maską naszej podsieci 172.30.31.208. Jeśli klientem z IP 172.30.31.210 co wynika z wcześniejszej maski sieci (30) łącza VPN wg_1 będzie router z podsiecią komputerów, np. 10.1.202.0/24 to jest to dobry moment by dodać ją do tablicy routingu, np. komendą w postaci:

        /ip/route add dst-address=10.1.202.0/24 gateway=wg_1

    Pierwotnie w tym miejscu artykułu zaczynała się konfiguracja zapory routera Mikrotika. Jednak ze względu na to, że aktywowanie połaczenia (Network Manger pod UBUNTU, apliakcji WireGurad pod Androidem) po stronie klienta w większości przypadków kończy się sukcesem bez względu na faktyczny jego stan, zdecydywołem się na odwrócenie logiki by móc na bieżaco kontrolować sytuację. Czasami może się okazać, że prościej było wszystko od poczatku skonfigurować niż walczyć z jednym logicznym błędem, którego popełnienia dopuściliśmy się na samym początku. Podsumowując, ikonę symbolizującą stan połączenia traktuję jedynie, jako uruchomienie progrmu WireGuard, a nie faktyczny przepływ pakietów tak, jak sobie to zaplanowaliśmy. Mamy dwie drogi konfiguracji klienta. Pierwsza według mnie nie tyle trudniejsza, ile zwiększająca prawdopodobieństwo utraty (zmarnowania) czasu. Polega ona na pobraniu wcześniej wygenerowanego automatycznie klucza prywatnego i publicznego (Public Key) dla interejsu wg_1 routera i wpisaniu go do konfiguracji klienta oraz wykorzystując pozostałe dane połączenia, a także analogicznie generując klucz prywatny i publiczny dla klienta. Po czym z wygenerowanym kluczem publicznym klienta wracamy do routera Mikrotika i w następnej zakładce konfiguratora WireGuard PEERS wykorzystujemy ją wraz z dodatkowymi danymi charakterystycznymi dla klienta, np. IP klienta, maska sieci, DNS, zakres dozwolonych adresów IP klienta, adres IP bramy, adres serwera WireGuard itd. W tej chwili ktoś może mi zarzucić, że posługuję się sformułowaniem klient oraz serwer łącza VPN, gdy tymczasem w projektcie WireGuard nie ma takiego rozróżnienia. Jednak ze względu na prostotę i jednoznaczność moich słów zignoruje ten zarzut. Drugie podejście w stworzeniu parametrów połaczenia dla klienta polega na konfiguracji kanału VPN przez router MikroTika dla obu końców VPN-a i w następnym kroku zaimportowanie gotowej konfiguracji do klienta WireGuarda. Może to się odbyć na drodze pliku, kodu kreskowego, czy też ostatecznie ręcznego przepisania. Czyli tworzymy automatycznie klucze prywatne i publiczne w jednym miejscu. Dzięki temu sam MikroTik zadba o ich prawidłowe wzajemne przyporządkowanie, skopiowanie. Wystarczy wybrać opcję "auto". Więc wykonujemy komendę:

        /interface/wireguard/peers/add name=peer_wg_1 interface=wg_1 private-key=auto allowed-address=0.0.0.0/0 responder=yes client-address=172.30.31.210 client-dns=1.1.1.1 client-endpoint=1.2.3.4 client-allowed-address=0.0.0.0/0

lub przy pomocy WinBox w menu WireGuard wybieramy zakładkę PEERS i w niej wybieramy NEW:


Powyższe paremetry są mimimalnymi ustawieniami klienta, które zapewniają zestawienie połączenie VPN. 

  • Pole Name uzupełniamy dowolnymi znakami przyjaznymi dla nas. 
  • Pole Interface jest wartością, którą uzupełniami na zasadzie wyboru z wczesniej stworzonego interfejsu Wireguard i w tym przypadku jest to wg_1.
  • Na podstawie wybranego właśnie interfejsu i wybranej opcji "auto" w polu Private Key po wybraniu przycisku Apply automatycznie zostaną wygenerowane Public Key i Private Key klienta oraz pobrany Public Key serwera tu uwidoczniony, jako Client Config oraz kodzie kreskowym w sekcji [Peer].
  • Responder zaznaczamy (ptaszek) na True (Yes), gdy wiemy, że łącze nie będzie non stop zestawione. Służy to ograniczeniu zaśmiecaniu niepotrzebnymi komunikatami logów


Wygląda to na skomplikowane, ale według mnie proszę mi wierzyć, że pracownicy MikroTika staneli na wysokości zadania w stosunku do opcji ręcznego uzupełniania, które jest nadal możliwe w dowolnym polu.  

  • Allowed Address jest kolejną opcją wymagającą uzupełnienia bez, której nasze połaczenie nie będzie działać. Domyślnie pojawia się nam dowolny adres wewnętrzny klienta serwera Wireguard-a, który wynosi ::/0 . Czyli jest on w standardzie IPV6 i jeśli używamy adresacji IPV4 to proszę się nie zdziwić, że bez dodania wiersza lub zamiany ::/0 na 0.0.0.0/0 czemuś połączenie zostanie odrzucone. Dla procesora 2+2 = 4, a nie 8, czy ile trzeba. :-) W naszym przypadku by uniknąć nakładania się numeracji IP przez inne kanały VPN (Peer) oraz eksperymentowania przez końcowego użytkownika innych adresacji powinniśmy wręcz wymusić docelowy IP: 172.30.31.210/32 . 
  • Na samym dole jest analogiczna opcja zwana Client Allowed Address w która również automatycznie zawiera ::/0 . Czyli dowolną adresację najnowszego protokołu internetowego IPV6. Tu też jeśli nie zmienimy warości tego pola na dowolny adres IP4 ( 0.0.0.0/0 ) kiedy nie używamy IPV6 to zablokujemy sobie ruch pakietów tym razem po stronie klienta pomimo, że wszystki znaki na niebie wskazywałby, żę jest aktywny. Ta opcja jest więc bardzo ważna jeśli chodzi o routing pakietów po stronie klienta, gdyż możemy nią decydować także czy chcemy by cały ruch przechodził przez serwer WireGuard-a (0.0.0.0/0, ::/0), czy też wybrane sieci, adresy IP, np. 172.30.31.208/30, 192.168.1.0/24 itd., a reszta ruchu będzie szła lokalnym łączem internetowym klienta. Oszczędzamy więc łącze po drugiej stronie kanału VPN zwane przeze mnie "serwerem WireGuard". Co przy stałym, wolnym, asymetrycznym łaczu nadal dostępnym w Polsce Z oraz wielu kanałach VPN jest opcją wartą pochylenia się nad nią.
  • Client EndPoint w tym przykładzie będący adresem IP 1.2.3.4. jest serwerm Wireguard nasłuchującym na porcie 12345 pobranym automatycznie z wcześniej skonfigurowanego interfejsu wg_1.
  • Client DNS jest numerem IP 1.1.1.1 serwera rozwiązywania nazw na numery IP i odwrotnie. Przy zbyt wielu DNS-ach aplikacje klienckie WireGuard-a mogą "głupieć". Tak, jak w przypadku MTU należy to indywidualnie sprawdzić.
  • Client Address jest adresem IP 172.30.31.210/32, jaki zostanie przydzielony zdalnemu urządzeniu. Tu kolejne ostrzeżenie przy zbyt wielu kanałach, interfejsach i maskach oraz zawansowanej zaporze łatwo się pomylić (bład logiczny), a wówczas ciężko dojść czemu choć połaczenie VPN jest aktywne to nic nie działa. Dodatkową informacją w kontekście zaistnienia takiej porażki może być asymetria w liczniku odebranych (RX) i nadanych pakietów (TX) danych w stosunku 0 do rosnącej w nieskonczoność wartości po drugiej stronie (Wireguard -> Interface -> Traffic).


W ten sposób ostateczna konfiguracja klienta po skopiowaniu zawartości obszaru Client Config do pliku i późniejszym zaimportowaniu w zdalnej aplikacji WireGuard  jest gotowa do zastosowania. Po przesunięciu widocznego okna Peer poniżej (w zależności od rozdzielczości monitora może to nie byc konieczne) ukaże się nam kod QR w sekcji Client QR, który też zawiera powyższe ustawienia klienta, a co za tym może my go wykorzystać do konfiguracji bezpośrednio klienta WireGuarda w smartfonach.


Niestety, jak się okazuje standardów zapisu kodów kreskowych, czy QR jest jak rakiet w Moskwie. Nistety nie, jak w naszym kraju, a jak wszystko wskazuje na dzień pański 20 sierpnia 2026 będzie ich jeszcze mniej. To mała dygresja, którą niestety nie mogę skierwoać do premiera Tuska bo przecież chcącemu krzywda się nie dzieje. 30 % narodu wybrało to 30% ma z 100 obietnic na 100 dni. Szybko minęło te 100 dni, prawda? Przez pozstałe 1360 dni chulaj dusza piekła nie ma. Bardzo przemyślane, prawda? Wracając do świata zero jedynkowego nasz klient, a dokładnie jego czytnik kodów QR może nie obsługiwać standardu generowanego przez router MikroTika. Pozostaje nam wówczas strona internetowa obsługująca tworzenie kodów QR lub samodzielne jego wygenerowanie. Dla połączeń testowych uważam, że jest to bez znaczenia, którą drogę obierzemy. Ze względów bezpieczeństwa, jak i przystało na Zosię Samosię  jego stworzenie wykonuję sam, ale nie młotkiem i dłutem midzianym, jak twierdzą to lewusy (mafia urzędnicza) bo skoro według nich wybudowano wielką piramidę w Gisie to tym bardziej i kod kreskowy tak się da. :-)  Ja to robię zapisując skopiowaną do schowka konfigurację z sekcji Client Config do nano i zapisuję ja z rozszerzeniem .conf, np. tworzę wg_1.conf. 

    touch wg_1.conf

Teraz edytuję plik wg_1.conf dzięki nano:

    nano wg_1.conf

i wklejam ze schowka do otwartego w nano pliku dodając dla wszystkiego Enter na końcu i wychodzę Ctrl+X następnie wciskam Y i jeszcze raz Enter Po czym w terminalu wykonuję następującą komendę odwołując się do stworzonego przed chwilą pliku:

    qrencode -t ansiutf8 < wg_1.conf

W wyniku czego otrzymuje kod QR, który jest już odczytywany przez wszytkie mi znane urządzenia mobilne bez problemu.


  Teoretycznie moglibyśmy spocząć na laurach, ale nie ma lekko. Skoro tak daleko doszliśmy to wypadałoby skonfigurować ostatnim rzutem na taśmę FIREWALL-a. Odblokowujemy wybrany port (12345) dla zdalnego klienta będącego pod adresem IP: 6.7.8.9 (jeśli nie znamy adresu klienta bo jest on dynamiczny to nie uwzgledniamy go w zmiennej src-address) na firewall-u komendą:

        /ip/firewall/filter/add chain=input action=accept dst-port=12345 protocol=udp src-address=6.7.8.9


Jeśli nasza polityka polega na blokowaniu wszystkiego, na zaporze routera to musimy dodatkowo odblokować porty do usług DNS, NTP itd. na routerze (tutaj ze względu na wiekszą ilość kanałów niż jeden zastosowałem maskę sieci nie 30, a 24 dla ich objęcia), np.:

        /ip/firewall/filter/add action=accept chain=input comment="DNS allow WireGuard" src-address=172.30.31.0/24 dst-port=53 protocol=udp place-before=17


        /ip/firewall/filter/add action=accept chain=input comment="NTP allow WireGuard" src-address=172.30.31.0/24 dst-port=123 protocol=udp place-before=18


/ip/firewall/filter/add action=accept chain=output comment="DNS allow WireGuard" dst-address=172.30.31.0/24 src-port=53 protocol=udp place-before=46


/ip/firewall/filter/add action=accept chain=output comment="NTP allow WireGuard" dst-address=172.30.31.0/24 src-port=123 protocol=udp place-before=47


Konfigurację zapory kończymy dodaniem reguły FORWARD zapewniającej ruch między sieciami (WAN, LAN, VLAN itp.) umożliwiając pakietom z do sieci wewnętrznych, np.:

/ip/firewall/filter/add action=accept chain=forward comment="Wireguard forward to LAN" src-address=172.30.31.0/24 out-interface-list=LAN place-before=7


        Na deser już na luzie chciałbym wrócić do opcji Preshared Key. Wspomniałem o niej we wstępie w kontekście kwantowej deszyfracji. Możemy ją uruchomić wybierając auto. Po wygenerowaniu nowej konfiguracji klienta musimy nie zapomnieć by jeszcze raz już tą odświeżoną mu zaplikować. I to tyle, na tyle, motyle. Powodzenia.

Opracowane na podstawie:


INSERT NEXO, Rewizor, Okres obrachunkowy, Wstępnie otwarty
Odblokowanie okresu obrachunkowego przez zmianę statusu z Wstępnie (Ostatecznie) otwarty w Utworzony.