Sprievodca MikroTik IPsec site-to-site VPN

Zhrnutie MikroTik IPsec site-to-site VPN šifruje prevádzku medzi dvoma celými sieťami — centrálou a pobočkou, dohľadovým centrom a vysielačom — takže hostitelia v každej LAN dosiahnu na tú druhú, akoby bola miestna. Tento návod nakonfiguruje oba smerovače na RouterOS v7: IKEv2 peer, identitu so zdieľaným kľúčom, proposal pre fázu 2, policy tunela, pravidlo na obídenie NAT, na ktorom stroskotá väčšina prvých pokusov, a firewallové pravidlá aj kontroly, ktoré potvrdia, že tunel beží.

Čo je MikroTik IPsec site-to-site VPN?

MikroTik IPsec site-to-site VPN je trvalý šifrovaný tunel medzi dvoma smerovačmi, ktorý spája dve oddelené LAN do jednej smerovateľnej siete na tretej vrstve bez toho, aby ktorýkoľvek smerovač vystavoval správcovský port do verejného internetu. Na rozdiel od klientskych VPN, ako sú WireGuard alebo OpenVPN — kde sa pripája jedno zariadenie správcu — je tunel site-to-site trvale zapnutý a spája podsiete: každý hostiteľ za smerovačom A sa automaticky dostane na každého povoleného hostiteľa za smerovačom B. IPsec je tu tou správnou voľbou, pretože ide o otvorený štandard podporovaný prakticky každým výrobcom firewallov a smerovačov, beží priamo v jadre RouterOS s dobrou priepustnosťou a na MikroTiku je zabudovaný bez nutnosti inštalovať ďalší balík.

Tunel vzniká v dvoch vyjednávaniach. Fáza 1 (IKE) overí oba smerovače navzájom a vytvorí zabezpečený kanál; fáza 2 (IPsec) vyjedná kľúče, ktoré skutočne šifrujú vašu dátovú prevádzku. Keď si obe fázy na oboch koncoch zodpovedajú, tunel nabehne; stačí nezhoda v jedinom algoritme a ticho zlyhá — preto nižšie uvedené kroky držia obe strany symetrické.

Skôr než začnete

Potrebujete dva smerovače MikroTik s RouterOS v7, každý s verejnou IP adresou alebo funkčným DDNS názvom, a dve neprekrývajúce sa LAN podsiete. Tento návod používa 192.168.10.0/24 na Site A a 192.168.20.0/24 na Site B. Ak obe lokality používajú 192.168.88.0/24, smerovanie nie je možné — najprv preadresujte jednu stranu. Keďže je IPsec veľmi citlivý na rozdiely v čase, zapnite pred začiatkom na oboch smerovačoch NTP; ak sa oba konce rozídu, bezpečnostné asociácie vypršia a tunel bude neustále padať.

Ustrážiť tento predpoklad na viac než hŕstke lokalít je už otrava. Keď prevádzkujete flotilu, MKController vám dá jedinú konzolu, kde si pri každom smerovači overíte verziu RouterOS a zdroj času ešte pred prepnutím tunela, takže sa nemusíte prihlasovať na každé zariadenie len kvôli kontrole pripravenosti.

Krok 1: Vytvorte IKE profil a peer

Na Site A nadefinujte profil fázy 1 a nasmerujte peer na verejnú adresu Site 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 je Diffie-Hellman Group 14 — rozumné moderné východisko. exchange-mode=ike2 volí IKEv2, ktorý je rýchlejší a odolnejší než zastaraný režim main/IKEv1. Oba konce musia používať rovnaké hodnoty profilu a rovnaký režim výmeny.

Krok 2: Pridajte identitu (pre-shared key)

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

Použite dlhý náhodný tajný kľúč a uložte ho tak ako SSH kľúč — nie do správy v chate. Rovnaký kľúč patrí na oba smerovače.

Krok 3: Definujte proposal pre fázu 2

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

Perfect Forward Secrecy (pfs-group) znamená, že každá výmena kľúčov použije čerstvý kľúčový materiál, takže kompromitovaný kľúč nikdy neodhalí staršiu prevádzku. Rovnako ako pri fáze 1 sa algoritmy musia zhodovať na oboch koncoch.

Krok 4: Vytvorte policy tunela

Policy hovorí RouterOS, ktorú prevádzku šifrovať — z miestnej LAN do vzdialenej LAN:

/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 je to, čo z toho robí site-to-site namiesto host-to-host: pôvodné pakety sa zabalia celé, takže obe LAN spolu komunikujú transparentne.

Krok 5: Pridajte pravidlo na obídenie NAT (krok, na ktorý všetci zabúdajú)

Práve tu stroskotá väčšina prvých pokusov. Váš smerovač už má pravidlo masquerade, ktoré prepisuje zdrojovú adresu odchádzajúcej prevádzky z LAN. Ak sa uplatní skôr než IPsec, vzdialený koniec dostane pakety, ktorých zdroj už nezodpovedá policy, a zahodí ich. Pridajte pravidlo accept nad masquerade, aby prevádzka smerujúca do tunela NAT preskočila:

/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 umiestni pravidlo úplne na začiatok reťazca srcnat, čo je nevyhnutné — pravidlo na obídenie zaradené až za masquerade nerobí nič.

Krok 6: Otvorte firewall a overte funkčnosť

Povoľte v reťazci input porty IKE a NAT-T plus protokol ESP, aby sa tunel mohol nadviazať, najmä ak niektorá lokalita sedí za ďalším NAT zariadením:

/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

Potom overte, že tunel beží:

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

Zdravý tunel ukáže aktívny peer a policy, ktorej ph2-state hlási established. Rýchly ping z hostiteľa v jednej LAN na hostiteľa v druhej dokáže dostupnosť od konca ku koncu.

Zrkadlite konfiguráciu na Site B

Zopakujte všetky kroky na Site B s obrátenými adresami: peer mieri na verejnú IP adresu Site A a policy aj obídenie NAT používajú src-address=192.168.20.0/24 a dst-address=192.168.10.0/24. Profil, proposal, tajný kľúč identity a režim IKEv2 zostávajú rovnaké. Keď si obe strany zodpovedajú, fáza 1 aj fáza 2 sa dokončia a tunel nabehne.

Tipy pre bezpečnosť a prevádzku

Držte RouterOS zaplátaný — nedávne vydania priniesli opravy dotýkajúce sa párovania certifikátov peerov pri IPsec/IKEv2, takže tunel, ktorý fungoval minulý kvartál, si po každom upgrade zaslúži nový test. Uprednostnite IKEv2 s PFS pred zastaranými východiskovými hodnotami IKEv1. Kde sa dá, prejdite s rastúcim počtom tunelov zo zdieľaného kľúča na overovanie certifikátmi, pretože jeden uniknutý pre-shared key zasiahne každú lokalitu, ktorá ho zdieľa. A logujte stav tunela tam, kam sa naozaj pozeráte: mŕtvy site-to-site spoj je neviditeľný, kým sa niekto nepokúsi dosiahnuť na vzdialenú LAN a nepodarí sa mu to.

Vo flotile je IPsec tunel, ktorý ticho spadne po rozídení hodín alebo výpadku WAN, presne ten typ poruchy, ktorý zákazník zaznamená skôr než vy. MKController túto medzeru zatvára: stráži každý smerovač cez zabezpečený odchádzajúci tunel, ktorý nepotrebuje verejnú IP ani presmerovanie portov na zariadení, uchováva verzované zálohy konfigurácie, takže si po zlej úprave môžete porovnať a obnoviť funkčný IPsec blok, a pri výpadku spoja vie založiť tiket skôr, než zazvoní telefón. Pre samotnú konfiguráciu tunela vysvetľuje náš sprievodca NAT na MikroTiku pravidlo masquerade, ktoré tu obchádzate, a ak potrebujete dosiahnuť na jediný smerovač namiesto spojenia dvoch LAN, pozrite si vzdialenú správu za CGNAT a náš návod vzdialená správa cez WireGuard.

Zjednoťte správu svojich tunelov

IPsec spojí dve lokality čisto, ale rastúci ISP alebo MSP má čoskoro desiatky tunelov, kľúčov a firewallových pravidiel, ktoré treba držať v súlade — a každá ručná úprava je šanca vyzamknúť sa zo vzdialenej lokality. MKController je postavený presne na túto veľkosť: centralizovaná správa flotily, zabezpečený vzdialený prístup bez vystavených portov, história konfigurácií a zálohy a hromadné nasadenie zmien firewallu a policy naprieč flotilou, takže sa šablóna tunela vyroluje raz namiesto prepisovania smerovač po smerovači. Operátori, ktorí prevádzkujú MikroTik vo veľkom, ho používajú na to, aby premenili stratené popoludnie s SSH na každom zariadení na pár kliknutí na zmenu.

Vyskúšajte MKController zadarmo