Blog
WireGuard pe MikroTik: Windows, două sedii și Android
- octombrie 26, 2026
- Posted by: admin@academia-mikrotik.ro
- Category: Technology

Ai nevoie să ajungi de pe laptop la un server din sediu, să conectezi două birouri sau să accesezi o resursă internă de pe telefon? În acest ghid configurăm WireGuard pe MikroTik pentru trei situații: Windows–MikroTik, MikroTik–MikroTik și Android–MikroTik.
Folosim o topologie de exemplu, cu rețele separate și chei generate pe fiecare dispozitiv. Laptopul și telefonul primesc acces la LAN-ul sediului A prin split tunnel: doar destinațiile indicate trec prin VPN. Legătura dintre sedii transportă traficul dintre cele două LAN-uri.
Înainte de aplicare: exemplele sunt verificate în documentația oficială, fără testare pe echipamente în cadrul acestui articol. Adaptează-le și validează-le într-un laborator înainte de producție. Lucrează cu o copie de siguranță și acces local de recuperare. Comenzile add se execută o singură dată; repetarea lor poate crea intrări duplicate.
Planul rețelei · Windows–MikroTik · MikroTik–MikroTik · Android–MikroTik · Verificare și depanare
1. Planul rețelei și condițiile de pornire
Alege o versiune RouterOS 7 din canalul Stable, validată pentru echipamentele tale. Ghidul folosește IPv4, o singură conexiune WAN și tabela principală de rutare. Configurațiile cu multi-WAN, VRF sau rutare prin politici necesită adaptări.
| Element | Valoare în exemplu |
|---|---|
| LAN sediul A / gateway R1 | 192.168.10.0/24 / 192.168.10.1 |
| LAN sediul B / gateway R2 | 192.168.20.0/24 / 192.168.20.1 |
| VPN pentru laptop și telefon | 10.77.0.0/24; R1: .1, Windows: .2, Android: .3 |
| Tunel între sedii | 10.78.0.0/30; R1: .1, R2: .2 |
| Endpoint public R1 | vpn.example.com — înlocuiește cu IP-ul sau numele tău DNS |
| Porturi UDP pe R1 | 51820 pentru clienți; 51821 pentru sediul B |
Rețelele din tabel trebuie să fie libere în infrastructura ta și să nu se suprapună cu rețeaua din care se conectează laptopul sau telefonul. R1 și R2 sunt gateway-urile LAN-urilor lor. Dacă folosești alte gateway-uri, pregătește și rutele de retur către rețelele VPN și sediul opus.
În această topologie, R1 trebuie să poată primi UDP din Internet. Dacă este în spatele unui router pe care îl administrezi, redirecționează porturile necesare către R1. Dacă R1 este în spatele CGNAT și nu ai o redirecționare disponibilă, rezolvă mai întâi accesibilitatea cu furnizorul sau folosește un hub public. Un nume DNS nu înlocuiește accesul până la port. R2 poate iniția conexiunea către R1 din spatele NAT.
Instalează clienții Windows și Android folosind pagina oficială WireGuard. Fiecare dispozitiv va avea propria cheie privată; între dispozitive copiem numai cheile publice.

2. Configurare Windows–MikroTik
Creează interfața pe R1
În terminalul RouterOS rulează:
/interface/wireguard/add name=wg-remote listen-port=51820
/ip/address/add address=10.77.0.1/24 interface=wg-remote
:put [/interface/wireguard/get [find name="wg-remote"] public-key]
La crearea interfeței, RouterOS generează cheia privată dacă nu îi furnizezi una. Ultima comandă afișează doar cheia publică, pe care o vei folosi pe laptop și telefon. Parametrii sunt descriși în referința interfeței WireGuard.
Creează tunelul pe Windows și înregistrează laptopul
- Deschide aplicația WireGuard și creează un tunel gol: Add empty tunnel sau Ctrl+N.
- Numește-l
Academia-Sediu-A. Păstrează cheia privată generată local și copiază cheia publică afișată. - Pe R1, adaugă peer-ul laptopului, înlocuind marcajul de mai jos:
/interface/wireguard/peers/add interface=wg-remote public-key="CHEIA_PUBLICA_WINDOWS" allowed-address=10.77.0.2/32 comment="WG-Windows"
Completează configurația Windows astfel. Marcajele pentru chei și domeniul de exemplu trebuie înlocuite înainte de salvare:
[Interface]
PrivateKey = CHEIA_PRIVATA_GENERATA_PE_WINDOWS
Address = 10.77.0.2/32
[Peer]
PublicKey = CHEIA_PUBLICA_R1_WG_REMOTE
Endpoint = vpn.example.com:51820
AllowedIPs = 10.77.0.1/32, 192.168.10.0/24
PersistentKeepalive = 25
PersistentKeepalive = 25 este util când clientul se află în spatele NAT și trebuie să mențină asocierea activă. Nu este o cerință pentru orice rețea; vezi explicația din WireGuard Quick Start. Pașii aplicației Windows sunt documentați și în ghidul MikroTik.
Permite traficul necesar în firewall
În WinBox, deschide IP → Firewall → Filter Rules. Tabelul de mai jos descrie reguli de adăugat pe R1, nu înlocuiește întregul firewall. Lista WAN trebuie să conțină interfața reală de Internet, inclusiv interfața PPPoE sau LTE dacă este cazul.
Ordinea contează: păstrează regulile existente pentru established,related și eliminarea traficului invalid. Plasează grupul de reguli VPN înaintea regulilor generale care ar accepta sau ar bloca același trafic. În fiecare grup, regulile accept sunt înaintea regulilor drop. Verifică poziția înainte să activezi regulile. input controlează accesul la router, iar forward traficul prin router, conform documentației firewall MikroTik.
| Chain / Action | Condiții | Scop |
|---|---|---|
| input / accept | in-interface-list=WAN; protocol=udp; dst-port=51820 | Conexiunea WireGuard din Internet |
| input / accept | in-interface=wg-remote; src-address=10.77.0.0/24; protocol=icmp | Ping către R1 pentru verificare |
| input / drop | in-interface=wg-remote | Blochează celelalte conexiuni către router prin acest tunel |
| forward / accept | in-interface=wg-remote; src-address=10.77.0.0/24; dst-address=192.168.10.0/24 | Accesul clienților VPN la LAN A |
| forward / drop | in-interface=wg-remote | Blochează alte destinații inițiate prin VPN |
| forward / drop | out-interface=wg-remote | Blochează conexiuni noi inițiate către clienți; răspunsurile trec prin established,related |
Acest exemplu permite clienților acces la întregul LAN A. Pentru acces doar la un server sau serviciu, restrânge regula forward / accept la adresa și porturile necesare. Pentru administrarea R1 prin WinBox, adaugă separat, înaintea regulii input / drop, o permisiune TCP 8291 doar pentru IP-ul VPN al administratorului și verifică restricțiile serviciului din IP → Services.
Nu adăuga wg-remote în lista LAN dacă vrei să păstrezi aceste permisiuni distincte. Configurația presupune că NAT-ul existent se aplică ieșirii spre Internet, nu traficului dintre VPN și LAN. Nu este necesar un nou masquerade pentru acest traseu rutat.
Salvează configurația Windows, apasă Activate, apoi verifică ping 10.77.0.1 și accesul la un serviciu autorizat din 192.168.10.0/24.
3. Configurare MikroTik–MikroTik între două sedii
Folosim o interfață separată, wg-sediu. R2 inițiază conexiunea, iar R1 învață endpoint-ul lui R2 din traficul autentificat. Rețelele locale trebuie să aibă adrese diferite.
Interfețe și chei
Pe R1, sediul A:
/interface/wireguard/add name=wg-sediu listen-port=51821
/ip/address/add address=10.78.0.1/30 interface=wg-sediu
:put [/interface/wireguard/get [find name="wg-sediu"] public-key]
Pe R2, sediul B:
/interface/wireguard/add name=wg-sediu listen-port=51821
/ip/address/add address=10.78.0.2/30 interface=wg-sediu
:put [/interface/wireguard/get [find name="wg-sediu"] public-key]
Peer-uri și rute
Pe R1, introdu cheia publică a interfeței wg-sediu de pe R2:
/interface/wireguard/peers/add interface=wg-sediu public-key="CHEIA_PUBLICA_R2_WG_SEDIU" allowed-address=10.78.0.2/32,192.168.20.0/24 comment="WG-Sediu-B"
/ip/route/add dst-address=192.168.20.0/24 gateway=wg-sediu comment="WG-LAN-B"
Pe R2, introdu cheia publică a interfeței wg-sediu de pe R1:
/interface/wireguard/peers/add interface=wg-sediu public-key="CHEIA_PUBLICA_R1_WG_SEDIU" allowed-address=10.78.0.1/32,192.168.10.0/24 endpoint-address=vpn.example.com endpoint-port=51821 persistent-keepalive=25s comment="WG-Sediu-A"
/ip/route/add dst-address=192.168.10.0/24 gateway=wg-sediu comment="WG-LAN-A"
Allowed-address și ruta au roluri diferite. Peer-ul identifică ce adrese sunt asociate celuilalt capăt, iar ruta trimite traficul către interfața tunelului. Subrețelele peer-urilor de pe aceeași interfață nu trebuie să se suprapună. Consultă referințele oficiale pentru peer-uri și rute.
Firewall pe ambele routere
Aplică aceeași regulă de poziționare ca în secțiunea Windows. Pe R1 permite suplimentar în input UDP 51821 din lista WAN. Pe R2 permite ieșirea UDP către endpoint-ul R1; pentru modelul în care R2 inițiază tunelul, răspunsurile sunt acceptate de regula existentă established,related, fără publicarea unui port nou pe routerul din amonte.
| Router | forward / accept — sens spre celălalt sediu | forward / accept — sens din tunel |
|---|---|---|
| R1 | out-interface=wg-sediu; src-address=192.168.10.0/24; dst-address=192.168.20.0/24 | in-interface=wg-sediu; src-address=192.168.20.0/24; dst-address=192.168.10.0/24 |
| R2 | out-interface=wg-sediu; src-address=192.168.20.0/24; dst-address=192.168.10.0/24 | in-interface=wg-sediu; src-address=192.168.10.0/24; dst-address=192.168.20.0/24 |
După aceste permisiuni, pe fiecare router adaugă în forward câte o regulă drop pentru in-interface=wg-sediu și una pentru out-interface=wg-sediu, înaintea acceptărilor generale. Pentru diagnostic, în input permite ICMP pe wg-sediu doar de la IP-ul de tunel al celuilalt router, apoi blochează celelalte intrări prin această interfață. Ajustează explicit dacă ai nevoie de administrare între sedii.
În acest exemplu, niciun NAT nu trebuie să modifice traficul dintre LAN-uri. Un masquerade limitat la WAN nu îl afectează; o regulă generală de src-nat poate necesita excepții înaintea ei. Verifică și firewall-ul serverelor sau stațiilor la care vrei să ajungi. Contextul pentru NAT limitat la interfața de Internet este explicat în documentația MikroTik.
Testează între două stații din LAN-urile A și B. Pentru un test pornit chiar de pe R1, indică sursa LAN, care corespunde regulilor de mai sus:
/ping 192.168.20.50 src-address=192.168.10.1 count=4
192.168.20.50 trebuie înlocuit cu o stație reală care permite ICMP. Adăugarea legăturii dintre sedii nu acordă automat laptopului și telefonului acces la LAN B; configurațiile lor din acest ghid includ doar LAN A.
4. Configurare Android–MikroTik
Telefonul folosește interfața wg-remote și regulile deja pregătite pe R1. Are însă o cheie proprie și IP-ul 10.77.0.3/32. Nu reutiliza configurația laptopului pe telefon.
- În aplicația WireGuard pentru Android, apasă + și alege crearea unui tunel de la zero, denumită Create from scratch în interfața engleză.
- În zona Interface, setează un nume, generează perechea de chei și introdu la Addresses
10.77.0.3/32. Copiază cheia publică a telefonului. - Adaugă peer-ul telefonului pe R1 cu comanda de mai jos.
- Pe telefon, adaugă peer-ul R1 cu valorile din tabel, salvează și activează tunelul. Acceptă solicitarea Android de creare a conexiunii VPN.
/interface/wireguard/peers/add interface=wg-remote public-key="CHEIA_PUBLICA_ANDROID" allowed-address=10.77.0.3/32 comment="WG-Android"
| Câmp peer în Android | Valoare |
|---|---|
| Public key | Cheia publică R1 de pe wg-remote |
| Endpoint | vpn.example.com:51820, înlocuit cu endpoint-ul tău |
| Allowed IPs | 10.77.0.1/32, 192.168.10.0/24 |
| Persistent keepalive | 25 secunde pentru acest scenariu cu NAT |
Aplicația acceptă și import din fișier sau cod QR. Dacă folosești un QR generat dintr-o configurație, tratează-l ca pe cheia privată pe care o poate conține: păstrează-l doar între administrator și dispozitivul destinat. Nu îl publica în capturi sau în servicii publice de generare QR. Opțiunile de creare și import sunt prezente în resursele aplicației oficiale Android.
Pentru test, oprește Wi-Fi și folosește datele mobile. Accesează o resursă permisă din LAN A prin IP. Exemplele nu stabilesc un DNS intern; pentru nume interne ai nevoie separat de un resolver accesibil prin tunel și de regulile aferente. Internetul obișnuit și traficul IPv6 nu sunt direcționate prin aceste configurații IPv4.
5. Cum verifici și unde cauți problema
În WireGuard → Peers, urmărește last-handshake, rx și tx după ce generezi trafic. Un handshake recent arată că peer-urile au comunicat, dar accesul la serverele din LAN trebuie verificat separat.
| Simptom | Verificare recomandată |
|---|---|
| Nu apare handshake | Cheile publice, endpoint-ul, rezolvarea DNS, portul UDP, firewall-ul de intrare și eventuala redirecționare din amonte. |
| Handshake există, LAN-ul nu răspunde | Allowed IPs/allowed-address, rutele în ambele sensuri, gateway-ul stației și regulile forward. |
| O stație răspunde, alta nu | Firewall-ul și serviciul de pe stația destinație; un ping blocat nu înseamnă automat tunel defect. |
| IP-ul funcționează, numele nu | Resolverul DNS folosit de client și accesul la DNS-ul intern. |
| Trafic mic trece, aplicația se blochează | Investighează MTU/PMTUD pe traseu și dimensiunea pachetelor; nu presupune că schimbarea cheilor rezolvă problema. |
Pentru fiecare dispozitiv păstrează o fișă cu IP-ul VPN, cheia publică, proprietarul și permisiunile acordate. Dacă un telefon sau laptop este pierdut, dezactivează peer-ul asociat pe R1 și verifică eventualele conexiuni deja urmărite de firewall.
Cu aceste trei scenarii ai o bază pentru acces de la distanță și legături între sedii. Următorul pas este să restrângi accesul la serviciile de care ai efectiv nevoie și să documentezi testele. Pentru pregătirea intervențiilor, citește și ghidul de actualizare RouterOS sau continuă studiul în cartea online Academia MikroTik.
Verificat documentar la 26 octombrie 2026. Canal vizat pentru implementare: Stable; referința RouterOS consultată afișează versiunea 7.26. Nu au fost efectuate teste de laborator pe o versiune binară. Adresele și marcajele de chei sunt exemple. Coperta este o ilustrație conceptuală generată cu AI, iar schema reprezintă topologia acestui articol.
