Remote Access
MikroTik IPsec site-to-site VPN útmutató
Építsen MikroTik IPsec site-to-site VPN-t: állítsa be az IKEv2 peert, a proposalt, a policyt és a NAT-megkerülő szabályt, amitől az alagút működik.
Összefoglaló A MikroTik IPsec site-to-site VPN két teljes hálózat közötti forgalmat titkosít — központi iroda és fióktelep, NOC és tornyhelyszín között —, így az egyes LAN-ok gépei úgy érik el a másikat, mintha helyiek lennének. Ez az útmutató mindkét routert beállítja RouterOS v7 alatt: az IKEv2 peert, az előre megosztott kulcsú identityt, a 2. fázis proposalját, az alagút policyját, a NAT-megkerülő szabályt, amelyen a legtöbb első próbálkozás elbukik, valamint a tűzfalszabályokat és ellenőrzéseket, amelyek igazolják, hogy az alagút él.
Mi az a MikroTik IPsec site-to-site VPN?
A MikroTik IPsec site-to-site VPN egy állandó titkosított alagút két router között, amely két különálló LAN-t egyetlen útvonalazható hálózattá kapcsol össze a 3. rétegen, anélkül hogy bármelyik router menedzsmentportot tenne közzé a nyilvános interneten. A kliensoldali VPN-ekkel ellentétben, mint a WireGuard vagy az OpenVPN — ahol egyetlen adminisztrátori eszköz kapcsolódik be —, a site-to-site alagút mindig aktív és alhálózat-alhálózat közötti: az A router mögötti minden gép automatikusan eléri a B router mögötti minden engedélyezett gépet. Az IPsec itt a megfelelő eszköz, mert nyílt szabvány, amelyet gyakorlatilag minden tűzfal- és routergyártó támogat, a RouterOS kerneljében fut a jó átbocsátás érdekében, és MikroTikon beépített, telepítendő extra csomag nélkül.
Az alagút két egyeztetéssel épül fel. Az 1. fázis (IKE) hitelesíti a két routert egymás felé és biztonságos csatornát hoz létre; a 2. fázis (IPsec) egyezteti azokat a kulcsokat, amelyek ténylegesen titkosítják az adatforgalmat. Ha mindkét fázis egyezik a két végponton, az alagút feláll; ha akár egyetlen algoritmus is eltér, csendben elbukik — ezért tartják az alábbi lépések szimmetrikusan a két oldalt.
Mielőtt hozzákezd
Két MikroTik routerre van szüksége RouterOS v7 rendszerrel, mindegyiken publikus IP-címmel vagy működő DDNS-névvel, és két nem átfedő LAN alhálózatra. Ez az útmutató a 192.168.10.0/24 címtartományt használja az A telephelyen és a 192.168.20.0/24 tartományt a B telephelyen. Ha mindkét telephely a 192.168.88.0/24 tartományt használja, az útvonalazás lehetetlen — előbb címezze át az egyik oldalt. Mivel az IPsec nagyon érzékeny az óraeltérésre, indulás előtt engedélyezze az NTP-t mindkét routeren; ha a két végpont elsodródik egymástól, a security associationök lejárnak és az alagút folyamatosan leszakad.
Ennek az előfeltételnek a kezelése néhánynál több telephelyen már önmagában is teher. Ha flottát üzemeltet, az MKController egyetlen konzolt ad, amelyen megerősítheti minden router RouterOS-verzióját és óraforrását, mielőtt élesítene egy alagutat, így nem kell minden eszközre belépnie csak azért, hogy ellenőrizze, készen áll-e.
1. lépés: Hozza létre az IKE profile-t és peert
Az A telephelyen határozza meg az 1. fázis profile-ját, és irányítson egy peert a B telephely publikus címére:
/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=ike2A dh-group=modp2048 a Diffie-Hellman 14-es csoport — megbízható modern alapérték. Az exchange-mode=ike2 az IKEv2-t választja, amely gyorsabb és robusztusabb a régi main/IKEv1 módnál. Mindkét végpontnak ugyanazokat a profile-értékeket és ugyanazt a cseremódot kell használnia.
2. lépés: Adja hozzá az identityt (előre megosztott kulcs)
/ip ipsec identity add peer=siteB auth-method=pre-shared-key \ secret="<long-random-shared-secret>"Használjon hosszú, véletlenszerű titkot, és úgy tárolja, ahogy egy SSH-kulcsot tárolna — ne csevegőüzenetben. Ugyanaz a titok kerül mindkét routerre.
3. lépés: Határozza meg a 2. fázis proposalját
/ip ipsec proposal add name=to-siteB auth-algorithms=sha256 \ enc-algorithms=aes-256-cbc pfs-group=modp2048A Perfect Forward Secrecy (pfs-group) azt jelenti, hogy minden kulcsmegújítás friss kulcsanyagot használ, így egy kompromittált kulcs soha nem fedi fel a korábbi forgalmat. Az 1. fázishoz hasonlóan az algoritmusoknak mindkét végponton egyezniük kell.
4. lépés: Hozza létre az alagút policyját
A policy megmondja a RouterOS-nek, melyik forgalmat titkosítsa — a helyi LAN-t a távoli LAN felé:
/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=encryptA tunnel=yes teszi ezt site-to-site kapcsolattá host-to-host helyett: az eredeti csomagok egészben becsomagolódnak, így a két LAN átlátszóan kommunikálhat.
5. lépés: Adja hozzá a NAT-megkerülő szabályt (a lépés, amit mindenki elfelejt)
Itt bukik el a legtöbb első próbálkozás. A routerén már van egy masquerade szabály, amely átírja a kimenő LAN-forgalom forráscímét. Ha ez az IPsec előtt lép működésbe, a távoli végpont olyan csomagokat kap, amelyek forrása már nem illeszkedik a policyra, és eldobja őket. Adjon hozzá egy accept szabályt a masquerade fölé, hogy az alagútba tartó forgalom kihagyja a NAT-ot:
/ip firewall nat add chain=srcnat action=accept place-before=0 \ src-address=192.168.10.0/24 dst-address=192.168.20.0/24A place-before=0 a szabályt a srcnat lánc legtetejére helyezi, ami kötelező — a masquerade után elhelyezett megkerülő szabály semmit sem tesz.
6. lépés: Nyissa meg a tűzfalat és ellenőrizzen
Engedélyezze az IKE és NAT-T portokat, valamint az ESP protokollt az input láncban, hogy az alagút létrejöhessen, különösen ha valamelyik telephely egy másik NAT-eszköz mögött van:
/ip firewall filter add chain=input protocol=udp dst-port=500,4500 action=accept/ip firewall filter add chain=input protocol=ipsec-esp action=acceptEzután erősítse meg, hogy az alagút él:
/ip ipsec active-peers print/ip ipsec policy printAz egészséges alagút aktív peert és olyan policyt mutat, amelynek ph2-state értéke established. Egy gyors ping az egyik LAN gépéről a másik LAN gépére bizonyítja a végponttól végpontig tartó elérhetőséget.
Tükrözze a konfigurációt a B telephelyen
Ismételje meg minden lépést a B telephelyen felcserélt címekkel: a peer az A telephely publikus IP-jére mutat, a policy és a NAT-megkerülés pedig a src-address=192.168.20.0/24 és dst-address=192.168.10.0/24 értékeket használja. A profile, a proposal, az identity titka és az IKEv2 mód azonos marad. Ha mindkét oldal egyezik, az 1. és 2. fázis lezárul, és az alagút feláll.
Biztonsági és üzemeltetési tippek
Tartsa naprakészen a RouterOS-t — a friss kiadások olyan javításokat hoztak, amelyek az IPsec/IKEv2 peer-tanúsítványok illesztését érintik, így egy alagút, amely múlt negyedévben működött, minden frissítés után újratesztelést érdemel. Részesítse előnyben az IKEv2-t PFS-sel a régi IKEv1 alapértékekkel szemben. Ahol lehet, az alagutak számának növekedésével térjen át a megosztott titokról tanúsítványalapú hitelesítésre, mert egyetlen kiszivárgott előre megosztott kulcs minden telephelyet érint, amely osztozik rajta. És naplózza az alagút állapotát olyan helyre, amelyet ténylegesen figyel: egy halott site-to-site kapcsolat láthatatlan, amíg valaki meg nem próbálja elérni a távoli LAN-t és nem sikerül neki.
Flottában egy IPsec alagút, amely óradeszinkronizálás vagy WAN-kiesés után csendben leszakad, pontosan az a fajta hiba, amit az ügyfél vesz észre Ön előtt. Az MKController betölti ezt a rést: minden routert egy biztonságos kimenő alagúton keresztül figyel, amelyhez nem kell publikus IP és porttovábbítás az eszközön, verziózott konfigurációs biztonsági mentéseket tart, hogy egy rossz szerkesztés után összehasonlíthassa és visszaállíthassa a működő IPsec blokkot, és a kapcsolatkiesési eseményre hibajegyet nyithat, mielőtt megcsörren a telefon. Magához az alagút konfigurációjához útmutatónk a MikroTik NAT-ról elmagyarázza a masquerade szabályt, amelyet itt megkerül, egyetlen router eléréséhez pedig két LAN összekapcsolása helyett lásd a távoli menedzsment CGNAT mögött és a WireGuard távoli menedzsment útmutatónkat.
Hozza alagútjait egy fedél alá
Az IPsec tisztán összeköt két telephelyet, de egy növekvő ISP vagy MSP hamarosan több tucat alagutat, kulcsot és tűzfalszabályt tart szinkronban — és minden kézi szerkesztés esély arra, hogy kizárja magát egy távoli telephelyről. Az MKController pontosan erre a léptékre készült: központosított flottakezelés, biztonságos távoli hozzáférés nyitott portok nélkül, konfigurációs előzmények és biztonsági mentések, valamint tűzfal- és policy-változások flottaszintű kiterjesztése, így egy alagútsablon egyszer kerül kiosztásra ahelyett, hogy routerről routerre újragépelnék. A MikroTikot nagy léptékben üzemeltető szolgáltatók arra használják, hogy egy eszközönkénti SSH-val elvesztegetett délutánt módosításonként néhány kattintássá alakítsanak.