Gwiazda czy pełna siatka: która topologia VPN pasuje do twoich lokalizacji

Dwa oddziały rozmawiają ze sobą przez cały dzień, a tunel między nimi nadkłada drogi przez centrum danych w innym regionie. Każde żądanie płaci za to nadłożenie dwa razy i nikt tego nie zauważa, dopóki synchronizacja plików nie zacznie wyglądać dziwnie. Tu naprawdę zaczyna się pytanie o topologię: nie od tego, który diagram wygląda solidniej, ale od tego, za jaki wzorzec ruchu płacisz. Oba projekty działają i oba zawodzą na różne sposoby, różnymi kosztami.

Najpierw policz relacje między węzłami

Przy N lokalizacjach pełna siatka potrzebuje N razy N minus jeden, podzielone przez dwa, tuneli; centrum potrzebuje N. Przy pięciu lokalizacjach to dziesięć przeciw pięciu, co wciąż brzmi wykonalnie. Przy piętnastu to 105 przeciw piętnastu, a różnica nie jest już arytmetyczna, lecz kadrowa.

Każda z tych relacji niesie stan, którym musisz zarządzać. W IPsec to asocjacja bezpieczeństwa, tożsamość, klucz lub certyfikat, wykrywanie martwego peera i co najmniej jedna trasa na każdy zdalny prefiks. W WireGuard to klucz publiczny i blok AllowedIPs na peera; taniej na peera, ale bez żadnego wykrywania: nowa lokalizacja i tak oznacza zmianę konfiguracji na każdej istniejącej.

Niech decyduje mieszanka ruchu, nie rysunek

Jeśli ruch oddziałów to głównie żądania do centralnego ERP lub klastra plików, centrum nie jest kompromisem, tylko właściwym kształtem: ruch już chciał tam trafić, a jeden punkt polityki łatwiej audytować niż siatkę reguł parami. Siatka zasługuje na swoją złożoność, gdy oddziały wymieniają dane między sobą: replikacja między dwoma biurami, głos między lokalizacjami, udział CAD, który tuzin inżynierów otwiera przez cały dzień.

Niewygodne przypadki leżą pośrodku i jest ich większość. Mierz, zanim zaczniesz się spierać, zamiast zgadywać ze schematu organizacji.

Czytaj tabelę jako rozstrzygnięcie, nie jako regułę. Trzy z czterech wierszy w jedną stronę zwykle rozstrzygają projekt, a podział oznacza hybrydę, którą większość dojrzałych sieci i tak ostatecznie prowadzi.

Centrum trzeba powiedzieć, żeby przekazywało ruch

Dwa działające tunele oddział-centrum nie tworzą dostępu między oddziałami. Centrum potrzebuje włączonego przekazywania IP, trasy do każdej sieci oddziału, reguły firewalla zezwalającej na tranzyt oraz wyliczonej trasy powrotnej; każdy oddział potrzebuje trasy do prefiksów drugiej lokalizacji. W centrum na Linuksie to net.ipv4.ip_forward=1 plus łańcuch FORWARD, który po cichu nie porzuca pary, a w IPsec opartym na politykach to selektory ruchu wymieniające podsieć zdalnego oddziału na obu końcach. strongSwan notatki o przekazywaniu obejmują stronę jądra i firewalla, gdy brakuje właśnie tej warstwy. Tani test: wyślij ruch z jednego oddziału do usługi w drugim i obserwuj liczniki centrum; reguła, która nigdy nie rośnie, oznacza, że zła jest kolejność, a nie trasa.

Centralna polityka to także użyteczna część. Oddziałom można pozwolić sięgać do wspólnych usług, nie sięgając siebie nawzajem, a ta macierz dostępu jest warta spisania wprost. Brakujące trasy to słaby substytut reguły, którą ktoś może przeczytać.

Uważaj na wersję zrobioną do połowy: oddział A trasuje do oddziału B przez centrum, centrum trasuje w obie strony, a firewall centrum pozwala na nowe połączenia z A, ale nie z B. Pierwszy kierunek testuje się dobrze, drugi wisi, co wygląda na błąd trasowania, a nim nie jest.

Najpierw zaprojektuj awarię, potem normalną ścieżkę

Pojedyncze centrum to wspólna zależność i wąskie gardło tranzytu, a redundancja to miejsce, w którym projekty z centrum zwykle zawodzą. Dwa centra oznaczają, że każdy oddział trzyma dwa tunele, a trasa powrotna musi się zgadzać z wychodzącą; gdy się nie zgadza, firewall stanowy porzuca odpowiedzi, a objawem jest połączenie, które się otwiera i potem ginie. Większe wdrożenia rozwiązują to protokołem trasowania nad tunelami zamiast statycznych prefiksów, to więcej maszynerii, ale usuwa zgadywanie. Cokolwiek wybierzesz, zapisz trasę powrotną obok wychodzącej, bo to połowa powrotna jest tą, której nikt nie testuje.

Siatka rozprasza to ryzyko: awaria łącza jednej lokalizacji nie izoluje pozostałych. Mnoży też miejsca, w których wybór ścieżki może cię zaskoczyć, a sesje aplikacji nadal nie przetrwają zmiany ścieżki bez pomocy.

Żaden z projektów sam nie utrzymuje sesji TCP przy przełączeniu. Jeśli aplikacja nie potrafi się połączyć ponownie, topologia nie jest twoim problemem.

Wybieraj po koszcie zmiany, a potem zweryfikuj trasy

Zacznij od centrum, bo to tańsza rzecz, w której można się pomylić, i dodaj tunele bezpośrednie dla par, których ruch to uzasadnia. Ta hybryda nie jest porażką w decydowaniu; to projekt, na którym większość organizacji osiada w ciągu roku. Liczy się to, że każde bezpośrednie łącze ma podany powód i właściciela.

Potem zweryfikuj dwa rysunki, a nie jeden. Dla normalnej ścieżki uruchom traceroute z każdej lokalizacji do każdego prefiksu usługi i potwierdź, że przeskoki zgadzają się z diagramem. Dla ścieżki awarii zamknij jeden tunel i powtórz, bo trasa, która działa tylko wtedy, gdy wszystko działa, nie została zaprojektowana, tylko skonfigurowana.

Trzymaj oba rysunki razem z macierzą dostępu i wracaj do nich, gdy dochodzi lokalizacja; koszt, którym zarządzasz, to koszt następnej zmiany, a nie elegancja obecnego obrazka.