MikroTik IPsec site-to-site VPN-guide

Sammanfattning En MikroTik IPsec site-to-site VPN krypterar trafik mellan två hela nätverk — ett huvudkontor och en filial, ett NOC och en mastplats — så att värdar på varje LAN når det andra som om de vore lokala. Den här guiden konfigurerar båda routrarna på RouterOS v7: IKEv2-peeren, identity med pre-shared key, proposal för fas 2, tunnelns policy, NAT-förbikopplingsregeln som fäller de flesta första försök, samt brandväggsreglerna och kontrollerna som bekräftar att tunneln är uppe.

Vad är en MikroTik IPsec site-to-site VPN?

En MikroTik IPsec site-to-site VPN är en permanent krypterad tunnel mellan två routrar som förenar två separata LAN till ett routbart nätverk på lager 3, utan att någon av routrarna exponerar en hanteringsport mot det publika internet. Till skillnad från klientåtkomst-VPN som WireGuard eller OpenVPN — där en enda administratörsenhet ansluter — är en site-to-site-tunnel alltid aktiv och går från subnät till subnät: varje värd bakom Router A når automatiskt varje tillåten värd bakom Router B. IPsec är rätt verktyg här eftersom det är en öppen standard som stöds av praktiskt taget varje brandväggs- och routertillverkare, det körs i RouterOS-kärnan för god genomströmning, och på MikroTik är det inbyggt utan extra paket att installera.

Tunneln byggs genom två förhandlingar. Fas 1 (IKE) autentiserar de två routrarna mot varandra och sätter upp en säker kanal; fas 2 (IPsec) förhandlar de nycklar som faktiskt krypterar din datatrafik. Får du båda faserna att stämma i vardera änden kommer tunneln upp; skiljer sig en enda algoritm misslyckas den tyst — därför håller stegen nedan de två sidorna symmetriska.

Innan du börjar

Du behöver två MikroTik-routrar med RouterOS v7, var och en med en publik IP-adress eller ett fungerande DDNS-värdnamn, och två icke-överlappande LAN-subnät. Den här guiden använder 192.168.10.0/24 på Plats A och 192.168.20.0/24 på Plats B. Om båda platserna använder 192.168.88.0/24 är routing omöjligt — adressera om den ena sidan först. Eftersom IPsec är mycket känsligt för klockavvikelser bör du aktivera NTP på båda routrarna innan du börjar; om de två ändarna driver isär löper security associations ut och tunneln faller gång på gång.

Att hantera den förutsättningen på fler än en handfull platser är redan ett arbete i sig. När du driver en flotta ger MKController dig en enda konsol för att bekräfta varje routers RouterOS-version och klockkälla innan du sätter en tunnel i drift, så att du slipper logga in på varje enhet bara för att kontrollera att den är redo.

Steg 1: Skapa IKE-profile och peer

På Plats A, definiera fas 1-profilen och peka en peer mot Plats B:s publika adress:

/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 är Diffie-Hellman-grupp 14 — ett gediget modernt standardval. exchange-mode=ike2 väljer IKEv2, som är snabbare och mer robust än det gamla main/IKEv1-läget. Båda ändarna måste använda samma profile-värden och samma utbytesläge.

Steg 2: Lägg till identity (pre-shared key)

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

Använd en lång, slumpmässig hemlighet och förvara den som du skulle förvara en SSH-nyckel — inte i ett chattmeddelande. Samma hemlighet läggs in på båda routrarna.

Steg 3: Definiera proposal för fas 2

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

Perfect Forward Secrecy (pfs-group) innebär att varje nyckelförnyelse använder färskt nyckelmaterial, så att en komprometterad nyckel aldrig avslöjar tidigare trafik. Precis som i fas 1 måste algoritmerna stämma i båda ändarna.

Steg 4: Skapa tunnelns policy

Policyn talar om för RouterOS vilken trafik som ska krypteras — det lokala LAN:et till fjärr-LAN:et:

/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 är det som gör detta till site-to-site i stället för värd-till-värd: de ursprungliga paketen kapslas in i sin helhet, så att de två LAN:en kan tala med varandra transparent.

Steg 5: Lägg till NAT-förbikopplingsregeln (steget alla glömmer)

Det är här de flesta första försök havererar. Din router har redan en masquerade-regel som skriver om källadressen för utgående LAN-trafik. Om den utlöses före IPsec tar fjärränden emot paket vars källa inte längre matchar policyn och kastar dem. Lägg till en accept-regel ovanför masquerade så att tunnelbunden trafik hoppar över NAT:

/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 placerar regeln allra överst i srcnat-kedjan, vilket är obligatoriskt — en förbikopplingsregel placerad efter masquerade gör ingenting.

Steg 6: Öppna brandväggen och verifiera

Tillåt IKE- och NAT-T-portarna samt ESP-protokollet i input-kedjan så att tunneln kan etableras, särskilt om någon av platserna sitter bakom ytterligare en NAT-enhet:

/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

Bekräfta sedan att tunneln är uppe:

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

En frisk tunnel visar en aktiv peer och en policy vars ph2-state står på established. En snabb ping från en värd på det ena LAN:et till en värd på det andra bevisar tillgänglighet från ände till ände.

Spegla konfigurationen på Plats B

Upprepa varje steg på Plats B med adresserna omkastade: peeren pekar mot Plats A:s publika IP, och policyn och NAT-förbikopplingen använder src-address=192.168.20.0/24 och dst-address=192.168.10.0/24. Profile, proposal, identity-hemligheten och IKEv2-läget förblir identiska. När båda sidorna stämmer slutförs fas 1 och fas 2 och tunneln kommer upp.

Säkerhets- och drifttips

Håll RouterOS uppdaterat — senare utgåvor har levererat rättningar som rör matchning av peer-certifikat i IPsec/IKEv2, så en tunnel som fungerade förra kvartalet förtjänar ett nytt test efter varje uppgradering. Föredra IKEv2 med PFS framför de gamla IKEv1-standarderna. Där du kan bör du gå från en delad hemlighet till certifikatautentisering allteftersom antalet tunnlar växer, eftersom en läckt pre-shared key drabbar varje plats som delar den. Och logga tunnelstatus någonstans du faktiskt tittar: en död site-to-site-länk är osynlig tills någon försöker nå fjärr-LAN:et och misslyckas.

I en flotta är en IPsec-tunnel som tyst faller efter en klockdesynkronisering eller en WAN-störning precis den sortens fel som en kund upptäcker före dig. MKController täpper till den luckan: den övervakar varje router över en säker utgående tunnel som varken kräver publik IP eller portvidarebefordran på enheten, håller versionerade konfigurationsbackuper så att du kan jämföra och återställa ett fungerande IPsec-block efter en dålig ändring, och kan öppna ett ärende vid en link-down-händelse innan telefonen ringer. För själva tunnelkonfigurationen förklarar vår guide om NAT på MikroTik masquerade-regeln du kringgår här, och för att nå en enskild router i stället för att koppla ihop två LAN, se fjärrhantering bakom CGNAT och vår genomgång av fjärrhantering med WireGuard.

Samla dina tunnlar under ett tak

IPsec kopplar ihop två platser snyggt, men en växande ISP eller MSP har snart dussintals tunnlar, nycklar och brandväggsregler att hålla synkroniserade — och varje manuell ändring är en chans att låsa ut sig själv från en fjärrplats. MKController är byggt för precis den skalan: centraliserad flotthantering, säker fjärråtkomst utan exponerade portar, konfigurationshistorik och backuper, samt flottäckande utrullning av brandväggs- och policyändringar, så att en tunnelmall rullas ut en gång i stället för att skrivas in router för router. Operatörer som kör MikroTik i stor skala använder det för att förvandla en förlorad eftermiddag med SSH per enhet till några få klick per ändring.

Starta din kostnadsfria MKController-provperiod