WireGuard, IPsec i SD-WAN nie znajdują się na tym samym poziomie. WireGuard i IPsec chronią ruch w tunelach. SD-WAN oznacza zarządzaną usługę łączenia lokalizacji przez jedno lub więcej połączeń bazowych; szyfrowanie może wykorzystywać różne technologie. Dla wielu lokalizacji wybór zaczyna się więc od aplikacji, łączy, odpowiedzialności i scenariuszy awarii, a nie nazwy produktu.
Fikcyjna firma ma centralę i trzy oddziały. ERP i telefonia korzystają z usług centralnych, Microsoft 365 wychodzi do internetu możliwie bezpośrednio, a firma serwisowa potrzebuje tylko ograniczonego dostępu. Nasz artykuł DAXS o konserwacji OPNsense omawia aktualizację zapory; tutaj chodzi o topologię lokalizacji i decyzję o jej eksploatacji. Drugie łącze internetowe w każdej lokalizacji jest osobnym zagadnieniem, którego sama nazwa SD-WAN nie rozwiązuje.
Cztery kontrole przed wyborem protokołu
Najpierw dla każdej lokalizacji rejestruje się aplikacje, sieci docelowe, zmierzone obciążenie szczytowe, wymagania opóźnień, publiczną osiągalność i awarie łączy. Nakładające się prywatne zakresy adresów komplikują routing i reguły dostępu niezależnie od protokołu tunelowania. Następnie określa się, czy oddziały komunikują się tylko z centralą, czy też bezpośrednio między sobą; hub-and-spoke wymaga mniej relacji tunelowych, ale może uczynić centralę wąskim gardłem. Na końcu przypisuje się eksploatację, obsługę kluczy, monitoring i przetestowaną ścieżkę przywrócenia działania.
| Podejście | Pasuje, gdy… | Kontrole i ograniczenia |
|---|---|---|
| WireGuard | Niewielka liczba jasno określonych peerów i sieci umożliwia sprawną obsługę kluczy | Praktycznie sprawdzić AllowedIPs, trasy, reguły zapory, NAT i osiągalność każdego peera; protokół sam nie zapewnia automatycznej centralnej eksploatacji |
| IPsec z IKEv2 | Istniejące urządzenia lub peery wymagają standardowych tuneli IPsec | Na konkretnej parze urządzeń zatwierdzić profile różnych producentów, certyfikaty, wymianę kluczy, NAT-T i przełączenie awaryjne |
| Usługa SD-WAN | Wiele łączy, liczne lokalizacje lub ścieżki zależne od aplikacji wymagają centralnego sterowania i obsługi | Technicznie i umownie sprawdzić underlay, urządzenia edge, politykę, punkty pomiarowe, dostęp administracyjny, SLA i ścieżkę awaryjną |
Mała sieć może bardzo dobrze działać z WireGuard lub IPsec, jeśli ktoś odpowiada za konfigurację i awarie. Oferta SD-WAN może połączyć te obowiązki i sterować ścieżkami, lecz wprowadza własne koszty platformy, licencji, wsparcia i zależności. Lepsza dostępność zależy od faktycznie niezależnych łączy i przetestowanego przełączenia.
WireGuard: jasno określone peery i sieci
WireGuard przypisuje kluczom publicznym dozwolone zakresy IP. W połączeniu między lokalizacjami zakresy muszą pasować do tablicy routingu i reguł zapory; poprawny handshake nie dowodzi jeszcze osiągalności ERP czy telefonii. Dla peera za NAT może być potrzebny keepalive. Dokumentacja OPNsense pokazuje konkretne kontrole peerów, tras i zapory dla dwóch lokalizacji oraz możliwe problemy MTU/MSS. Przy czterech lokalizacjach rosną konfiguracja i obsługa kluczy, zwłaszcza gdy potrzebne są bezpośrednie połączenia między oddziałami. Sam WireGuard nie dodaje automatycznego zarządzania politykami, monitorowania usług ani SLA.
IPsec/IKEv2: standaryzacja wymaga odbioru
IPsec chroni pakiety w warstwie sieciowej; IKEv2 negocjuje skojarzenia zabezpieczeń i klucze. Może to być użyteczne przy różnych zaporach lub istniejących wymaganiach partnerów. Zgodność wymaga jednak weryfikacji: zestawy szyfrów, certyfikaty, selektory sieciowe, wymiana kluczy i NAT traversal muszą pasować po obu stronach. RFC 7296 opisuje na przykład enkapsulację UDP dla IPsec przy NAT. Pilot sprawdza więc zestawienie tunelu, długotrwałą pracę, zmianę kluczy i odtworzenie po przerwaniu łącza. Udany ping również tutaj nie jest odbiorem funkcjonalnym.
SD-WAN: rozdzielić overlay, underlay i umowę
MEF 70.2 definiuje SD-WAN jako usługę o uzgodnionych atrybutach i wyraźnie odróżnia ją od bazowych usług łączności. W przykładzie wymaganiami mogłyby być reguły „ERP ścieżką A, a przy zmierzonej awarii ścieżką B” lub „telefonia tylko przy odpowiednim opóźnieniu”; faktyczna dostępność zależy od produktu dostawcy, pomiarów i usług objętych umową. Jeśli oddział ma tylko jeden fizyczny dostęp do internetu, centralne sterowanie nie usunie jego awarii konfiguracją. Drugie łącze też niewiele pomoże, jeśli oba korzystają z tej samej trasy, zasilania lub urządzenia edge.
W ofercie ocenia się więc osobno sprzęt edge, lokalizację zarządzania, łącza, politykę centralną, granice bezpieczeństwa, logowanie, obsługę firmware, godziny wsparcia, drogę danych i scenariusz wyjścia. „Zarządzane” jest zaletą tylko wtedy, gdy określono eskalację, dane pomiarowe i odpowiedzialność podczas awarii.
Test awarii mówi więcej niż karta katalogowa
Centrala i jeden oddział wspólnie testują cztery przypadki: utratę głównej ścieżki, awarię urządzenia edge, nieprawidłowy klucz lub certyfikat oraz aplikację niedziałającą mimo aktywnego tunelu. Mierzy się wykrycie, przełączenie, ponowne zestawienie połączenia, wpływ na aplikację i przywrócenie zwykłej ścieżki. ERP i telefonia mogą mieć różne dopuszczalne przerwy. Protokół podaje rzeczywiste czasy zamiast ogólnej obietnicy wysokiej dostępności.
Decyzja kosztowa obejmuje urządzenia i części zapasowe, konfigurację tuneli i polityk, ceny łączy, dodatkową rzeczywistą redundancję, licencje lub opłaty usługowe, monitoring oraz wewnętrzny nakład dyżurów. Własny tunel WireGuard może nie mieć osobnej opłaty licencyjnej za protokół, ale nadal generuje koszty eksploatacji i łączy. Tunel IPsec na istniejących urządzeniach może wydawać się tani, jeśli uwzględni się konserwację i zatwierdzenie producenta. Usługa SD-WAN może ograniczyć pracę przy wielu lokalizacjach, lecz trzeba ją porównywać przy tym samym zakresie usług. Bez pomiarów i ofert ranking w euro byłby zmyślony.
DAXS może wspólnie z firmą przełożyć cztery lokalizacje, aplikacje i scenariusze awarii na topologię gotową do odbioru oraz porównać odpowiednie warianty eksploatacji. Podstawą do rozmowy z DAXS są plan sieci lokalizacji, umowy na łącza i dotychczasowa historia awarii.
Źródła: WireGuard: Quick Start; OPNsense: WireGuard Site-to-Site; IETF RFC 7296: IKEv2; Mplify/MEF 70.2: SD-WAN Service Attributes.
