Hub și spițe sau plasă completă: ce topologie VPN se potrivește siturilor tale

Două birouri de sucursală vorbesc toată ziua între ele, iar tunelul dintre ele ocolește printr-un centru de date din altă regiune. Fiecare cerere plătește de două ori pentru ocol, și nimeni nu observă până când sincronizarea fișierelor nu începe să pară greșită. Aici începe de fapt întrebarea despre topologie: nu cu ce diagramă pare mai rezilientă, ci cu ce model de trafic plătești. Ambele proiecte funcționează și ambele eșuează în moduri diferite, cu costuri diferite.

Numără relațiile dintre noduri înainte de orice

Cu N situri, o plasă completă are nevoie de N ori N minus unu, împărțit la doi, tuneluri; un hub are nevoie de N. La cinci situri înseamnă zece contra cinci, ceea ce încă sună gestionabil. La cincisprezece înseamnă 105 contra cincisprezece, iar diferența nu mai este aritmetică, ci de personal.

Fiecare dintre aceste relații poartă stare pe care trebuie să o administrezi. În IPsec asta înseamnă o asociere de securitate, o identitate, o cheie sau un certificat, detectarea nodului mort și cel puțin o rută pentru fiecare prefix remote. În WireGuard înseamnă o cheie publică și un bloc AllowedIPs pentru fiecare nod; mai ieftin pe nod, dar fără nicio descoperire: un sit nou este oricum o schimbare de configurație pe toate cele existente.

Lasă mixul de trafic să decidă, nu desenul

Dacă traficul sucursalelor constă în principal din cereri către un ERP central sau un cluster de fișiere, un hub nu este un compromis, ci forma corectă: traficul voia deja să meargă acolo, iar un singur punct de politică este mai ușor de auditat decât o plasă de reguli perechi. Plasa își merită complexitatea când sucursalele schimbă date între ele: replicare între două birouri, voce între situri, un partaj CAD pe care o duzină de ingineri îl deschid toată ziua.

Cazurile incomode stau la mijloc, și sunt majoritatea. Măsoară înainte să argumentezi, în loc să ghicești dintr-o organigramă.

Citește tabelul ca departajare, nu ca regulă. Trei din patru rânduri într-o direcție decid de obicei proiectul, iar o împărțire înseamnă hibrid, ceea ce majoritatea rețelelor mature ajung să ruleze.

Hubului trebuie să i se spună să redirecționeze

Două tuneluri funcționale spiță-hub nu creează acces între spițe. Hubul are nevoie de redirecționare IP activată, o rută către fiecare rețea de spiță, o regulă de firewall care permite tranzitul și calea de întoarcere rezolvată; fiecare spiță are nevoie de o rută către prefixele celuilalt sit. Pe un hub Linux asta este net.ipv4.ip_forward=1 plus un lanț FORWARD care nu aruncă perechea în tăcere, iar în IPsec bazat pe politici sunt selectori de trafic care listează subrețeaua spiței remote la ambele capete. strongSwan notele despre redirecționare acoperă partea de kernel și firewall când acela este stratul care îți lipsește. Un test ieftin este să trimiți trafic dintr-o spiță către un serviciu din cealaltă, urmărind contoarele hubului; o regulă care nu crește niciodată înseamnă că ordinea este greșită, nu ruta.

Politica centrală este și partea utilă. Sucursalelor li se poate permite să ajungă la servicii comune fără să ajungă una la alta, iar acea matrice de acces merită scrisă explicit. Rutele lipsă sunt un substitut slab pentru o regulă pe care cineva o poate citi.

Atenție la versiunea pe jumătate făcută: spița A rutează către spița B prin hub, hubul rutează în ambele sensuri, iar firewallul hubului permite conexiuni noi din A, dar nu din B. Prima direcție se testează bine, a doua se blochează, ceea ce pare o defecțiune de rutare și nu este.

Proiectează întâi defectarea, apoi calea normală

Un singur hub este o dependență comună și un blocaj de tranzit, iar redundanța este locul unde proiectele cu hub greșesc de obicei. Două huburi înseamnă că fiecare spiță ține două tuneluri, iar calea de întoarcere trebuie să fie de acord cu cea de ieșire; când nu este, un firewall cu stare aruncă răspunsurile, iar simptomul este o conexiune care se deschide și apoi moare. Implementările mari rezolvă asta cu un protocol de rutare peste tuneluri în loc de prefixe statice, ceea ce este mai mult mecanism, dar elimină ghicitul. Orice ai alege, scrie calea de întoarcere lângă cea de ieșire, pentru că jumătatea de întoarcere este cea pe care nimeni nu o testează.

O plasă împrăștie acel risc: căderea legăturii unui sit nu le izolează pe celelalte. Ea înmulțește însă și locurile în care selecția căii te poate surprinde, iar sesiunile aplicațiilor tot nu supraviețuiesc unei schimbări de cale fără ajutor.

Niciunul dintre proiecte nu ține singur o sesiune TCP în viață la un failover. Dacă aplicația nu se poate reconecta, topologia nu este problema ta.

Alege după costul schimbării, apoi verifică rutele

Începe cu hubul, pentru că este lucrul mai ieftin la care să greșești, și adaugă tuneluri directe pentru perechile al căror trafic le justifică. Acel hibrid nu este o eșuare de a decide; este proiectul la care majoritatea organizațiilor ajung într-un an. Contează ca fiecare legătură directă să aibă un motiv declarat și un proprietar.

Apoi verifică două desene, nu unul. Pentru calea normală, rulează traceroute de la fiecare sit la fiecare prefix de serviciu și confirmă că salturile corespund diagramei. Pentru calea de defectare, oprește un tunel și repetă, pentru că o rută care funcționează doar cât timp totul este pornit nu a fost proiectată, doar configurată.

Păstrează ambele desene împreună cu matricea de acces și revino la ele când se adaugă un sit; costul pe care îl gestionezi este costul următoarei schimbări, nu eleganța imaginii actuale.