Remote Access
Ghid VPN IPsec site-to-site MikroTik
Construiți un VPN IPsec site-to-site MikroTik: configurați peer-ul IKEv2, proposal, policy și regula de bypass NAT care face tunelul să funcționeze.
Rezumat Un VPN IPsec site-to-site MikroTik criptează traficul dintre două rețele întregi — un sediu central și o filială, un NOC și o locație cu turn — astfel încât gazdele din fiecare LAN ajung la celălalt ca și cum ar fi locale. Acest ghid configurează ambele routere pe RouterOS v7: peer-ul IKEv2, identity cu cheie pre-partajată, proposal-ul Fazei 2, policy-ul tunelului, regula de bypass NAT care blochează majoritatea primelor încercări, precum și regulile de firewall și verificările care confirmă că tunelul este activ.
Ce este un VPN IPsec site-to-site MikroTik?
Un VPN IPsec site-to-site MikroTik este un tunel criptat permanent între două routere care unește două LAN-uri separate într-o singură rețea rutabilă la nivelul 3, fără ca vreun router să expună un port de management către internetul public. Spre deosebire de VPN-urile de acces client precum WireGuard sau OpenVPN — unde se conectează un singur dispozitiv de administrare —, un tunel site-to-site este mereu activ și merge de la subrețea la subrețea: fiecare gazdă din spatele Routerului A poate ajunge automat la fiecare gazdă permisă din spatele Routerului B. IPsec este instrumentul potrivit aici pentru că este un standard deschis susținut de practic orice producător de firewall și router, rulează în kernelul RouterOS pentru un debit bun, iar pe MikroTik este integrat, fără pachet suplimentar de instalat.
Tunelul se construiește prin două negocieri. Faza 1 (IKE) autentifică cele două routere reciproc și stabilește un canal securizat; Faza 2 (IPsec) negociază cheile care criptează efectiv traficul de date. Faceți ambele faze să coincidă la fiecare capăt și tunelul se ridică; lăsați un singur algoritm să difere și eșuează în tăcere — de aceea pașii de mai jos păstrează cele două părți simetrice.
Înainte de a începe
Aveți nevoie de două routere MikroTik cu RouterOS v7, fiecare cu o adresă IP publică sau un nume DDNS funcțional, și de două subrețele LAN care nu se suprapun. Acest ghid folosește 192.168.10.0/24 în Locația A și 192.168.20.0/24 în Locația B. Dacă ambele locații folosesc 192.168.88.0/24, rutarea este imposibilă — readresați mai întâi o parte. Deoarece IPsec este foarte sensibil la decalajul de ceas, activați NTP pe ambele routere înainte de a începe; dacă cele două capete se depărtează, security associations expiră și tunelul cade în mod repetat.
Gestionarea acestei condiții pe mai mult de câteva locații este deja o corvoadă. Când administrați o flotă, MKController vă oferă o singură consolă pentru a confirma versiunea RouterOS și sursa de ceas a fiecărui router înainte de a pune un tunel în funcțiune, astfel încât să nu vă conectați la fiecare dispozitiv doar pentru a verifica dacă este pregătit.
Pasul 1: Creați profile-ul și peer-ul IKE
În Locația A, definiți profile-ul Fazei 1 și îndreptați un peer spre adresa publică a Locației 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 este Grupul 14 Diffie-Hellman — o valoare implicită modernă și solidă. exchange-mode=ike2 selectează IKEv2, care este mai rapid și mai robust decât vechiul mod main/IKEv1. Ambele capete trebuie să folosească aceleași valori de profile și același mod de schimb.
Pasul 2: Adăugați identity (cheie pre-partajată)
/ip ipsec identity add peer=siteB auth-method=pre-shared-key \ secret="<long-random-shared-secret>"Folosiți un secret lung și aleatoriu și păstrați-l așa cum ați păstra o cheie SSH — nu într-un mesaj de chat. Același secret merge pe ambele routere.
Pasul 3: Definiți proposal-ul Fazei 2
/ip ipsec proposal add name=to-siteB auth-algorithms=sha256 \ enc-algorithms=aes-256-cbc pfs-group=modp2048Perfect Forward Secrecy (pfs-group) înseamnă că fiecare reînnoire de cheie folosește material de cheie proaspăt, astfel încât o cheie compromisă nu expune niciodată traficul trecut. Ca și în Faza 1, algoritmii trebuie să coincidă la ambele capete.
Pasul 4: Creați policy-ul tunelului
Policy-ul îi spune RouterOS ce trafic să cripteze — LAN-ul local către LAN-ul la distanță:
/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 este ceea ce face conexiunea site-to-site în loc de gazdă-la-gazdă: pachetele originale sunt împachetate în întregime, astfel încât cele două LAN-uri pot comunica transparent.
Pasul 5: Adăugați regula de bypass NAT (pasul pe care toată lumea îl uită)
Aici cad majoritatea primelor încercări. Routerul dumneavoastră are deja o regulă masquerade care rescrie adresa sursă a traficului LAN de ieșire. Dacă aceasta se declanșează înainte de IPsec, capătul la distanță primește pachete a căror sursă nu mai corespunde policy-ului și le respinge. Adăugați o regulă accept deasupra masquerade, astfel încât traficul destinat tunelului să ocolească 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 plasează regula chiar în vârful lanțului srcnat, ceea ce este obligatoriu — o regulă de bypass plasată după masquerade nu face nimic.
Pasul 6: Deschideți firewall-ul și verificați
Permiteți porturile IKE și NAT-T plus protocolul ESP în lanțul input pentru ca tunelul să se poată stabili, mai ales dacă vreuna dintre locații se află în spatele altui dispozitiv 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=acceptApoi confirmați că tunelul este activ:
/ip ipsec active-peers print/ip ipsec policy printUn tunel sănătos arată un peer activ și un policy al cărui ph2-state este established. Un ping rapid de la o gazdă dintr-un LAN către o gazdă din celălalt demonstrează accesibilitatea cap la cap.
Reproduceți configurația în Locația B
Repetați fiecare pas în Locația B cu adresele inversate: peer-ul indică spre IP-ul public al Locației A, iar policy-ul și bypass-ul NAT folosesc src-address=192.168.20.0/24 și dst-address=192.168.10.0/24. Profile-ul, proposal-ul, secretul identity și modul IKEv2 rămân identice. Când ambele părți coincid, Faza 1 și Faza 2 se finalizează și tunelul se ridică.
Sfaturi de securitate și operare
Mențineți RouterOS actualizat — versiunile recente au adus corecții care afectează potrivirea certificatelor peer în IPsec/IKEv2, așa că un tunel care funcționa trimestrul trecut merită un nou test după fiecare actualizare. Preferați IKEv2 cu PFS în locul valorilor implicite vechi IKEv1. Acolo unde puteți, treceți de la un secret partajat la autentificarea cu certificat pe măsură ce numărul de tuneluri crește, pentru că o singură cheie pre-partajată scursă afectează fiecare locație care o folosește. Și înregistrați starea tunelului undeva unde chiar vă uitați: o legătură site-to-site moartă este invizibilă până când cineva încearcă să ajungă la LAN-ul îndepărtat și nu reușește.
Într-o flotă, un tunel IPsec care cade în liniște după o desincronizare de ceas sau o întrerupere WAN este exact tipul de defecțiune pe care clientul o observă înaintea dumneavoastră. MKController acoperă acest gol: monitorizează fiecare router printr-un tunel securizat de ieșire care nu are nevoie de IP public și nici de redirecționare de porturi pe dispozitiv, păstrează copii de siguranță versionate ale configurației pentru a putea compara și restaura un bloc IPsec funcțional după o modificare greșită și poate deschide un tichet la un eveniment de cădere a legăturii înainte să sune telefonul. Pentru configurarea tunelului în sine, ghidul nostru despre NAT pe MikroTik explică regula masquerade pe care o ocoliți aici, iar pentru a ajunge la un singur router în loc să uniți două LAN-uri, consultați administrarea la distanță în spatele CGNAT și ghidul nostru despre administrarea la distanță cu WireGuard.
Aduceți-vă tunelurile sub același acoperiș
IPsec unește curat două locații, dar un ISP sau MSP în creștere are curând zeci de tuneluri, chei și reguli de firewall de menținut sincronizate — iar fiecare modificare manuală este o șansă de a vă bloca accesul la o locație la distanță. MKController este construit exact pentru această scară: management centralizat al flotei, acces la distanță securizat fără porturi expuse, istoric și copii de siguranță ale configurației și aplicarea modificărilor de firewall și policy la nivelul întregii flote, astfel încât un șablon de tunel se aplică o singură dată în loc să fie retastat router cu router. Operatorii care rulează MikroTik la scară îl folosesc pentru a transforma o după-amiază pierdută cu SSH pe fiecare dispozitiv în câteva clicuri per modificare.