Przejdź do głównej zawartości
InstagramYouTubeFacebook

Remote Access

MikroTik IPsec site-to-site: przewodnik

Zbuduj VPN IPsec site-to-site na MikroTik: skonfiguruj peera IKEv2, proposal, policy oraz regułę omijania NAT, dzięki której tunel działa.

Podsumowanie VPN IPsec site-to-site na MikroTik szyfruje ruch między dwiema całymi sieciami — centralą i oddziałem, NOC-iem i stacją bazową — dzięki czemu hosty w każdej sieci LAN sięgają do drugiej tak, jakby była lokalna. Ten przewodnik konfiguruje oba routery na RouterOS v7: peera IKEv2, identity z kluczem współdzielonym, proposal fazy 2, policy tunelu, regułę omijania NAT, na której wykłada się większość pierwszych prób, oraz reguły firewalla i testy potwierdzające, że tunel działa.

MikroTik IPsec site-to-site VPN: dwie sieci LAN połączone szyfrowanym tunelem IKEv2 między Site A a Site B.

Czym jest VPN IPsec site-to-site na MikroTik?

VPN IPsec site-to-site na MikroTik to stały szyfrowany tunel między dwoma routerami, który łączy dwie odrębne sieci LAN w jedną routowalną sieć na warstwie 3, bez wystawiania przez którykolwiek router portu zarządzania do publicznego internetu. W odróżnieniu od VPN-ów dostępowych, takich jak WireGuard czy OpenVPN — gdzie łączy się pojedyncze urządzenie administratora — tunel site-to-site działa bez przerwy i łączy podsieć z podsiecią: każdy host za routerem A automatycznie sięga do każdego dozwolonego hosta za routerem B. IPsec jest tu właściwym narzędziem, bo to otwarty standard obsługiwany praktycznie przez każdego producenta firewalli i routerów, działa w jądrze RouterOS, zapewniając dobrą przepustowość, a na MikroTik jest wbudowany — bez dodatkowych pakietów do instalacji.

Tunel powstaje w dwóch negocjacjach. Faza 1 (IKE) uwierzytelnia routery wobec siebie i zestawia bezpieczny kanał; faza 2 (IPsec) negocjuje klucze, które faktycznie szyfrują ruch danych. Gdy obie fazy zgadzają się po obu stronach, tunel się podnosi; wystarczy jeden niezgodny algorytm i połączenie po cichu zawodzi — dlatego poniższe kroki utrzymują obie strony symetryczne.

Zanim zaczniesz

Potrzebujesz dwóch routerów MikroTik z RouterOS v7, każdy z publicznym adresem IP lub działającą nazwą DDNS, oraz dwóch nienakładających się podsieci LAN. W tym przewodniku używamy 192.168.10.0/24 w lokalizacji A i 192.168.20.0/24 w lokalizacji B. Jeśli obie lokalizacje używają 192.168.88.0/24, routing jest niemożliwy — najpierw przeadresuj jedną stronę. Ponieważ IPsec jest bardzo wrażliwy na rozjazd zegara, przed startem włącz NTP na obu routerach; gdy oba końce się rozjadą, security association wygasają i tunel wciąż będzie się zrywał.

Pilnowanie tego wymogu w więcej niż kilku lokalizacjach to już mordęga. Przy zarządzaniu flotą MKController daje jedną konsolę, w której potwierdzisz wersję RouterOS i źródło czasu każdego routera przed przełączeniem tunelu, więc nie logujesz się do każdego urządzenia tylko po to, by sprawdzić jego gotowość.

Krok 1: Utwórz profil IKE i peera

W lokalizacji A zdefiniuj profil fazy 1 i skieruj peera na publiczny adres lokalizacji B:

/ip ipsec profile add name=to-siteB hash-algorithm=sha256 \
enc-algorithm=aes-256 dh-group=modp2048 lifetime=1d
/ip ipsec peer add name=siteB address=<SITE_B_PUBLIC_IP>/32 \
profile=to-siteB exchange-mode=ike2

dh-group=modp2048 to Diffie-Hellman Group 14 — solidny, nowoczesny domyślny wybór. exchange-mode=ike2 wybiera IKEv2, szybszy i odporniejszy niż stary tryb main/IKEv1. Oba końce muszą używać tych samych wartości profilu i tego samego trybu wymiany.

Krok 2: Dodaj identity (klucz współdzielony)

/ip ipsec identity add peer=siteB auth-method=pre-shared-key \
secret="<long-random-shared-secret>"

Użyj długiego, losowego sekretu i przechowuj go tak, jak klucz SSH — nie w wiadomości na czacie. Ten sam sekret trafia na oba routery.

Krok 3: Zdefiniuj proposal fazy 2

/ip ipsec proposal add name=to-siteB auth-algorithms=sha256 \
enc-algorithms=aes-256-cbc pfs-group=modp2048

Perfect Forward Secrecy (pfs-group) oznacza, że każda wymiana kluczy używa świeżego materiału, więc przejęty klucz nigdy nie odsłoni wcześniejszego ruchu. Tak jak w fazie 1, algorytmy muszą się zgadzać po obu stronach.

Krok 4: Utwórz policy tunelu

Policy mówi RouterOS, który ruch szyfrować — z lokalnej sieci LAN do zdalnej:

/ip ipsec policy add peer=siteB tunnel=yes \
src-address=192.168.10.0/24 dst-address=192.168.20.0/24 \
proposal=to-siteB action=encrypt

tunnel=yes sprawia, że jest to połączenie site-to-site, a nie host-to-host: oryginalne pakiety są opakowywane w całości, więc obie sieci LAN komunikują się przezroczyście.

Krok 5: Dodaj regułę omijania NAT (krok, o którym wszyscy zapominają)

Właśnie tu wykłada się większość pierwszych prób. Twój router ma już regułę masquerade, która przepisuje adres źródłowy wychodzącego ruchu z LAN. Jeśli zadziała przed IPsec, zdalny koniec dostaje pakiety, których źródło nie pasuje już do policy, i je odrzuca. Dodaj regułę accept powyżej masquerade, aby ruch kierowany do tunelu pomijał NAT:

/ip firewall nat add chain=srcnat action=accept place-before=0 \
src-address=192.168.10.0/24 dst-address=192.168.20.0/24

place-before=0 umieszcza regułę na samej górze łańcucha srcnat i jest to obowiązkowe — reguła omijania ustawiona za masquerade nic nie daje.

Krok 6: Otwórz firewall i zweryfikuj

Zezwól na porty IKE i NAT-T oraz protokół ESP w łańcuchu input, aby tunel mógł się zestawić, zwłaszcza gdy któraś z lokalizacji siedzi za kolejnym urządzeniem NAT:

/ip firewall filter add chain=input protocol=udp dst-port=500,4500 action=accept
/ip firewall filter add chain=input protocol=ipsec-esp action=accept

Następnie potwierdź, że tunel działa:

/ip ipsec active-peers print
/ip ipsec policy print

Zdrowy tunel pokazuje aktywnego peera oraz policy, której ph2-state ma wartość established. Szybki ping z hosta w jednej sieci LAN do hosta w drugiej dowodzi osiągalności end-to-end.

Odwzoruj konfigurację w lokalizacji B

Powtórz każdy krok w lokalizacji B z odwróconymi adresami: peer wskazuje na publiczny IP lokalizacji A, a policy i omijanie NAT używają src-address=192.168.20.0/24 i dst-address=192.168.10.0/24. Profil, proposal, sekret identity i tryb IKEv2 pozostają identyczne. Gdy obie strony się zgadzają, faza 1 i faza 2 kończą się powodzeniem i tunel się podnosi.

Wskazówki dotyczące bezpieczeństwa i eksploatacji

Aktualizuj RouterOS — ostatnie wydania przyniosły poprawki dotyczące dopasowywania certyfikatów peerów w IPsec/IKEv2, więc tunel, który działał w zeszłym kwartale, zasługuje na ponowny test po każdej aktualizacji. Wybieraj IKEv2 z PFS zamiast domyślnych ustawień starego IKEv1. Tam, gdzie możesz, wraz ze wzrostem liczby tuneli przechodź z klucza współdzielonego na uwierzytelnianie certyfikatami, bo jeden wyciekły klucz pre-shared dotyka każdej lokalizacji, która go używa. I zapisuj stan tunelu tam, gdzie faktycznie patrzysz: martwe łącze site-to-site jest niewidoczne, dopóki ktoś nie spróbuje sięgnąć do zdalnej sieci LAN i mu się nie uda.

We flocie tunel IPsec, który po cichu pada po rozjeździe zegara albo zerwaniu WAN, to dokładnie ta awaria, którą klient zauważy przed tobą. MKController zamyka tę lukę: obserwuje każdy router przez bezpieczny tunel wychodzący, który nie wymaga publicznego IP ani przekierowania portów na urządzeniu, trzyma wersjonowane kopie konfiguracji, dzięki czemu porównasz i przywrócisz działający blok IPsec po nieudanej zmianie, i potrafi otworzyć zgłoszenie przy zdarzeniu link-down, zanim zadzwoni telefon. Jeśli chodzi o samą konfigurację tunelu, nasz przewodnik o NAT na MikroTik wyjaśnia regułę masquerade, którą tutaj omijasz, a jeśli chcesz dotrzeć do pojedynczego routera zamiast łączyć dwie sieci LAN, zobacz zdalne zarządzanie za CGNAT oraz nasz poradnik o zdalnym zarządzaniu przez WireGuard.

Zbierz swoje tunele pod jednym dachem

IPsec czysto łączy dwie lokalizacje, ale rosnący ISP czy MSP szybko ma dziesiątki tuneli, kluczy i reguł firewalla do utrzymania w zgodzie — a każda ręczna zmiana to okazja, by zamknąć sobie drogę do zdalnej lokalizacji. MKController powstał dokładnie na tę skalę: scentralizowane zarządzanie flotą, bezpieczny zdalny dostęp bez wystawionych portów, historia konfiguracji i kopie zapasowe oraz wdrażanie zmian firewalla i policy na całą flotę, dzięki czemu szablon tunelu wdrażasz raz, zamiast przepisywać go router po routerze. Operatorzy pracujący z MikroTik na dużą skalę używają go, by zamienić stracone popołudnie z SSH na każdym urządzeniu w kilka kliknięć na zmianę.

Rozpocznij darmowy okres próbny MKController