WireGuard, IPsec a SD-WAN nejsou na stejné úrovni. WireGuard a IPsec chrání provoz v tunelech. SD-WAN označuje řízenou službu propojení lokalit přes jedno či více podkladových spojení; šifrování přitom může využívat různé technologie. U více firemních lokalit proto výběr začíná aplikacemi, linkami, odpovědnostmi a scénáři výpadku, nikoli názvem produktu.
Fiktivní podnik má centrálu a tři pobočky. ERP a telefonie využívají centrální služby, Microsoft 365 směřuje pokud možno přímo do internetu a servisní firma potřebuje jen omezený přístup. Náš článek DAXS o údržbě OPNsense řeší aktualizaci firewallu; zde jde o topologii lokalit a volbu provozního přístupu. Druhá internetová linka v každé lokalitě je samostatné téma, které samotný název SD-WAN neřeší.
Čtyři kontroly před volbou protokolu
Nejprve se pro každou lokalitu zaznamenají aplikace, cílové sítě, naměřené špičkové zatížení, požadavky na latenci, veřejná dosažitelnost a výpadky linek. Překrývající se soukromé adresní rozsahy komplikují směrování a pravidla přístupu bez ohledu na tunelovací protokol. Poté se určí, zda pobočky komunikují pouze s centrálou, nebo i přímo mezi sebou; hub-and-spoke potřebuje méně tunelových vztahů, ale může z centrály udělat úzké hrdlo. Nakonec se přidělí odpovědnost za provoz, správu klíčů, monitoring a otestovanou cestu obnovy.
| Přístup | Vhodný, pokud … | Kontroly a hranice |
|---|---|---|
| WireGuard | Několik jasně definovaných protistran a sítí umožňuje zvládnutelnou správu klíčů | Prakticky otestovat AllowedIPs, trasy, pravidla firewallu, NAT a dosažitelnost každé protistrany; protokol sám neposkytuje automatický centrální provoz |
| IPsec s IKEv2 | Stávající zařízení či protistrany potřebují standardizované tunely IPsec | Na konkrétní dvojici zařízení ověřit profily různých výrobců, certifikáty, obnovu klíčů, NAT-T a přepnutí při výpadku |
| Služba SD-WAN | Více linek, mnoho lokalit nebo aplikačně řízené cesty mají být centrálně spravovány a podporovány | Technicky i smluvně posoudit underlay, edge zařízení, politiku, měřicí body, přístup ke správě, SLA a cestu při výpadku |
Malou síť lze s WireGuardem nebo IPsec provozovat velmi dobře, pokud někdo odpovídá za konfiguraci a poruchy. Nabídka SD-WAN může tuto provozní práci spojit a řídit cesty, ale přináší vlastní náklady na platformu, licence, podporu a závislosti. Lepší dostupnost závisí na skutečně nezávislých linkách a otestovaném přepnutí.
WireGuard: jasné protistrany, jasné sítě
WireGuard přiřazuje veřejným klíčům povolené rozsahy IP. Při propojení lokalit musí tyto rozsahy odpovídat směrovací tabulce a pravidlům firewallu; funkční handshake sám neprokazuje dosažitelnost ERP či telefonie. U protistrany za NAT může být potřebný keepalive. Dokumentace OPNsense uvádí konkrétní kontroly protistran, tras a firewallu pro dvě lokality i možné problémy MTU/MSS. Se čtyřmi lokalitami roste konfigurace a správa klíčů, zvláště pokud jsou požadovány přímé cesty mezi pobočkami. Samotný WireGuard nepřidává automatickou správu politik, monitoring služby ani SLA.
IPsec/IKEv2: standardizace potřebuje ověření
IPsec chrání pakety na síťové vrstvě; IKEv2 vyjednává bezpečnostní asociace a klíče. To může dávat smysl u různých firewallů nebo stávajících požadavků partnerů. Kompatibilita však není samozřejmá: šifrovací sady, certifikáty, síťové selektory, obnova klíčů a průchod NAT musí souhlasit na obou stranách. RFC 7296 popisuje například zapouzdření UDP pro IPsec při NAT. Pilot proto ověřuje navázání tunelu, delší provoz, změnu klíčů a obnovení po přerušení linky. Ani zde úspěšný ping neznamená funkční převzetí.
SD-WAN: rozlišovat overlay, underlay a smlouvu
MEF 70.2 definuje SD-WAN jako službu s dohodnutými atributy a výslovně ji odlišuje od podkladových konektivitních služeb. V příkladu by požadavky mohly znít „ERP přes cestu A, při naměřeném výpadku přes B“ nebo „telefonie jen při vhodné latenci“; jejich konkrétní dostupnost závisí na produktu poskytovatele, měření a smluvních službách. Pokud má pobočka jen jeden fyzický internetový přístup, centrální řízení jeho výpadek konfigurací neodstraní. Stejně tak druhá linka pomůže málo, pokud obě vedou stejnou trasou, používají stejné napájení nebo edge zařízení.
V nabídce se proto zvlášť posuzují edge hardware, umístění správy, linky, centrální politika, bezpečnostní hranice, protokolování, údržba firmwaru, časy podpory, cesta dat a scénář odchodu. „Spravované“ je výhodou pouze tehdy, jsou-li určeny eskalace, měřicí údaje a odpovědnost při poruše.
Test výpadku řekne více než technický list
Centrála a jedna pobočka společně ověří čtyři případy: ztrátu hlavní cesty, výpadek edge zařízení, neplatný klíč nebo certifikát a nefunkční aplikaci navzdory aktivnímu tunelu. Měří se detekce, přepnutí, opětovné spojení, dopad na aplikaci a návrat k běžné cestě. ERP a telefonie mohou mít různé přípustné doby přerušení. Protokol uvádí skutečné časy místo obecného příslibu vysoké dostupnosti.
Nákladové rozhodnutí zahrnuje zařízení a náhradní díly, nastavení tunelů a politik, ceny linek, další skutečnou redundanci, licence či poplatky za službu, monitoring a interní pohotovost. Vlastní tunel WireGuard nemusí mít zvláštní licenční poplatek za protokol, stále však nese provozní náklady a náklady na linky. Tunel IPsec na stávajících zařízeních může vypadat levně, pokud se započítají údržba a schválení výrobce. Služba SD-WAN může u mnoha lokalit snížit práci, ale je nutné ji porovnat při stejném rozsahu služeb. Bez měření a nabídek by pořadí podle eur bylo vymyšlené.
DAXS může s podnikem převést čtyři lokality, aplikace a případy výpadku do topologie připravené k převzetí a porovnat vhodné provozní varianty. Výchozími podklady pro rozhovor s DAXS jsou síťový plán lokalit, smlouvy o linkách a dosavadní historie poruch.
Zdroje: WireGuard: Quick Start; OPNsense: WireGuard Site-to-Site; IETF RFC 7296: IKEv2; Mplify/MEF 70.2: SD-WAN Service Attributes.
