MikroTik IPsec site-to-site VPN juhend

Kokkuvõte MikroTiki IPsec site-to-site VPN krüpteerib liikluse kahe terve võrgu vahel — peakontor ja filiaal, NOC ja masti asukoht — nii et kummagi LAN-i seadmed jõuavad teiseni, nagu oleksid nad kohalikud. See juhend seadistab mõlemad ruuterid RouterOS v7-l: IKEv2 peer’i, eeljagatud võtmega identity, 2. faasi proposal’i, tunneli policy, NAT-i möödaviigu reegli, mis nurjab enamiku esimesi katseid, ning tulemüürireeglid ja kontrollid, mis kinnitavad, et tunnel töötab.

Mis on MikroTiki IPsec site-to-site VPN?

MikroTiki IPsec site-to-site VPN on püsiv krüpteeritud tunnel kahe ruuteri vahel, mis ühendab kaks eraldi LAN-i üheks marsruuditavaks võrguks 3. kihis, ilma et kumbki ruuter avaldaks haldusporti avalikku internetti. Erinevalt kliendipõhistest VPN-idest nagu WireGuard või OpenVPN — kus sisse helistab üks halduri seade — on site-to-site tunnel alati sees ja alamvõrgust alamvõrku: iga seade Ruuteri A taga jõuab automaatselt iga lubatud seadmeni Ruuteri B taga. IPsec on siin õige valik, sest see on avatud standard, mida toetab praktiliselt iga tulemüüri- ja ruuteritootja, see töötab hea läbilaskevõime nimel RouterOS-i tuumas ja MikroTikis on see sisse ehitatud ilma lisapaketti paigaldamata.

Tunnel ehitatakse kahe läbirääkimisega. 1. faas (IKE) autendib kaks ruuterit teineteisele ja loob turvalise kanali; 2. faas (IPsec) lepib kokku võtmed, mis tegelikult sinu andmeliiklust krüpteerivad. Kui mõlemad faasid mõlemas otsas kokku langevad, tuleb tunnel üles; kui kas või üks algoritm erineb, ebaõnnestub see vaikselt — seetõttu hoiavad allolevad sammud pooled sümmeetrilised.

Enne alustamist

Vajad kahte MikroTiki ruuterit RouterOS v7-ga, kummalgi avalik IP-aadress või toimiv DDNS-i hostinimi, ja kahte mittekattuvat LAN-i alamvõrku. See juhend kasutab Asukohas A 192.168.10.0/24 ja Asukohas B 192.168.20.0/24. Kui mõlemad asukohad kasutavad 192.168.88.0/24, on marsruutimine võimatu — muuda esmalt ühe poole aadresse. Kuna IPsec on kella nihkele väga tundlik, luba enne alustamist mõlemas ruuteris NTP; kui otsad triivivad lahku, aeguvad security association’id ja tunnel kukub pidevalt.

Selle eelduse haldamine enam kui käputäies asukohtades on juba tüütu töö. Kui haldad parki, annab MKController sulle ühe konsooli, kus kinnitada iga ruuteri RouterOS-i versioon ja kellaallikas enne tunneli üleviimist, nii et sa ei pea igasse seadmesse sisse logima ainult selleks, et kontrollida, kas see on valmis.

1. samm: loo IKE profile ja peer

Asukohas A määra 1. faasi profile ja suuna peer Asukoha B avalikule aadressile:

/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-Hellmani grupp 14 — mõistlik kaasaegne vaikeväärtus. exchange-mode=ike2 valib IKEv2, mis on kiirem ja töökindlam kui vana main/IKEv1 režiim. Mõlemad otsad peavad kasutama samu profile’i väärtusi ja sama vahetusrežiimi.

2. samm: lisa identity (eeljagatud võti)

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

Kasuta pikka juhuslikku saladust ja hoia seda nii, nagu hoiaksid SSH-võtit — mitte vestlussõnumis. Sama saladus läheb mõlemasse ruuterisse.

3. samm: määra 2. faasi proposal

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

Perfect Forward Secrecy (pfs-group) tähendab, et iga võtmevahetus kasutab värsket võtmematerjali, nii et kompromiteeritud võti ei paljasta kunagi varasemat liiklust. Nagu 1. faasis, peavad algoritmid mõlemas otsas kokku langema.

4. samm: loo tunneli policy

Policy ütleb RouterOS-ile, millist liiklust krüpteerida — kohalikust LAN-ist kaug-LAN-i:

/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 on see, mis teeb sellest site-to-site ühenduse host-to-host ühenduse asemel: algsed paketid mähitakse tervikuna, nii et kaks LAN-i saavad läbipaistvalt suhelda.

5. samm: lisa NAT-i möödaviigu reegel (samm, mille kõik unustavad)

Siin katkeb enamik esimesi katseid. Sinu ruuteril on juba masquerade reegel, mis kirjutab väljuva LAN-liikluse lähteaadressi ümber. Kui see rakendub enne IPsec-i, saab kaugem ots pakette, mille lähe ei vasta enam policy’le, ja viskab need ära. Lisa accept reegel masquerade’ist ettepoole, et tunnelisse suunduv liiklus NAT-i vahele jätaks:

/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 paigutab reegli srcnat ahela kõige ette, mis on kohustuslik — masquerade’i järele paigutatud möödaviigu reegel ei tee midagi.

6. samm: ava tulemüür ja kontrolli

Luba input ahelas IKE ja NAT-T pordid ning ESP protokoll, et tunnel saaks luua ühenduse, eriti kui üks asukoht asub veel ühe NAT-seadme taga:

/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

Seejärel kinnita, et tunnel on üleval:

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

Terve tunnel näitab aktiivset peer’i ja policy’t, mille ph2-state on established. Kiire ping ühe LAN-i seadmest teise LAN-i seadmesse tõestab otsast otsani ühenduvust.

Peegelda seadistus Asukohas B

Korda iga sammu Asukohas B vahetatud aadressidega: peer osutab Asukoha A avalikule IP-le ning policy ja NAT-i möödaviik kasutavad src-address=192.168.20.0/24 ja dst-address=192.168.10.0/24. Profile, proposal, identity saladus ja IKEv2 režiim jäävad identseks. Kui mõlemad pooled kattuvad, lõpevad 1. ja 2. faas ning tunnel tuleb üles.

Turva- ja haldusnõuanded

Hoia RouterOS uuendatuna — hiljutised väljalasked on toonud parandusi, mis puudutavad IPsec/IKEv2 peer-sertifikaadi sobitamist, nii et eelmises kvartalis töötanud tunnel väärib pärast iga uuendust uut testi. Eelista IKEv2 koos PFS-iga vanade IKEv1 vaikeseadete asemel. Kus võimalik, liigu tunnelite arvu kasvades jagatud saladuselt sertifikaadipõhisele autentimisele, sest üks lekkinud eeljagatud võti mõjutab iga asukohta, mis seda jagab. Ja logi tunneli olekut kohta, mida sa tegelikult jälgid: surnud site-to-site ühendus on nähtamatu, kuni keegi püüab kaug-LAN-i jõuda ja ei suuda.

Pargis on IPsec-tunnel, mis kella desünkroniseerimise või WAN-i katkestuse järel vaikselt kukub, täpselt selline rike, mille klient märkab enne sind. MKController sulgeb selle lünga: see jälgib iga ruuterit turvalise väljuva tunneli kaudu, mis ei vaja avalikku IP-d ega pordi suunamist seadmes, hoiab versioonitud konfiguratsiooni varukoopiaid, et saaksid pärast halba muudatust töötava IPsec-ploki võrrelda ja taastada, ning võib avada pileti ühenduse katkemise sündmusel enne, kui telefon heliseb. Tunneli seadistuse enda kohta selgitab meie juhend NAT MikroTikis masquerade reeglit, millest sa siin mööda lähed, ja ühe ruuterini jõudmiseks kahe LAN-i ühendamise asemel vaata kaughaldus CGNAT-i taga ja meie ülevaadet kaughaldusest WireGuardiga.

Too oma tunnelid ühe katuse alla

IPsec ühendab kaks asukohta puhtalt, kuid kasvaval ISP-l või MSP-l on peagi kümneid tunneleid, võtmeid ja tulemüürireegleid, mida sünkroonis hoida — ja iga käsitsi tehtud muudatus on võimalus end kaugasukohast välja lukustada. MKController on ehitatud just sellise mastaabi jaoks: keskne pargihaldus, turvaline kaugjuurdepääs ilma avatud portideta, konfiguratsiooni ajalugu ja varukoopiad ning tulemüüri- ja policy-muudatuste pargiülene rakendamine, nii et tunneli mall rullub välja üks kord, mitte ei kirjutata ruuterhaaval ümber. Operaatorid, kes haldavad MikroTiki suures mastaabis, kasutavad seda selleks, et muuta kaotatud pärastlõuna seadmepõhise SSH-ga mõneks klikiks muudatuse kohta.

Alusta tasuta MKControlleri prooviperioodi