Hvězda, nebo úplná síť: která topologie VPN se hodí pro vaše lokality

Dvě pobočky spolu mluví celý den a tunel mezi nimi zajíždí přes datové centrum v jiném regionu. Každý požadavek platí za tuto okliku dvakrát a nikdo si toho nevšimne, dokud synchronizace souborů nezačne působit špatně. Právě tady otázka topologie skutečně začíná: ne tím, které schéma vypadá odolněji, ale tím, za jaký vzor provozu platíte. Oba návrhy fungují a selhávají různými způsoby za různých nákladů.

Nejdřív spočítejte vztahy mezi uzly

Při N lokalitách potřebuje úplná síť N krát N mínus jedna, děleno dvěma, tunelů; hub potřebuje N. Při pěti lokalitách je to deset proti pěti, což ještě zní zvládnutelně. Při patnácti je to 105 proti patnácti a rozdíl už není aritmetický, ale personální.

Každý z těchto vztahů nese stav, který musíte vlastnit. V IPsec to znamená bezpečnostní asociaci, identitu, klíč nebo certifikát, detekci mrtvého uzlu a alespoň jednu trasu pro každý vzdálený prefix. Ve WireGuardu to znamená veřejný klíč a AllowedIPs blok pro každého partnera, což je na partnera levnější, ale přichází zcela bez objevování: nová lokalita je tak jako tak změna konfigurace na každé stávající.

Ať rozhoduje směs provozu, ne kresba

Pokud je provoz poboček převážně požadavky na centrální ERP nebo souborový cluster, hub není kompromis, je to správný tvar: provoz už tam chtěl jít a jeden politický bod se audituje snáz než síť párových pravidel. Úplná síť si svou složitost zaslouží, když pobočky vyměňují data mezi sebou — replikace mezi dvěma kancelářemi, hlas mezi lokalitami, sdílený CAD, který desítky inženýrů otevírají celý den.

Nepříjemné případy leží uprostřed a jsou většinou. Měřte, než se začnete hádat, místo abyste hádali z organizačního schématu.

Čtěte tabulku jako rozřazovací kritérium, ne jako pravidlo. Tři ze čtyř řádků jedním směrem obvykle návrh rozhodnou; rozdělení znamená hybrid, ke kterému většina zralých sítí stejně dospěje.

Hubu se musí říct, aby přeposílal

Dva funkční tunely spoke-hub nevytvářejí přístup spoke-spoke. Hub potřebuje zapnuté IP přeposílání, trasu do každé sítě spoke, pravidlo firewallu, které povolí tranzit, a spočítanou zpáteční cestu; každý spoke potřebuje trasu pro prefixy druhé lokality. Na Linux hubu je to net.ipv4.ip_forward=1 plus FORWARD řetěz, který pár tiše nezahodí, a u IPsec založeného na politikách to jsou selektory provozu, které na obou koncích vypisují vzdálenou podsíť spoke. U strongSwanu poznámky k přeposílání pokrývají stranu jádra a firewallu, když je to vrstva, která vám chybí. Levný test je poslat provoz z jednoho spoke na službu na druhém a sledovat počítadla hubu; pravidlo, které nikdy nepřibude, znamená, že špatné je pořadí, ne trasa.

Centrální politika je také ta užitečná část. Pobočkám lze povolit dosáhnout sdílených služeb, aniž by dosáhly na sebe, a tuto přístupovou matici stojí za to zapsat explicitně. Chybějící trasy jsou špatná náhrada pravidla, které si někdo může přečíst.

Dejte pozor na poloviční verzi: spoke A směruje na spoke B přes hub, hub směruje oběma směry a firewall hubu povoluje nová spojení z A, ale ne z B. První směr se testuje dobře a druhý visí, což vypadá jako chyba směrování a není.

Navrhněte výpadek, pak běžnou cestu

Jediný hub je sdílená závislost a tranzitní hrdlo, a redundance je místo, kde se návrhy s hubem obvykle pokazí. Dva huby znamenají, že každý spoke drží dva tunely, a zpáteční cesta se musí shodovat s odchozí; když ne, stavový firewall zahodí odpovědi a symptomem je spojení, které se otevře a pak umře. Větší nasazení to řeší směrovacím protokolem nad tunely místo statických prefixů, což je víc strojů, ale odstraňuje to hádání. Ať zvolíte cokoli, napište zpáteční cestu vedle odchozí, protože právě zpáteční polovinu nikdo netestuje.

Úplná síť to riziko rozprostírá: výpadek spoje jedné lokality neizoluje ostatní. Také násobí místa, kde vás výběr cesty může překvapit, a aplikační relace stále nepřežijí změnu cesty bez pomoci.

Ani jeden z návrhů sám neudrží TCP relaci živou přes přepnutí. Pokud se aplikace nedokáže znovu připojit, topologie není váš problém.

Vybírejte podle nákladů na změnu, pak ověřte trasy

Začněte hubem, protože je to levnější věc, ve které se splést, a přidejte přímé tunely pro páry, jejichž provoz to ospravedlňuje. Tento hybrid není neschopnost rozhodnout se; je to návrh, ke kterému většina organizací dojde do roka. Důležité je, aby každý přímý spoj měl uvedený důvod a vlastníka.

Pak ověřte dvě kresby místo jedné. Pro běžnou cestu, traceroute z každé lokality na každý prefix služby a potvrďte, že skoky odpovídají diagramu. Pro cestu výpadku vypněte jeden tunel a zopakujte to, protože trasa, která funguje jen dokud je vše v provozu, není navržená, jen nakonfigurovaná.

Uchovejte obě kresby spolu s přístupovou maticí a revidujte je, když přibude lokalita; náklad, který řídíte, je náklad příští změny, ne elegance současného obrázku.