MikroTik IPsec site-to-site VPN-guide

Resumé En MikroTik IPsec site-to-site VPN krypterer trafik mellem to hele netværk — et hovedkontor og en filial, et NOC og en mastelokation — så værter på hvert LAN når det andet, som var de lokale. Denne guide konfigurerer begge routere med RouterOS v7: IKEv2-peeren, identity med pre-shared key, proposal til fase 2, tunnel-policy, NAT-bypass-reglen der spænder ben for de fleste første forsøg, samt firewallreglerne og kontrollerne, der bekræfter at tunnelen er oppe.

Hvad er en MikroTik IPsec site-to-site VPN?

En MikroTik IPsec site-to-site VPN er en permanent krypteret tunnel mellem to routere, der samler to adskilte LAN i ét routbart netværk på lag 3, uden at nogen af routerne eksponerer en administrationsport mod det offentlige internet. I modsætning til klientadgangs-VPN’er som WireGuard eller OpenVPN — hvor en enkelt administratorenhed ringer op — er en site-to-site-tunnel altid aktiv og går fra subnet til subnet: hver vært bag Router A kan automatisk nå hver tilladt vært bag Router B. IPsec er det rigtige valg her, fordi det er en åben standard, som stort set alle firewall- og routerproducenter understøtter, det kører i RouterOS-kernen for god gennemstrømning, og på MikroTik er det indbygget uden ekstra pakker at installere.

Tunnelen bygges gennem to forhandlinger. Fase 1 (IKE) autentificerer de to routere over for hinanden og opsætter en sikker kanal; fase 2 (IPsec) forhandler de nøgler, der reelt krypterer din datatrafik. Får du begge faser til at matche i hver ende, kommer tunnelen op; er blot én algoritme forskellig, fejler den lydløst — derfor holder trinnene nedenfor de to sider symmetriske.

Før du går i gang

Du skal bruge to MikroTik-routere med RouterOS v7, hver med en offentlig IP-adresse eller et fungerende DDNS-værtsnavn, og to ikke-overlappende LAN-subnet. Denne guide bruger 192.168.10.0/24 på Lokation A og 192.168.20.0/24 på Lokation B. Hvis begge lokationer bruger 192.168.88.0/24, er routing umulig — omadresser først den ene side. Da IPsec er meget følsom over for uroverensstemmelser, skal du aktivere NTP på begge routere, før du begynder; hvis de to ender driver fra hinanden, udløber security associations, og tunnelen falder gentagne gange.

At styre den forudsætning på mere end en håndfuld lokationer er allerede en byrde. Når du driver en flåde, giver MKController dig én konsol til at bekræfte hver routers RouterOS-version og urkilde, før du sætter en tunnel i drift, så du ikke skal logge ind på hver enhed blot for at se, om den er klar.

Trin 1: Opret IKE-profile og peer

På Lokation A definerer du fase 1-profilen og peger en peer på Lokation B’s offentlige adresse:

/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 er Diffie-Hellman gruppe 14 — en solid moderne standard. exchange-mode=ike2 vælger IKEv2, som er hurtigere og mere robust end den gamle main/IKEv1-tilstand. Begge ender skal bruge de samme profile-værdier og den samme exchange-tilstand.

Trin 2: Tilføj identity (pre-shared key)

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

Brug en lang, tilfældig hemmelighed og opbevar den, som du ville opbevare en SSH-nøgle — ikke i en chatbesked. Den samme hemmelighed skal på begge routere.

Trin 3: Definer proposal til fase 2

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

Perfect Forward Secrecy (pfs-group) betyder, at hver nøgleudskiftning bruger friskt nøglemateriale, så en kompromitteret nøgle aldrig afslører tidligere trafik. Som i fase 1 skal algoritmerne matche i begge ender.

Trin 4: Opret tunnel-policy

Policyen fortæller RouterOS, hvilken trafik der skal krypteres — det lokale LAN til det fjerne 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 er det, der gør dette site-to-site frem for vært-til-vært: de oprindelige pakker pakkes ind i deres helhed, så de to LAN kan tale sammen transparent.

Trin 5: Tilføj NAT-bypass-reglen (trinnet alle glemmer)

Det er her, de fleste første forsøg bryder sammen. Din router har allerede en masquerade-regel, der omskriver kildeadressen på udgående LAN-trafik. Hvis den udløses før IPsec, modtager fjernenden pakker, hvis kilde ikke længere matcher policyen, og kasserer dem. Tilføj en accept-regel over masquerade, så tunnelbunden trafik springer NAT over:

/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 placerer reglen allerøverst i srcnat-kæden, hvilket er påkrævet — en bypass-regel placeret efter masquerade gør ingenting.

Trin 6: Åbn firewallen og verificer

Tillad IKE- og NAT-T-portene samt ESP-protokollen i input-kæden, så tunnelen kan etableres, især hvis en af lokationerne sidder bag endnu en NAT-enhed:

/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æft derefter, at tunnelen er oppe:

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

En sund tunnel viser en aktiv peer og en policy, hvis ph2-state står til established. Et hurtigt ping fra en vært på det ene LAN til en vært på det andet beviser end-to-end-forbindelse.

Spejl konfigurationen på Lokation B

Gentag hvert trin på Lokation B med adresserne byttet om: peeren peger på Lokation A’s offentlige IP, og policy og NAT-bypass bruger src-address=192.168.20.0/24 og dst-address=192.168.10.0/24. Profile, proposal, identity-hemmeligheden og IKEv2-tilstanden forbliver identiske. Når begge sider matcher, fuldføres fase 1 og fase 2, og tunnelen kommer op.

Sikkerheds- og driftstips

Hold RouterOS opdateret — nyere udgivelser har leveret rettelser, der berører matchning af peer-certifikater i IPsec/IKEv2, så en tunnel, der virkede sidste kvartal, fortjener en ny test efter hver opgradering. Foretræk IKEv2 med PFS frem for de gamle IKEv1-standarder. Hvor du kan, så gå fra en delt hemmelighed til certifikatgodkendelse, efterhånden som antallet af tunneler vokser, for én lækket pre-shared key rammer hver eneste lokation, der deler den. Og log tunnelstatus et sted, du rent faktisk holder øje med: et dødt site-to-site-link er usynligt, indtil nogen forsøger at nå det fjerne LAN og ikke kan.

På en flåde er en IPsec-tunnel, der stille falder efter en urdesynkronisering eller et WAN-udfald, netop den type fejl, en kunde opdager før dig. MKController lukker det hul: den overvåger hver router over en sikker udgående tunnel, der hverken kræver offentlig IP eller portviderestilling på enheden, holder versionerede konfigurationsbackups, så du kan sammenligne og gendanne en fungerende IPsec-blok efter en dårlig redigering, og kan oprette en sag ved en link-down-hændelse, før telefonen ringer. Til selve tunnelkonfigurationen forklarer vores guide om NAT på MikroTik den masquerade-regel, du omgår her, og for at nå en enkelt router frem for at forbinde to LAN, se fjernadministration bag CGNAT og vores gennemgang af fjernadministration med WireGuard.

Saml dine tunneler ét sted

IPsec forbinder to lokationer rent, men en voksende ISP eller MSP har snart snesevis af tunneler, nøgler og firewallregler at holde synkroniseret — og hver manuel redigering er en chance for at låse sig selv ude af en fjern lokation. MKController er bygget til præcis den skala: centraliseret flådestyring, sikker fjernadgang uden eksponerede porte, konfigurationshistorik og backups samt flådedækkende udrulning af firewall- og policyændringer, så en tunnelskabelon rulles ud én gang i stedet for at blive tastet ind router for router. Operatører, der kører MikroTik i stor skala, bruger det til at forvandle en tabt eftermiddag med SSH per enhed til nogle få klik per ændring.

Start din gratis MKController-prøveperiode