Un client cu doua locatii avea nevoie de o retea unica, redundanta si securizata intre ele — fara sa depinda de un singur ISP sau de un singur server. Am construit in fiecare site un server Linux care face rutare, trunk VLAN, dual-ISP cu failover instant, VPN bridge L2 intre VLAN-uri, intreg stack-ul de securitate si virtualizare KVM — plus un server de backup care preia productia in 15 minute. Proiect implementat in februarie 2020, pe Debian 10, cu Suricata 5.
Contextul
La inceput, fiecare locatie avea cate un Mikrotik pentru rutare si VLAN-uri, cu un singur ISP. Functiona, dar avea limite clare:
- Un singur ISP per site — daca pica providerul, locatia ramanea izolata
- Fara conectivitate L2 unitara intre cele doua locatii — VLAN-urile nu se "vedeau" intre site-uri
- Securitate minima la perimetru — fara IPS, fara blocare dinamica de atacuri, fara vizibilitate pe trafic
- Fara redundanta de server — un singur punct de cedare per locatie
Clientul voia ca cele doua locatii sa functioneze ca o singura retea, sa reziste la caderea unui ISP sau a unui server si sa fie protejate real la perimetru.
Provocarea
Trebuia sa legam cele doua locatii la nivel L2 — fiecare VLAN sa se comporte ca si cum ambele site-uri ar fi in aceeasi cladire — cu redundanta de ISP si de server, perimetru de securitate puternic si fara downtime la o cadere. Totul fara sa schimbam adresarea sau aplicatiile din spate.
Solutia / Arhitectura
In fiecare site am instalat un server Debian Linux care preia si extinde rolul vechiului Mikrotik. Acelasi server face simultan: router, trunk VLAN, terminator VPN, firewall, IPS si host de virtualizare.
- Trunk VLAN (802.1Q) — serverul are o interfata trunk cu toate VLAN-urile; pe el se fac rutarile si regulile de acces interne intre VLAN-uri si intre site-uri
- Dual-ISP — doi provideri pe fiecare server, pentru redundanta de internet
- OpenVPN in mod bridge (L2) — o instanta de OpenVPN per VLAN, asa ca fiecare VLAN se intinde la nivel L2 peste ambele locatii
- Virtualizare KVM — VM-uri pe fiecare server, cu configuratiile sincronizate intre site-uri
- Server de backup in fiecare locatie, gata sa preia productia
Hardware si infrastructura
Fiecare site e o fabrica cu sute de end-point-uri — PC-uri, masini de productie si dispozitive IoT — toate pe reteaua interna. Serverul principal din fiecare locatie e un Dell PowerEdge R640 (14th gen, 1U, dual-CPU, 128 GB RAM), cu 4 porturi 1GbE agregate in port-channel LACP distribuite activ pe doua switch-uri Dell N1500 in stiva — redundanta completa la nivel de switch core. Daca cade un switch, traficul continua fara intrerupere pe celalalt. Cele 2x 10GbE asigura conectivitatea dual-ISP. Serverul de backup din fiecare site e un Dell PowerEdge R730 (13th gen, achizitionat in 2017), cu aceeasi configuratie de NIC-uri si conectivitate — hardware mai vechi, dar arhitectura identica.
Implementarea
Pasul 1 — Serverul Linux ca router + trunk VLAN
Serverul Debian a preluat rolul Mikrotik-ului, dar cu mult mai multa putere. Pe interfata trunk 802.1Q ajung toate VLAN-urile, iar pe server se fac rutarile si regulile de acces interne — cine vede pe cine, intre VLAN-uri si intre cele doua locatii. Segmentarea ramane curata, dar controlata dintr-un singur loc.
Pasul 2 — Dual-ISP cu failover instant
Fiecare server are doi ISP. Daca un provider pica, conexiunile OpenVPN se muta instant pe celalalt ISP — tunelul intre locatii nu se intrerupe vizibil pentru utilizatori. Un cablu taiat sau o pana la un provider nu mai izoleaza o locatie.
Pasul 3 — VPN bridge L2 intre VLAN-uri
Conectivitatea intre cele doua locatii se face prin OpenVPN in mod bridge, cu o instanta separata pentru fiecare VLAN. Practic, fiecare VLAN se intinde la nivel L2 peste ambele site-uri — un dispozitiv dintr-o locatie e in aceeasi retea cu unul din cealalta, ca si cum ar fi in acelasi switch. Aplicatiile care presupun aceeasi retea locala functioneaza fara modificari.
De ce 12 instante OpenVPN si nu una singura
O obiectie pe care o auzim des: un bridge L2 per VLAN, cu o instanta OpenVPN separata pentru fiecare, ar trebui sa fie greoi. In practica nu e. Rulam 12 instante OpenVPN in mod bridge, una per VLAN, si sistemul merge fara probleme in productie din februarie 2020 incoace. Separarea pe instante e de fapt un avantaj: fiecare VLAN are propriul tunel izolat, propriul proces, propriul set de chei — daca pica sau se reconfigureaza unul, restul nu sunt afectate. Depanarea e mult mai simpla decat intr-un singur tunel care cara tot traficul. Broadcast-ul si ARP-ul raman izolate per VLAN. La nevoie scalam adaugand inca o instanta pentru un VLAN nou, fara sa atingem restul.
Pasul 4 — Virtualizare KVM cu config sincronizat
Pe fiecare server ruleaza KVM, iar VM-urile au configuratiile sincronizate intre cele doua locatii. Un serviciu poate fi pornit in cealalta locatie cu aceeasi configuratie, fara reconstructie manuala.
Securitatea — perimetru pe fiecare server
Fiecare server Linux e si firewall, si IPS, si punct de vizibilitate. Stack-ul de securitate e identic in ambele locatii:
- Suricata IPS — inspectie profunda a pachetelor; detecteaza si blocheaza tentativele de exploit inainte sa atinga retelele interne
- ipset cu liste dinamice — blocare la nivel de kernel, foarte rapida, a unor liste mari de IP-uri care se actualizeaza dinamic (feed-uri de amenintari, reputatie IP) — atacatorii sunt taiati la poarta
- GeoIP filtering — filtrare la nivel de tara, reduce suprafata de atac din regiunile de unde nu vin utilizatori legitimi
- nftables — firewall-ul de baza pe fiecare server, cu reguli stricte de acces intre VLAN-uri si catre exterior
- Fail2ban — blocheaza automat IP-urile care incearca brute-force pe servicii (SSH si altele)
Disponibilitate si failover
Redundanta e pe trei niveluri: ISP, server si site.
- ISP — failover instant intre cei doi provideri pe fiecare server; tunelele OpenVPN nu se intrerup vizibil
- Server — in fiecare locatie exista un server de backup care intra automat in productie dupa 15 minute de la caderea serverului main, sau imediat printr-o comanda care cere confirmare
- Site — cele doua locatii se acopera reciproc la nivel de retea si monitorizare
De ce 15 minute si nu instant? Pentru ca exista ferestre de mentenanta in care se fac upgrade-uri de sistem de operare, iar un reboot planificat dureaza ~5 minute. Un failover instant ar promova serverul de backup la fiecare reboot — fals pozitiv. Pragul de 15 minute lasa serverul main sa termine un reboot normal fara sa declanseze failover-ul. Iar cand vrei sa preiei controlul manual, exista o comanda care cere confirmare — deci failover-ul nu se poate executa accidental.
Intre serverul main si cel de backup din fiecare site exista sincronizare continua de configuratii: orice regula de firewall, rutare sau acces modificata pe serverul main se propaga automat si pe serverul de backup. Asa, cand backup-ul preia productia, o face cu exact aceeasi configuratie — fara surprize si fara reconfigurare manuala.
Monitorizare — Nagios redundant
Serverele Linux au si rol de Nagios. Monitorizarea ruleaza pe serverele main din fiecare site, dar pentru ca avem doua locatii care se vad la nivel L2, daca pica un server main, Nagios din cealalta locatie preia monitorizarea — nu ramai orb tocmai cand ai un incident.
Rezultatul
- ✅ Cele doua locatii functioneaza ca o singura retea L2 — un VPN bridge per VLAN, transparent pentru aplicatii
- ✅ Dual-ISP cu failover instant — caderea unui provider nu mai izoleaza o locatie
- ✅ Redundanta de server — backup care intra in productie in 15 minute sau la comanda, cu confirmare
- ✅ Perimetru de securitate complet: Suricata IPS + ipset cu liste dinamice + GeoIP + nftables + Fail2ban, identic in ambele site-uri
- ✅ Monitorizare Nagios redundanta — un site acopera celalalt
- ✅ Vechile Mikrotik-uri consolidate intr-un singur server Linux per site, care face tot: rutare, VLAN, VPN, securitate, virtualizare
Ai mai multe locatii care trebuie sa functioneze ca una singura?
Construim retele multi-site redundante: conectivitate L2/L3 intre locatii, dual-ISP cu failover, perimetru de securitate identic peste tot, virtualizare si server de rezerva care preia productia in minute. Fara dependenta de un singur ISP, un singur server sau o singura locatie.