Průvodce MikroTik IPsec site-to-site VPN

Shrnutí MikroTik IPsec site-to-site VPN šifruje provoz mezi dvěma celými sítěmi — centrálou a pobočkou, dohledovým centrem a vysílačem — takže hosty v každé LAN dosáhnou na tu druhou, jako by byla místní. Tento návod nakonfiguruje oba routery na RouterOS v7: IKEv2 peer, identitu se sdíleným klíčem, proposal pro fázi 2, policy tunelu, pravidlo pro obejití NAT, o které se rozbije většina prvních pokusů, a firewallová pravidla i kontroly, které potvrdí, že tunel běží.

Co je MikroTik IPsec site-to-site VPN?

MikroTik IPsec site-to-site VPN je trvalý šifrovaný tunel mezi dvěma routery, který spojuje dvě oddělené LAN do jedné směrovatelné sítě na třetí vrstvě, aniž by kterýkoli router vystavoval správcovský port do veřejného internetu. Na rozdíl od klientských VPN, jako jsou WireGuard nebo OpenVPN — kde se připojuje jedno zařízení správce — je tunel site-to-site trvale zapnutý a propojuje podsítě: každý host za routerem A se automaticky dostane na každého povoleného hosta za routerem B. IPsec je zde tou správnou volbou, protože jde o otevřený standard podporovaný prakticky každým výrobcem firewallů a routerů, běží přímo v jádře RouterOS s dobrou propustností a na MikroTiku je zabudovaný bez nutnosti instalovat další balíček.

Tunel vzniká ve dvou vyjednáváních. Fáze 1 (IKE) ověří oba routery navzájem a vytvoří zabezpečený kanál; fáze 2 (IPsec) vyjedná klíče, které skutečně šifrují váš datový provoz. Když si obě fáze na obou koncích odpovídají, tunel naskočí; stačí neshoda v jediném algoritmu a tiše selže — proto níže uvedené kroky drží obě strany symetrické.

Než začnete

Potřebujete dva routery MikroTik s RouterOS v7, každý s veřejnou IP adresou nebo funkčním DDNS názvem, a dvě nepřekrývající se LAN podsítě. Tento návod používá 192.168.10.0/24 na Site A a 192.168.20.0/24 na Site B. Pokud obě lokality používají 192.168.88.0/24, směrování není možné — nejprve přeadresujte jednu stranu. Protože je IPsec velmi citlivý na rozdíly v čase, zapněte před začátkem na obou routerech NTP; když se oba konce rozejdou, bezpečnostní asociace vyprší a tunel bude neustále padat.

Uhlídat tenhle předpoklad na víc než hrstce lokalit už je otrava. Když provozujete flotilu, MKController vám dá jedinou konzoli, kde si u každého routeru ověříte verzi RouterOS a zdroj času ještě před přepnutím tunelu, takže se nemusíte hlásit na každé zařízení jen kvůli kontrole připravenosti.

Krok 1: Vytvořte IKE profil a peer

Na Site A nadefinujte profil fáze 1 a nasměrujte peer na veřejnou 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ýchozí stav. exchange-mode=ike2 volí IKEv2, který je rychlejší a odolnější než zastaralý režim main/IKEv1. Oba konce musí používat stejné hodnoty profilu a stejný režim výměny.

Krok 2: Přidejte identitu (pre-shared key)

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

Použijte dlouhý náhodný tajný klíč a uložte ho stejně jako SSH klíč — ne do chatové zprávy. Stejný klíč patří na oba routery.

Krok 3: Definujte proposal pro fázi 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ýměna klíčů použije čerstvý klíčový materiál, takže kompromitovaný klíč nikdy neodhalí dřívější provoz. Stejně jako u fáze 1 se algoritmy musí shodovat na obou koncích.

Krok 4: Vytvořte policy tunelu

Policy říká RouterOS, který provoz šifrovat — z místní LAN do vzdálené 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, co z toho dělá site-to-site místo host-to-host: původní pakety se zabalí celé, takže spolu obě LAN komunikují transparentně.

Krok 5: Přidejte pravidlo pro obejití NAT (krok, na který všichni zapomínají)

Právě tady se rozbije většina prvních pokusů. Váš router už má pravidlo masquerade, které přepisuje zdrojovou adresu odchozího provozu z LAN. Pokud se uplatní dřív než IPsec, vzdálený konec dostane pakety, jejichž zdroj už neodpovídá policy, a zahodí je. Přidejte pravidlo accept nad masquerade, aby provoz mířící do tunelu NAT přeskočil:

/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 umístí pravidlo úplně na začátek řetězce srcnat, což je nezbytné — pravidlo pro obejití zařazené až za masquerade nedělá nic.

Krok 6: Otevřete firewall a ověřte funkčnost

Povolte v řetězci input porty IKE a NAT-T plus protokol ESP, aby se tunel mohl navázat, zvlášť pokud některá lokalita sedí za dalším NAT zařízení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

Pak ověřte, že tunel běží:

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

Zdravý tunel ukáže aktivní peer a policy, jejíž ph2-state hlásí established. Rychlý ping z hosta v jedné LAN na hosta ve druhé prokáže dostupnost od konce ke konci.

Zrcadlete konfiguraci na Site B

Zopakujte všechny kroky na Site B s obrácenými adresami: peer míří na veřejnou IP adresu Site A a policy i obejití NAT používají src-address=192.168.20.0/24 a dst-address=192.168.10.0/24. Profil, proposal, tajný klíč identity a režim IKEv2 zůstávají shodné. Když si obě strany odpovídají, fáze 1 i fáze 2 se dokončí a tunel naskočí.

Tipy pro bezpečnost a provoz

Držte RouterOS záplatovaný — nedávná vydání přinesla opravy dotýkající se párování certifikátů peerů u IPsec/IKEv2, takže tunel, který fungoval minulé čtvrtletí, si po každém upgradu zaslouží nový test. Dávejte přednost IKEv2 s PFS před zastaralými výchozími hodnotami IKEv1. Kde to jde, přejděte se rostoucím počtem tunelů ze sdíleného klíče na ověřování certifikáty, protože jeden uniklý pre-shared key zasáhne každou lokalitu, která ho sdílí. A logujte stav tunelu tam, kam se opravdu díváte: mrtvý site-to-site spoj je neviditelný, dokud se někdo nepokusí dosáhnout na vzdálenou LAN a nepovede se mu to.

Ve flotile je IPsec tunel, který tiše spadne po rozejití hodin nebo výpadku WAN, přesně ten typ poruchy, kterou zákazník zaznamená dřív než vy. MKController tuhle mezeru zavírá: hlídá každý router přes zabezpečený odchozí tunel, který nepotřebuje veřejnou IP ani přesměrování portů na zařízení, uchovává verzované zálohy konfigurace, takže si můžete po špatné úpravě porovnat a obnovit funkční IPsec blok, a při výpadku spoje umí založit ticket dřív, než zazvoní telefon. Pro samotnou konfiguraci tunelu vysvětluje náš průvodce NAT na MikroTiku pravidlo masquerade, které tady obcházíte, a pokud potřebujete dosáhnout na jediný router místo spojení dvou LAN, podívejte se na vzdálenou správu za CGNAT a náš návod vzdálená správa přes WireGuard.

Sjednoťte správu svých tunelů

IPsec spojí dvě lokality čistě, ale rostoucí ISP nebo MSP má brzy desítky tunelů, klíčů a firewallových pravidel, které je třeba držet v souladu — a každá ruční úprava je šance vyzamknout se ze vzdálené lokality. MKController je postavený přesně na tuhle velikost: centralizovaná správa flotily, zabezpečený vzdálený přístup bez vystavených portů, historie konfigurací a zálohy a hromadné nasazení změn firewallu a policy napříč flotilou, takže se šablona tunelu vyroluje jednou místo přepisování router po routeru. Operátoři, kteří provozují MikroTik ve velkém, ho používají k tomu, aby proměnili ztracené odpoledne s SSH na každém zařízení v pár kliknutí na změnu.

Vyzkoušejte MKController zdarma