WireGuard, IPsec og SD-WAN befinder sig ikke på samme niveau. WireGuard og IPsec beskytter trafik i tunneler. SD-WAN beskriver en styret lokationstjeneste over en eller flere underliggende forbindelser; krypteringen kan bruge forskellige teknikker. Ved flere virksomhedsadresser begynder valget derfor med applikationer, linjer, ansvar og fejlsituationer frem for et produktnavn.
En fiktiv virksomhed har et hovedkontor og tre afdelinger. ERP og telefoni bruger centrale tjenester, Microsoft 365 går så direkte som muligt på internettet, og et vedligeholdelsesfirma behøver kun en begrænset serviceadgang. Vores DAXS-artikel om OPNsense-vedligeholdelse beskriver opdatering af en firewall; her handler det om lokationstopologien og dens driftsvalg. En ekstra internetforbindelse på hver lokation er et særskilt emne, som navnet SD-WAN alene ikke løser.
Fire kontroller før valg af protokol
Registrér først applikationer, destinationsnet, målt spidsbelastning, latenstidskrav, offentlig tilgængelighed og linjefejl for hver lokation. Overlappende private adresseområder gør routing og adgangsregler vanskeligere uanset tunnelprotokol. Fastlæg derefter, om afdelingerne kun kommunikerer med hovedkontoret eller også direkte med hinanden; hub-and-spoke kræver færre tunnelrelationer, men kan gøre hovedkontoret til en flaskehals. Til sidst fordeles drift, nøglevedligeholdelse, monitoring og en testet genopretningsvej.
| Tilgang | Passer, når … | Kontrolpunkter og grænser |
|---|---|---|
| WireGuard | Få klart definerede peers og netværk giver overskuelig nøglevedligeholdelse | Test AllowedIPs, ruter, firewallregler, NAT og tilgængelighed for hver peer i praksis; protokollen giver ikke automatisk central drift |
| IPsec med IKEv2 | Eksisterende enheder eller peers kræver standardiserede IPsec-tunneler | Godkend profiler på tværs af producenter, certifikater, rekeying, NAT-T og failover på det konkrete enhedspar |
| SD-WAN-tjeneste | Flere linjer, mange lokationer eller applikationsbestemte stier skal styres og vedligeholdes centralt | Vurder underlay, edge-enheder, politik, målepunkter, administrationsadgang, SLA og fejlvej både teknisk og kontraktligt |
Et lille netværk kan drives meget godt med WireGuard eller IPsec, hvis nogen har ansvaret for konfiguration og fejl. Et SD-WAN-tilbud kan samle dette driftsarbejde og styre stier, men medfører egne omkostninger til platform, licenser, support og afhængigheder. Bedre tilgængelighed afhænger af reelt uafhængige linjer og testet omskiftning.
WireGuard: klare peers, klare netværk
WireGuard knytter offentlige nøgler til tilladte IP-områder. I en lokationsforbindelse skal områderne passe til routingtabellen og firewallreglerne; et fungerende handshake beviser endnu ikke, at ERP eller telefoni kan nås. En keepalive kan være nødvendig, hvis en peer er bag NAT. OPNsense-dokumentationen viser konkrete peer-, rute- og firewallkontroller for to lokationer samt mulige MTU/MSS-problemer. Ved fire lokationer vokser konfiguration og nøglevedligeholdelse, især hvis der ønskes direkte veje mellem afdelingerne. WireGuard alene tilføjer ikke automatisk politikstyring, servicemonitoring eller SLA.
IPsec/IKEv2: standardisering kræver afprøvning
IPsec beskytter pakker på netværkslaget; IKEv2 forhandler sikkerhedsassociationer og nøgler. Det kan være relevant med forskellige firewalls eller eksisterende partnerkrav. Kompatibiliteten skal dog afprøves: krypteringssuiter, certifikater, netværksselektorer, rekeying og NAT traversal skal passe sammen på begge sider. RFC 7296 beskriver eksempelvis UDP-indkapsling af IPsec ved NAT. Pilotprojektet kontrollerer derfor tunneloprettelse, længere drift, nøgleskift og genetablering efter linjeafbrydelse. En vellykket ping er heller ikke her en faglig godkendelse.
SD-WAN: skeln mellem overlay, underlay og kontrakt
MEF 70.2 definerer SD-WAN som en tjeneste med aftalte egenskaber og skelner udtrykkeligt fra de underliggende forbindelsestjenester. I eksemplet kunne kravene være »ERP via sti A og via B ved målt fejl« eller »telefoni kun ved passende latenstid«; den konkrete tilgængelighed afhænger af udbyderens produkt, målingen og de aftalte ydelser. Har en afdeling kun én fysisk internetadgang, kan central styring ikke konfigurere dens fejl væk. En ekstra linje hjælper heller ikke meget, hvis begge bruger samme tracé, strømforsyning eller edge-enhed.
Et tilbud vurderes derfor separat på edge-hardware, administrationsplacering, linjer, central politik, sikkerhedsgrænser, logning, firmwarevedligeholdelse, supporttider, datavej og exit-scenarie. »Managed« er kun en fordel, når eskalation, måledata og ansvar ved fejl er fastlagt.
En fejltest siger mere end et datablad
Hovedkontoret og en afdeling tester sammen fire tilfælde: tab af hovedvejen, fejl på edge-enheden, ugyldig nøgle eller certifikat og en applikation, som ikke virker trods aktiv tunnel. Mål registrering, omskiftning, genetablering, applikationspåvirkning og tilbagevenden til normalvejen. ERP og telefoni kan tillade forskellige afbrydelser. Testprotokollen angiver faktiske tider frem for et generelt løfte om høj tilgængelighed.
Omkostningsvalget omfatter enheder og reservedele, tunnel- og politikopsætning, linjepriser, ekstra reel redundans, licenser eller servicegebyrer, monitoring og intern vagtindsats. En egen WireGuard-tunnel har måske ingen særskilt protokollicens, men stadig drifts- og forbindelsesomkostninger. En IPsec-tunnel på eksisterende enheder kan se billig ud, hvis vedligeholdelse og producentgodkendelse regnes med. En SD-WAN-tjeneste kan reducere arbejdet ved mange lokationer, men skal sammenlignes med samme ydelsesomfang. Uden målinger og tilbud ville en rangordning i euro være opdigtet.
DAXS kan sammen med virksomheden omsætte de fire lokationer, applikationer og fejlsituationer til en topologi, der kan godkendes ved test, og sammenligne egnede driftsvarianter. Udgangspunktet for en samtale med DAXS er lokationernes netværksplan, linjekontrakter og den hidtidige fejlhistorik.
Kilder: WireGuard: Quick Start; OPNsense: WireGuard Site-to-Site; IETF RFC 7296: IKEv2; Mplify/MEF 70.2: SD-WAN Service Attributes.
