Remote Access
Vodnik za MikroTik IPsec site-to-site VPN
Zgradite MikroTik IPsec site-to-site VPN: nastavite peer IKEv2, proposal, policy in pravilo obhoda NAT, zaradi katerega tunel deluje.
Povzetek MikroTik IPsec site-to-site VPN šifrira promet med dvema celotnima omrežjema — sedežem in podružnico, NOC in lokacijo s stolpom — tako da naprave v vsakem LAN dosežejo drugega, kot bi bile lokalne. Ta vodnik nastavi oba usmerjevalnika na RouterOS v7: peer IKEv2, identity z vnaprej deljenim ključem, proposal faze 2, policy tunela, pravilo obhoda NAT, ob katerega se spotakne večina prvih poskusov, ter pravila požarnega zidu in preverjanja, ki potrdijo, da tunel deluje.

Kaj je MikroTik IPsec site-to-site VPN?
MikroTik IPsec site-to-site VPN je trajen šifriran tunel med dvema usmerjevalnikoma, ki združi dva ločena LAN v eno usmerljivo omrežje na sloju 3, ne da bi kateri koli usmerjevalnik izpostavil upravljalna vrata javnemu internetu. Za razliko od odjemalskih VPN, kot sta WireGuard ali OpenVPN — kjer se poveže ena skrbniška naprava —, je tunel site-to-site vedno vklopljen in deluje od podomrežja do podomrežja: vsaka naprava za usmerjevalnikom A samodejno doseže vsako dovoljeno napravo za usmerjevalnikom B. IPsec je tu pravo orodje, ker je odprt standard, ki ga podpira praktično vsak proizvajalec požarnih zidov in usmerjevalnikov, teče v jedru RouterOS za dobro prepustnost, na MikroTiku pa je vgrajen brez dodatnega paketa za namestitev.
Tunel se zgradi z dvema pogajanjema. Faza 1 (IKE) medsebojno overi usmerjevalnika in vzpostavi varen kanal; faza 2 (IPsec) se dogovori o ključih, ki dejansko šifrirajo vaš podatkovni promet. Poskrbite, da se obe fazi ujemata na vsakem koncu, in tunel se vzpostavi; naj se razlikuje en sam algoritem in tiho odpove — zato spodnji koraki ohranjajo obe strani simetrični.
Preden začnete
Potrebujete dva usmerjevalnika MikroTik z RouterOS v7, vsakega z javnim naslovom IP ali delujočim imenom DDNS, in dve neprekrivajoči se podomrežji LAN. Ta vodnik uporablja 192.168.10.0/24 na lokaciji A in 192.168.20.0/24 na lokaciji B. Če obe lokaciji uporabljata 192.168.88.0/24, je usmerjanje nemogoče — najprej prenaslovite eno stran. Ker je IPsec zelo občutljiv na odstopanje ure, pred začetkom omogočite NTP na obeh usmerjevalnikih; če se konca razideta, security associations potečejo in tunel nenehno pada.
Upravljanje tega pogoja na več kot peščici lokacij je že samo po sebi breme. Ko upravljate floto, vam MKController da eno konzolo za potrditev različice RouterOS in vira ure vsakega usmerjevalnika, preden tunel prenesete v produkcijo, tako da se vam ni treba prijaviti v vsako napravo le zato, da preverite, ali je pripravljena.
Korak 1: Ustvarite profile in peer IKE
Na lokaciji A določite profile faze 1 in usmerite peer na javni naslov lokacije 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 je Diffie-Hellmanova skupina 14 — zanesljiva sodobna privzeta vrednost. exchange-mode=ike2 izbere IKEv2, ki je hitrejši in zanesljivejši od starega načina main/IKEv1. Oba konca morata uporabljati enake vrednosti profile in enak način izmenjave.
Korak 2: Dodajte identity (vnaprej deljeni ključ)
/ip ipsec identity add peer=siteB auth-method=pre-shared-key \ secret="<long-random-shared-secret>"Uporabite dolgo, naključno skrivnost in jo hranite tako, kot bi hranili ključ SSH — ne v sporočilu klepeta. Ista skrivnost gre na oba usmerjevalnika.
Korak 3: Določite proposal faze 2
/ip ipsec proposal add name=to-siteB auth-algorithms=sha256 \ enc-algorithms=aes-256-cbc pfs-group=modp2048Perfect Forward Secrecy (pfs-group) pomeni, da vsaka obnova ključa uporabi svež ključni material, tako da ogrožen ključ nikoli ne razkrije preteklega prometa. Tako kot pri fazi 1 se morajo algoritmi ujemati na obeh koncih.
Korak 4: Ustvarite policy tunela
Policy pove RouterOS, kateri promet naj šifrira — lokalni LAN proti oddaljenemu 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=encrypttunnel=yes je tisto, kar naredi povezavo site-to-site namesto gostitelj-gostitelj: izvirni paketi se ovijejo v celoti, tako da lahko oba LAN komunicirata pregledno.
Korak 5: Dodajte pravilo obhoda NAT (korak, ki ga vsi pozabijo)
Tu se zlomi večina prvih poskusov. Vaš usmerjevalnik že ima pravilo masquerade, ki prepiše izvorni naslov odhodnega prometa LAN. Če se sproži pred IPsec, oddaljeni konec prejme pakete, katerih izvor se ne ujema več s policy, in jih zavrže. Dodajte pravilo accept nad masquerade, da promet, namenjen tunelu, preskoči 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 postavi pravilo na sam vrh verige srcnat, kar je obvezno — pravilo obhoda, postavljeno za masquerade, ne naredi ničesar.
Korak 6: Odprite požarni zid in preverite
Dovolite vrata IKE in NAT-T ter protokol ESP v verigi input, da se tunel lahko vzpostavi, zlasti če je katera od lokacij za še eno napravo NAT:
/ip firewall filter add chain=input protocol=udp dst-port=500,4500 action=accept/ip firewall filter add chain=input protocol=ipsec-esp action=acceptNato potrdite, da tunel deluje:
/ip ipsec active-peers print/ip ipsec policy printZdrav tunel prikaže aktiven peer in policy, katerega ph2-state je established. Hiter ping z naprave v enem LAN na napravo v drugem dokaže dosegljivost od konca do konca.
Zrcalite konfiguracijo na lokaciji B
Ponovite vsak korak na lokaciji B z zamenjanimi naslovi: peer kaže na javni IP lokacije A, policy in obhod NAT pa uporabljata src-address=192.168.20.0/24 in dst-address=192.168.10.0/24. Profile, proposal, skrivnost identity in način IKEv2 ostanejo enaki. Ko se obe strani ujemata, se fazi 1 in 2 zaključita in tunel se vzpostavi.
Nasveti za varnost in delovanje
Naj bo RouterOS posodobljen — nedavne izdaje so prinesle popravke, ki zadevajo ujemanje certifikatov peer v IPsec/IKEv2, zato si tunel, ki je delal prejšnje četrtletje, zasluži ponovni preizkus po vsaki nadgradnji. Raje izberite IKEv2 s PFS kot stare privzete nastavitve IKEv1. Kjer je mogoče, z naraščanjem števila tunelov preidite z deljene skrivnosti na overjanje s certifikati, saj en uhajajoč vnaprej deljeni ključ prizadene vsako lokacijo, ki ga uporablja. In beležite stanje tunela nekje, kamor dejansko gledate: mrtva povezava site-to-site je nevidna, dokler nekdo ne poskusi doseči oddaljenega LAN in mu ne uspe.
V floti je tunel IPsec, ki tiho pade po razsinhronizaciji ure ali izpadu WAN, natanko tista vrsta okvare, ki jo stranka opazi pred vami. MKController zapolni to vrzel: vsak usmerjevalnik nadzoruje prek varnega odhodnega tunela, ki ne potrebuje javnega IP niti posredovanja vrat na napravi, hrani različične varnostne kopije konfiguracije, da lahko po slabi spremembi primerjate in obnovite delujoč blok IPsec, in lahko odpre zahtevek ob dogodku izpada povezave, preden zazvoni telefon. Za samo konfiguracijo tunela naš vodnik o NAT na MikroTiku pojasnjuje pravilo masquerade, ki ga tukaj obhajate, za dostop do enega usmerjevalnika namesto povezovanja dveh LAN pa si oglejte oddaljeno upravljanje za CGNAT in naš pregled oddaljenega upravljanja z WireGuard.
Združite svoje tunele pod eno streho
IPsec čisto poveže dve lokaciji, a rastoč ISP ali MSP ima kmalu na desetine tunelov, ključev in pravil požarnega zidu, ki jih mora usklajevati — in vsaka ročna sprememba je priložnost, da se zaklenete iz oddaljene lokacije. MKController je zgrajen prav za tak obseg: centralizirano upravljanje flote, varen oddaljeni dostop brez izpostavljenih vrat, zgodovina in varnostne kopije konfiguracije ter uvedba sprememb požarnega zidu in policy po vsej floti, tako da se predloga tunela uvede enkrat, namesto da bi jo pretipkavali usmerjevalnik za usmerjevalnikom. Operaterji, ki MikroTik uporabljajo v velikem obsegu, ga uporabljajo, da izgubljeno popoldne s SSH po napravah spremenijo v nekaj klikov na spremembo.