Remote Access
MikroTik IPsec site-to-site VPN-guide
Bygg en MikroTik IPsec site-to-site VPN: konfigurer IKEv2-peer, proposal, policy og NAT-omgåelsesregelen som får tunnelen til å virke.
Sammendrag En MikroTik IPsec site-to-site VPN krypterer trafikk mellom to hele nettverk — et hovedkontor og en filial, et NOC og en mastelokasjon — slik at verter på hvert LAN når det andre som om de var lokale. Denne guiden konfigurerer begge ruterne på RouterOS v7: IKEv2-peeren, identity med pre-shared key, proposal for fase 2, tunnel-policyen, NAT-omgåelsesregelen som velter de fleste første forsøk, samt brannmurreglene og kontrollene som bekrefter at tunnelen er oppe.

Hva er en MikroTik IPsec site-to-site VPN?
En MikroTik IPsec site-to-site VPN er en permanent kryptert tunnel mellom to rutere som slår sammen to atskilte LAN til ett rutbart nettverk på lag 3, uten at noen av ruterne eksponerer en administrasjonsport mot det offentlige internett. I motsetning til klienttilgangs-VPN-er som WireGuard eller OpenVPN — der én enkelt administratorenhet kobler seg til — er en site-to-site-tunnel alltid på og går fra subnett til subnett: hver vert bak Ruter A når automatisk hver tillatte vert bak Ruter B. IPsec er riktig verktøy her fordi det er en åpen standard som støttes av praktisk talt alle brannmur- og ruterleverandører, det kjører i RouterOS-kjernen for god gjennomstrømning, og på MikroTik er det innebygd uten ekstra pakke å installere.
Tunnelen bygges gjennom to forhandlinger. Fase 1 (IKE) autentiserer de to ruterne mot hverandre og setter opp en sikker kanal; fase 2 (IPsec) forhandler nøklene som faktisk krypterer datatrafikken din. Får du begge fasene til å stemme i hver ende, kommer tunnelen opp; avviker bare én algoritme, feiler den stille — derfor holder trinnene nedenfor de to sidene symmetriske.
Før du starter
Du trenger to MikroTik-rutere med RouterOS v7, hver med en offentlig IP-adresse eller et fungerende DDNS-vertsnavn, og to ikke-overlappende LAN-subnett. Denne guiden bruker 192.168.10.0/24 på Lokasjon A og 192.168.20.0/24 på Lokasjon B. Hvis begge lokasjoner bruker 192.168.88.0/24, er ruting umulig — endre adressering på den ene siden først. Fordi IPsec er svært følsom for klokkeavvik, må du aktivere NTP på begge ruterne før du begynner; hvis de to endene driver fra hverandre, utløper security associations og tunnelen faller gjentatte ganger.
Å håndtere den forutsetningen på mer enn en håndfull lokasjoner er allerede et ork. Når du drifter en flåte, gir MKController deg én konsoll for å bekrefte hver ruters RouterOS-versjon og klokkekilde før du setter en tunnel i drift, slik at du slipper å logge inn på hver enhet bare for å sjekke at den er klar.
Trinn 1: Opprett IKE-profile og peer
På Lokasjon A definerer du fase 1-profilen og peker en peer mot den offentlige adressen til Lokasjon B:
/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=ike2dh-group=modp2048 er Diffie-Hellman gruppe 14 — en solid moderne standardverdi. exchange-mode=ike2 velger IKEv2, som er raskere og mer robust enn den gamle main/IKEv1-modusen. Begge ender må bruke de samme profile-verdiene og samme utvekslingsmodus.
Trinn 2: Legg til identity (pre-shared key)
/ip ipsec identity add peer=siteB auth-method=pre-shared-key \ secret="<long-random-shared-secret>"Bruk en lang, tilfeldig hemmelighet og oppbevar den slik du ville oppbevart en SSH-nøkkel — ikke i en chatmelding. Samme hemmelighet skal inn på begge ruterne.
Trinn 3: Definer proposal for fase 2
/ip ipsec proposal add name=to-siteB auth-algorithms=sha256 \ enc-algorithms=aes-256-cbc pfs-group=modp2048Perfect Forward Secrecy (pfs-group) betyr at hver nøkkelfornyelse bruker friskt nøkkelmateriale, slik at en kompromittert nøkkel aldri avslører tidligere trafikk. Som i fase 1 må algoritmene stemme i begge ender.
Trinn 4: Opprett tunnel-policy
Policyen forteller RouterOS hvilken trafikk som skal krypteres — det lokale LAN-et til det eksterne 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=encrypttunnel=yes er det som gjør dette til site-to-site i stedet for vert-til-vert: de opprinnelige pakkene pakkes inn i sin helhet, slik at de to LAN-ene kan snakke sammen transparent.
Trinn 5: Legg til NAT-omgåelsesregelen (trinnet alle glemmer)
Det er her de fleste første forsøk ryker. Ruteren din har allerede en masquerade-regel som skriver om kildeadressen til utgående LAN-trafikk. Hvis den utløses før IPsec, mottar den eksterne enden pakker der kilden ikke lenger matcher policyen, og forkaster dem. Legg til en accept-regel over masquerade slik at tunnelbundet trafikk hopper over 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/24place-before=0 plasserer regelen helt øverst i srcnat-kjeden, noe som er påkrevd — en omgåelsesregel plassert etter masquerade gjør ingenting.
Trinn 6: Åpne brannmuren og verifiser
Tillat IKE- og NAT-T-portene samt ESP-protokollen i input-kjeden slik at tunnelen kan etableres, spesielt hvis en av lokasjonene står bak nok 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=acceptBekreft deretter at tunnelen er oppe:
/ip ipsec active-peers print/ip ipsec policy printEn sunn tunnel viser en aktiv peer og en policy der ph2-state står til established. En rask ping fra en vert på det ene LAN-et til en vert på det andre beviser ende-til-ende-tilgjengelighet.
Speil konfigurasjonen på Lokasjon B
Gjenta hvert trinn på Lokasjon B med adressene byttet om: peeren peker mot den offentlige IP-en til Lokasjon A, og policyen og NAT-omgåelsen bruker src-address=192.168.20.0/24 og dst-address=192.168.10.0/24. Profile, proposal, identity-hemmeligheten og IKEv2-modusen forblir identiske. Når begge sider stemmer, fullføres fase 1 og fase 2 og tunnelen kommer opp.
Sikkerhets- og driftstips
Hold RouterOS oppdatert — nyere utgivelser har levert rettelser som berører matching av peer-sertifikater i IPsec/IKEv2, så en tunnel som virket forrige kvartal fortjener en ny test etter hver oppgradering. Foretrekk IKEv2 med PFS fremfor de gamle IKEv1-standardene. Der du kan, gå fra en delt hemmelighet til sertifikatautentisering etter hvert som antallet tunneler vokser, for én lekket pre-shared key rammer hver eneste lokasjon som deler den. Og logg tunnelstatus et sted du faktisk følger med: en død site-to-site-forbindelse er usynlig helt til noen prøver å nå det eksterne LAN-et og ikke får det til.
På en flåte er en IPsec-tunnel som stille faller etter en klokkedesynkronisering eller et WAN-avbrudd nettopp den typen feil kunden oppdager før deg. MKController lukker det gapet: den overvåker hver ruter over en sikker utgående tunnel som verken krever offentlig IP eller portvideresending på enheten, holder versjonerte konfigurasjonssikkerhetskopier slik at du kan sammenligne og gjenopprette en fungerende IPsec-blokk etter en dårlig endring, og kan opprette en sak ved en link-down-hendelse før telefonen ringer. For selve tunnelkonfigurasjonen forklarer guiden vår om NAT på MikroTik masquerade-regelen du omgår her, og for å nå én enkelt ruter i stedet for å koble sammen to LAN, se fjernadministrasjon bak CGNAT og gjennomgangen vår av fjernadministrasjon med WireGuard.
Samle tunnelene dine under ett tak
IPsec kobler sammen to lokasjoner rent, men en voksende ISP eller MSP har snart dusinvis av tunneler, nøkler og brannmurregler å holde synkronisert — og hver manuelle endring er en sjanse til å låse seg selv ute av en ekstern lokasjon. MKController er bygget for nettopp den skalaen: sentralisert flåtestyring, sikker fjerntilgang uten eksponerte porter, konfigurasjonshistorikk og sikkerhetskopier, samt flåteomfattende utrulling av brannmur- og policyendringer, slik at en tunnelmal rulles ut én gang i stedet for å tastes inn ruter for ruter. Operatører som kjører MikroTik i stor skala bruker det til å gjøre en tapt ettermiddag med SSH per enhet om til noen få klikk per endring.