MikroTik IPsec site-to-site VPN -opas

Yhteenveto MikroTik IPsec site-to-site VPN salaa liikenteen kahden kokonaisen verkon välillä — pääkonttorin ja sivutoimipisteen, NOCin ja mastopaikan — niin että kummankin LANin laitteet tavoittavat toisen kuin ne olisivat paikallisia. Tämä opas määrittää molemmat reitittimet RouterOS v7:llä: IKEv2-peerin, esijaetun avaimen identityn, vaiheen 2 proposalin, tunnelin policyn, NAT-ohitussäännön joka kaataa useimmat ensiyritykset, sekä palomuurisäännöt ja tarkistukset jotka vahvistavat tunnelin toimivan.

Mikä on MikroTik IPsec site-to-site VPN?

MikroTik IPsec site-to-site VPN on pysyvä salattu tunneli kahden reitittimen välillä, joka yhdistää kaksi erillistä LANia yhdeksi reititettäväksi verkoksi kerroksella 3 ilman että kumpikaan reititin altistaa hallintaporttia julkiseen internetiin. Toisin kuin asiakaspääsy-VPN:t kuten WireGuard tai OpenVPN — joissa yksittäinen ylläpitolaite ottaa yhteyden — site-to-site-tunneli on aina päällä ja aliverkosta aliverkkoon: jokainen laite Reitittimen A takana tavoittaa automaattisesti jokaisen sallitun laitteen Reitittimen B takana. IPsec on tässä oikea työkalu, koska se on avoin standardi jota lähes jokainen palomuuri- ja reititinvalmistaja tukee, se ajetaan RouterOSin ytimessä hyvän läpisyötön vuoksi, ja MikroTikissä se on sisäänrakennettu ilman erillistä asennettavaa pakettia.

Tunneli rakennetaan kahdella neuvottelulla. Vaihe 1 (IKE) todentaa reitittimet toisilleen ja luo suojatun kanavan; vaihe 2 (IPsec) neuvottelee avaimet jotka todella salaavat dataliikenteesi. Kun molemmat vaiheet täsmäävät kummassakin päässä, tunneli nousee; jos yksikin algoritmi eroaa, se epäonnistuu hiljaa — siksi alla olevat vaiheet pitävät puolet symmetrisinä.

Ennen kuin aloitat

Tarvitset kaksi MikroTik-reititintä RouterOS v7:llä, kummallakin julkinen IP-osoite tai toimiva DDNS-isäntänimi, ja kaksi päällekkäisyydetöntä LAN-aliverkkoa. Tämä opas käyttää sivustolla A osoitetta 192.168.10.0/24 ja sivustolla B osoitetta 192.168.20.0/24. Jos molemmat sivustot käyttävät 192.168.88.0/24, reititys on mahdotonta — muuta ensin toisen puolen osoitteet. Koska IPsec on hyvin herkkä kellon poikkeamalle, ota NTP käyttöön molemmissa reitittimissä ennen aloittamista; jos päät ajautuvat erilleen, security associationit vanhenevat ja tunneli katkeilee jatkuvasti.

Tämän edellytyksen hallinta useammassa kuin kourallisessa sivustoja on jo työlästä. Kun ylläpidät laitekantaa, MKController antaa yhden konsolin, josta varmistat jokaisen reitittimen RouterOS-version ja kellolähteen ennen tunnelin käyttöönottoa, joten sinun ei tarvitse kirjautua jokaiseen laitteeseen vain tarkistaaksesi että se on valmis.

Vaihe 1: Luo IKE-profile ja peer

Sivustolla A määritä vaiheen 1 profile ja osoita peer sivuston B julkiseen osoitteeseen:

/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 on Diffie-Hellman-ryhmä 14 — vankka nykyaikainen oletus. exchange-mode=ike2 valitsee IKEv2:n, joka on nopeampi ja kestävämpi kuin vanha main/IKEv1-tila. Molempien päiden on käytettävä samoja profile-arvoja ja samaa vaihtotilaa.

Vaihe 2: Lisää identity (esijaettu avain)

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

Käytä pitkää satunnaista salaisuutta ja säilytä se kuten säilyttäisit SSH-avaimen — ei chat-viestissä. Sama salaisuus tulee molempiin reitittimiin.

Vaihe 3: Määritä vaiheen 2 proposal

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

Perfect Forward Secrecy (pfs-group) tarkoittaa että jokainen avaimen uusinta käyttää tuoretta avainmateriaalia, joten vaarantunut avain ei koskaan paljasta mennyttä liikennettä. Kuten vaiheessa 1, algoritmien on täsmättävä molemmissa päissä.

Vaihe 4: Luo tunnelin policy

Policy kertoo RouterOSille mikä liikenne salataan — paikallisesta LANista etä-LANiin:

/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 tekee tästä site-to-site- eikä host-to-host-yhteyden: alkuperäiset paketit kääritään kokonaisina, joten kaksi LANia voivat keskustella läpinäkyvästi.

Vaihe 5: Lisää NAT-ohitussääntö (vaihe jonka kaikki unohtavat)

Tässä useimmat ensiyritykset kaatuvat. Reitittimessäsi on jo masquerade-sääntö joka kirjoittaa lähtevän LAN-liikenteen lähdeosoitteen uudelleen. Jos se laukeaa ennen IPseciä, etäpää vastaanottaa paketteja joiden lähde ei enää täsmää policyyn ja pudottaa ne. Lisää accept-sääntö masqueraden yläpuolelle, jotta tunneliin menevä liikenne ohittaa NATin:

/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 sijoittaa säännön aivan srcnat-ketjun kärkeen, mikä on pakollista — masqueraden jälkeen sijoitettu ohitussääntö ei tee mitään.

Vaihe 6: Avaa palomuuri ja varmista

Salli IKE- ja NAT-T-portit sekä ESP-protokolla input-ketjussa jotta tunneli voi muodostua, etenkin jos jompikumpi sivusto on toisen NAT-laitteen takana:

/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

Varmista sitten että tunneli on ylhäällä:

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

Terve tunneli näyttää aktiivisen peerin ja policyn jonka ph2-state on established. Nopea ping toisen LANin laitteesta toisen LANin laitteeseen todistaa päästä päähän -tavoitettavuuden.

Peilaa määritykset sivustolle B

Toista jokainen vaihe sivustolla B osoitteet käännettyinä: peer osoittaa sivuston A julkiseen IP-osoitteeseen, ja policy sekä NAT-ohitus käyttävät arvoja src-address=192.168.20.0/24 ja dst-address=192.168.10.0/24. Profile, proposal, identityn salaisuus ja IKEv2-tila pysyvät identtisinä. Kun molemmat puolet täsmäävät, vaihe 1 ja vaihe 2 valmistuvat ja tunneli nousee.

Tietoturva- ja ylläpitovinkkejä

Pidä RouterOS päivitettynä — viimeaikaiset julkaisut ovat sisältäneet korjauksia jotka koskevat IPsec/IKEv2-peer-varmenteiden täsmäystä, joten viime neljänneksellä toiminut tunneli ansaitsee uuden testin jokaisen päivityksen jälkeen. Suosi IKEv2:ta PFS:n kanssa vanhojen IKEv1-oletusten sijaan. Siirry jaetusta salaisuudesta varmennetodennukseen aina kun voit tunneleiden määrän kasvaessa, koska yksi vuotanut esijaettu avain koskee jokaista sivustoa joka sen jakaa. Ja kirjaa tunnelin tila jonnekin jota todella seuraat: kuollut site-to-site-linkki on näkymätön kunnes joku yrittää tavoittaa etä-LANin eikä onnistu.

Laitekannassa IPsec-tunneli joka putoaa hiljaa kellon desynkronoinnin tai WAN-katkoksen jälkeen on juuri sellainen vika jonka asiakas huomaa ennen sinua. MKController kuroo tämän aukon: se valvoo jokaista reititintä suojatun lähtevän tunnelin kautta joka ei vaadi julkista IP-osoitetta eikä portin edelleenohjausta laitteessa, säilyttää versioidut asetusvarmuuskopiot jotta voit vertailla ja palauttaa toimivan IPsec-lohkon huonon muokkauksen jälkeen, ja voi avata tiketin linkin katkeamisesta ennen kuin puhelin soi. Itse tunnelin määritykseen oppaamme NAT MikroTikissä selittää masquerade-säännön jonka tässä ohitat, ja yksittäisen reitittimen tavoittamiseen kahden LANin yhdistämisen sijaan katso etähallinta CGNATin takana ja WireGuard-etähallinnan läpikäyntimme.

Kokoa tunnelisi saman katon alle

IPsec yhdistää kaksi sivustoa siististi, mutta kasvavalla ISP:llä tai MSP:llä on pian kymmeniä tunneleita, avaimia ja palomuurisääntöjä pidettävänä synkronissa — ja jokainen käsin tehty muokkaus on tilaisuus lukita itsensä ulos etäsivustolta. MKController on rakennettu juuri tähän mittakaavaan: keskitetty laitekannan hallinta, suojattu etäkäyttö ilman avoimia portteja, asetushistoria ja varmuuskopiot sekä palomuuri- ja policy-muutosten vieminen koko laitekantaan, joten tunnelimalli otetaan käyttöön kerran sen sijaan että se kirjoitettaisiin uudelleen reititin kerrallaan. MikroTikiä laajassa mittakaavassa ajavat operaattorit käyttävät sitä muuttamaan hukatun iltapäivän laitekohtaista SSH:ta muutamaksi klikkaukseksi muutosta kohden.

Aloita ilmainen MKController-kokeilu