Remote Access
MikroTik IPsec site-to-site VPN ceļvedis
Izveidojiet MikroTik IPsec site-to-site VPN: konfigurējiet IKEv2 peer, proposal, policy un NAT apiešanas noteikumu, kas liek tunelim darboties.
Kopsavilkums MikroTik IPsec site-to-site VPN šifrē datplūsmu starp divām veselām tīklu sistēmām — galveno biroju un filiāli, NOC un torņa vietu — tā, ka katra LAN ierīces sasniedz otru tā, it kā tās būtu vietējas. Šis ceļvedis konfigurē abus maršrutētājus ar RouterOS v7: IKEv2 peer, identity ar iepriekš koplietotu atslēgu, 2. fāzes proposal, tuneļa policy, NAT apiešanas noteikumu, kas izgāž lielāko daļu pirmo mēģinājumu, un ugunsmūra noteikumus un pārbaudes, kas apliecina, ka tunelis darbojas.
Kas ir MikroTik IPsec site-to-site VPN?
MikroTik IPsec site-to-site VPN ir pastāvīgs šifrēts tunelis starp diviem maršrutētājiem, kas apvieno divus atsevišķus LAN vienā maršrutējamā tīklā 3. slānī, nevienam maršrutētājam neatklājot pārvaldības portu publiskajam internetam. Atšķirībā no klientu piekļuves VPN, piemēram, WireGuard vai OpenVPN — kur pieslēdzas viena administratora ierīce —, site-to-site tunelis vienmēr ir aktīvs un darbojas no apakštīkla uz apakštīklu: katra ierīce aiz A maršrutētāja automātiski sasniedz katru atļauto ierīci aiz B maršrutētāja. IPsec šeit ir pareizais rīks, jo tas ir atvērts standarts, ko atbalsta praktiski katrs ugunsmūru un maršrutētāju ražotājs, tas darbojas RouterOS kodolā labai caurlaidspējai, un MikroTik tas ir iebūvēts bez papildu instalējamas pakotnes.
Tunelis tiek veidots divās sarunās. 1. fāze (IKE) autentificē abus maršrutētājus savstarpēji un izveido drošu kanālu; 2. fāze (IPsec) vienojas par atslēgām, kas patiešām šifrē jūsu datplūsmu. Panāciet, lai abas fāzes sakristu katrā galā, un tunelis pacelsies; lai atšķiras kaut viens algoritms, un tas klusi neizdodas — tāpēc turpmākie soļi saglabā abas puses simetriskas.
Pirms sākat
Jums nepieciešami divi MikroTik maršrutētāji ar RouterOS v7, katram ar publisku IP adresi vai strādājošu DDNS resursdatora nosaukumu, un divi nepārklājošies LAN apakštīkli. Šajā ceļvedī tiek izmantots 192.168.10.0/24 A vietā un 192.168.20.0/24 B vietā. Ja abas vietas izmanto 192.168.88.0/24, maršrutēšana nav iespējama — vispirms mainiet vienas puses adreses. Tā kā IPsec ir ļoti jutīgs pret pulksteņa nobīdi, pirms sākšanas iespējojiet NTP abos maršrutētājos; ja abi gali atšķiras, security associations beidzas un tunelis nepārtraukti krīt.
Šī priekšnosacījuma pārvaldība vairāk nekā dažās vietās jau ir apgrūtinājums. Kad pārvaldāt parku, MKController sniedz vienu konsoli, kurā apstiprināt katra maršrutētāja RouterOS versiju un pulksteņa avotu pirms tuneļa nodošanas ekspluatācijā, tāpēc jums nav jāpieslēdzas katrai ierīcei tikai tāpēc, lai pārliecinātos, ka tā ir gatava.
1. solis: izveidojiet IKE profile un peer
A vietā definējiet 1. fāzes profile un norādiet peer uz B vietas publisko adresi:
/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 ir Diffie-Hellman 14. grupa — stabila mūsdienīga noklusējuma vērtība. exchange-mode=ike2 izvēlas IKEv2, kas ir ātrāks un noturīgāks nekā vecais main/IKEv1 režīms. Abiem galiem jāizmanto vienādas profile vērtības un viens un tas pats apmaiņas režīms.
2. solis: pievienojiet identity (iepriekš koplietota atslēga)
/ip ipsec identity add peer=siteB auth-method=pre-shared-key \ secret="<long-random-shared-secret>"Izmantojiet garu, nejaušu noslēpumu un glabājiet to tāpat, kā glabātu SSH atslēgu — nevis tērzēšanas ziņojumā. Tas pats noslēpums tiek ievadīts abos maršrutētājos.
3. solis: definējiet 2. fāzes proposal
/ip ipsec proposal add name=to-siteB auth-algorithms=sha256 \ enc-algorithms=aes-256-cbc pfs-group=modp2048Perfect Forward Secrecy (pfs-group) nozīmē, ka katra atslēgas atjaunošana izmanto svaigu atslēgas materiālu, tāpēc kompromitēta atslēga nekad neatklāj iepriekšējo datplūsmu. Tāpat kā 1. fāzē, algoritmiem jāsakrīt abos galos.
4. solis: izveidojiet tuneļa policy
Policy norāda RouterOS, kuru datplūsmu šifrēt — vietējo LAN uz attālo 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 ir tas, kas padara šo savienojumu par site-to-site, nevis host-to-host: sākotnējās paketes tiek ietītas veselas, tāpēc abi LAN var sazināties caurspīdīgi.
5. solis: pievienojiet NAT apiešanas noteikumu (solis, ko visi aizmirst)
Tieši šeit sabrūk lielākā daļa pirmo mēģinājumu. Jūsu maršrutētājam jau ir masquerade noteikums, kas pārraksta izejošās LAN datplūsmas avota adresi. Ja tas nostrādā pirms IPsec, attālais gals saņem paketes, kuru avots vairs neatbilst policy, un tās atmet. Pievienojiet accept noteikumu virs masquerade, lai uz tuneli virzītā datplūsma izlaistu 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 novieto noteikumu pašā srcnat ķēdes augšgalā, kas ir obligāti — apiešanas noteikums, kas novietots pēc masquerade, neko nedara.
6. solis: atveriet ugunsmūri un pārbaudiet
Atļaujiet IKE un NAT-T portus un ESP protokolu input ķēdē, lai tunelis varētu izveidoties, īpaši ja kāda no vietām atrodas aiz vēl viena NAT ierīces:
/ip firewall filter add chain=input protocol=udp dst-port=500,4500 action=accept/ip firewall filter add chain=input protocol=ipsec-esp action=acceptPēc tam apstipriniet, ka tunelis ir aktīvs:
/ip ipsec active-peers print/ip ipsec policy printVesels tunelis rāda aktīvu peer un policy, kuras ph2-state ir established. Ātrs ping no vienas LAN ierīces uz otras LAN ierīci pierāda sasniedzamību no gala līdz galam.
Atspoguļojiet konfigurāciju B vietā
Atkārtojiet katru soli B vietā ar apmainītām adresēm: peer norāda uz A vietas publisko IP, bet policy un NAT apiešana izmanto src-address=192.168.20.0/24 un dst-address=192.168.10.0/24. Profile, proposal, identity noslēpums un IKEv2 režīms paliek identiski. Kad abas puses sakrīt, 1. un 2. fāze noslēdzas un tunelis paceļas.
Drošības un ekspluatācijas ieteikumi
Uzturiet RouterOS atjauninātu — nesenajos laidienos iekļauti labojumi, kas skar IPsec/IKEv2 peer sertifikātu atbilstību, tāpēc tunelis, kas darbojās pagājušajā ceturksnī, ir vērts atkārtotu pārbaudi pēc katras jaunināšanas. Dodiet priekšroku IKEv2 ar PFS, nevis vecajiem IKEv1 noklusējumiem. Kur iespējams, pieaugot tuneļu skaitam, pārejiet no koplietota noslēpuma uz sertifikātu autentifikāciju, jo viena noplūdusi iepriekš koplietota atslēga ietekmē katru vietu, kas to izmanto. Un reģistrējiet tuneļa stāvokli kaut kur, kur patiešām skatāties: miris site-to-site savienojums ir neredzams, līdz kāds mēģina sasniegt attālo LAN un nevar.
Parkā IPsec tunelis, kas klusi krīt pēc pulksteņa desinhronizācijas vai WAN pārtraukuma, ir tieši tāda kļūme, ko klients pamana pirms jums. MKController aizpilda šo robu: tas uzrauga katru maršrutētāju caur drošu izejošu tuneli, kam nav vajadzīga ne publiska IP, ne portu pāradresācija ierīcē, uztur versionētas konfigurācijas rezerves kopijas, lai pēc neveiksmīgas rediģēšanas varētu salīdzināt un atjaunot strādājošu IPsec bloku, un var atvērt pieteikumu par savienojuma pārtraukuma notikumu, pirms iezvanās telefons. Par pašu tuneļa konfigurāciju mūsu ceļvedis par NAT MikroTik ierīcēs skaidro masquerade noteikumu, ko šeit apejat, bet, lai piekļūtu vienam maršrutētājam, nevis savienotu divus LAN, skatiet attālo pārvaldību aiz CGNAT un mūsu attālās pārvaldības ar WireGuard pamācību.
Apvienojiet savus tuneļus zem viena jumta
IPsec tīri savieno divas vietas, bet augošam ISP vai MSP drīz ir desmitiem tuneļu, atslēgu un ugunsmūra noteikumu, kas jātur sinhronizēti — un katra manuāla rediģēšana ir iespēja izslēgt sevi no attālas vietas. MKController ir veidots tieši šādam mērogam: centralizēta parka pārvaldība, droša attālā piekļuve bez atvērtiem portiem, konfigurācijas vēsture un rezerves kopijas, kā arī ugunsmūra un policy izmaiņu izvietošana visā parkā, tāpēc tuneļa veidne tiek izvietota vienreiz, nevis pārrakstīta maršrutētāju pēc maršrutētāja. Operatori, kas MikroTik darbina lielā mērogā, to izmanto, lai zaudētu pēcpusdienu ar SSH katrai ierīcei pārvērstu dažos klikšķos uz vienu izmaiņu.