Hub-and-spoke czy Virtual WAN? Decyduje routing, nie schemat

Wybór między klasycznym hub-and-spoke a Virtual WAN bywa przedstawiany jako decyzja o rysunku architektury. W praktyce jest to decyzja o tym, ile kontroli nad routingiem chce zachować zespół sieciowy — i czy w hubie ma stać urządzenie, którym ten zespół już zarządza.

Co naprawdę różni obie topologie

Klasyczny hub-and-spoke to zwykła sieć wirtualna, w której wszystko jest jawne: bramy, tabele tras, peeringi i urządzenia. Nic nie dzieje się bez wpisu, który można pokazać audytorowi.

Virtual WAN przenosi część tej odpowiedzialności do usługi zarządzanej. Hub sam utrzymuje tabele tras, propagację i połączenia branch-to-branch, a routing intent pozwala jednym ustawieniem skierować ruch prywatny i internetowy do urządzenia inspekcyjnego. Zyskujemy skalę i prostotę operacyjną, tracimy część możliwości ręcznej korekty.

Routing jest właściwym kryterium

Zanim padnie decyzja o topologii, warto odpowiedzieć na kilka pytań:

• Czy potrzebna jest pełna kontrola nad tabelami tras? W klasycznym hubie każdą trasę definiujemy sami — łącznie z trasami bardziej szczegółowymi, obejściami dla wybranych przepływów i wyłączeniem propagacji tras z bramy. W Virtual WAN część tych decyzji podejmuje usługa.
• Ile jest lokalizacji lokalnych i regionów? Przy kilkudziesięciu oddziałach i wielu regionach ręczne utrzymanie pełnej siatki tras w klasycznym modelu staje się kosztowne. To najmocniejszy argument za Virtual WAN.
• Jak wygląda filtrowanie prefiksów? Sesje BGP z centrum danych rzadko powinny przyjmować wszystko, co ogłasza druga strona. Zakres akceptowanych prefiksów i sposób ich agregacji trzeba ustalić niezależnie od wybranej topologii.
• Czy wymagany jest forced tunneling? Kierowanie ruchu internetowego przez centrum danych zmienia projekt tras domyślnych i bywa najtrudniejszym elementem do pogodzenia z usługami PaaS.

Własne NVA: gdzie leży granica

Instytucje, które mają wdrożony standard bezpieczeństwa oparty na konkretnym producencie firewalli, zwykle chcą utrzymać go również w chmurze. Są trzy sensowne warianty:

1. NVA w klasycznym hubie. Pełna swoboda konfiguracji, wysoka dostępność realizowana przez load balancer wewnętrzny, a symetria ruchu wymuszona jawnymi trasami po obu stronach przepływu.
2. NVA zintegrowane w hubie Virtual WAN. Wybrani producenci mogą być wdrożeni bezpośrednio w hubie i uczestniczyć w routing intent. Wygodne, ale ograniczone do listy wspieranych rozwiązań.
3. NVA w dedykowanym spoke. Kompromis, który zachowuje Virtual WAN jako szkielet, a inspekcję pozostawia w sieci zarządzanej przez klienta — kosztem dodatkowych tras i uważnego projektu przepływów zwrotnych.

Niezależnie od wariantu obowiązuje ta sama zasada: urządzenie stanowe musi widzieć obie strony sesji. Większość problemów, które trafiają do nas jako „losowe zrywanie połączeń”, to ruch asymetryczny powstały po dołożeniu jednej trasy w jednym miejscu.

Czego nie widać na schemacie

Dwie rzeczy warto policzyć wcześniej niż później. Po pierwsze koszt: hub Virtual WAN jest rozliczany za samo istnienie oraz za przetworzone dane, więc przy niewielkim środowisku bywa droższy niż zwykła sieć wirtualna z bramą. Po drugie limity: liczba połączeń na hub, liczba tras w tabeli i przepustowość jednostek skalowania to twarde granice, które lepiej sprawdzić przed migracją niż w jej trakcie.

Wniosek

Virtual WAN jest dobrym wyborem tam, gdzie liczy się skala i liczba lokalizacji, a organizacja akceptuje zarządzany model routingu. Klasyczny hub-and-spoke pozostaje właściwy tam, gdzie zespół sieciowy musi utrzymać własne urządzenia i pełną kontrolę nad każdą trasą. W projektach, które prowadzimy, oba modele współistnieją — decyzję podejmujemy na podstawie macierzy przepływów i wymagań inspekcji, a nie preferencji dotyczącej rysunku.