Jak połączyliśmy oddziały firmy logistycznej z AWS za pomocą Unifi i BGP – Case Study SparkSome

Stworzenie systemu sieciowego łączącego oddziały firmy z chmurą AWS

Kilka lat temu stanęliśmy przed jednym z naszych czołowych wyzwań. Jeden z operatorów logistycznych potrzebował stworzenia systemu sieciowego, który połączyłby wszystkie oddziały firmy i zapewnił im dostęp do zasobów w chmurze AWS. Klient nie chciał wymieniać swoich urządzeń (cała sieć bazowała na Unifi), w tym Unifi Security Gateway, mimo że ich możliwości były ograniczone względem potrzeb projektu. To był moment, w którym rozpoczęła się nasza techniczna przygoda.

Zarządzanie infrastrukturą sieciową w serwerowni – projekt wymagał połączenia istniejących urządzeń Unifi Security Gateway z chmurą AWS bez wymiany sprzętu. Kluczem była konfiguracja via CLI i wdrożenie dynamicznego routingu BGP.

Diagnoza problemu – wymagania vs ograniczenia sprzętu

Zanim przystąpiliśmy do wdrożenia, przeprowadziliśmy szczegółową analizę wymagań i ograniczeń. Sytuacja wyglądała następująco:

Wymagania klienta

• Połączenie wielu oddziałów firmy logistycznej w jedną sieć rozległą (WAN)
• Bezpieczny dostęp do zasobów w AWS – systemy logistyczne, bazy danych, aplikacje biznesowe
• Automatyczny failover – w przypadku awarii jednego łącza, ruch powinien automatycznie przełączyć się na trasę zapasową
• Brak wymiany sprzętu – klient chciał zachować istniejącą infrastrukturę opartą na ekosystemie Ubiquiti Unifi
• Minimalne przestoje – firma działała w trybie ciągłym (24/7), więc wdrożenie musiało odbywać się etapowo

Ograniczenia Unifi Security Gateway

Ubiquiti Unifi Security Gateway (USG) to urządzenie zaprojektowane przede wszystkim do małych i średnich sieci. Standardowy interfejs graficzny (UniFi Controller) oferuje:

• Zarządzanie sieciami LAN/VLAN
• Firewall z regułami dostępu
• Proste tunele VPN (IPsec site-to-site, L2TP)
• Podstawowy routing statyczny

Czego nie oferuje w GUI:

• Dynamiczny routing (BGP, OSPF)
• Zaawansowane polityki routingu (policy-based routing)
• Redundantne tunele VPN z automatycznym failoverem
• Natywna integracja z AWS VPN Gateway

To właśnie te brakujące funkcje były kluczowe dla naszego projektu.

Architektura rozwiązania

Warstwa 1: Tunele VPN IPsec do AWS

Każdy oddział firmy został połączony z chmurą AWS poprzez tunel IPsec Site-to-Site VPN. AWS Virtual Private Gateway (VGW) wymaga konfiguracji dwóch tuneli na każde połączenie – tunelu podstawowego i zapasowego. Daje to wbudowaną redundancję na poziomie chmury.

Konfiguracja tuneli na USG wymagała bezpośredniego dostępu do CLI urządzenia i edycji pliku konfiguracyjnego config.gateway.json, który nadpisuje ustawienia interfejsu graficznego:

{
  "interfaces": {
    "vti": {
      "vti0": {
        "address": "169.254.10.2/30",
        "description": "AWS-Tunnel-Primary",
        "mtu": "1436"
      },
      "vti1": {
        "address": "169.254.11.2/30",
        "description": "AWS-Tunnel-Secondary",
        "mtu": "1436"
      }
    }
  }
}

Interfejsy VTI (Virtual Tunnel Interface) były kluczowe, ponieważ umożliwiają routowanie ruchu przez tunel VPN za pomocą tablicy routingu, zamiast statycznego mapowania ruchu na podstawie list ACL. To z kolei otworzyło drogę do wdrożenia protokołu BGP.

Warstwa 2: Dynamiczny routing BGP

Kluczowym krokiem było wdrożenie protokołu BGP (Border Gateway Protocol), który dynamicznie zarządzał trasami sieciowymi, automatycznie przełączając połączenia w przypadku awarii jednego z tuneli VPN.

AWS narzuca dwa podejścia do routingu:

• iBGP (internal BGP) – wymaga synchronizacji tras między routerami, ale oferuje automatyczny failover
• Routing statyczny – prostszy w początkowej konfiguracji, ale staje się trudny w zarządzaniu przy rozbudowanej infrastrukturze i nie oferuje automatycznego przełączania

Wybraliśmy BGP, ponieważ przy wielu oddziałach i dwóch tunelach na oddział, statyczny routing wymagałby ręcznej reconfiguracji przy każdej zmianie topologii.

Konfiguracja BGP na Unifi Security Gateway (fragment config.gateway.json):

{
  "protocols": {
    "bgp": {
      "65001": {
        "neighbor": {
          "169.254.10.1": {
            "remote-as": "64512",
            "description": "AWS-Primary",
            "soft-reconfiguration": {
              "inbound": "''"
            }
          },
          "169.254.11.1": {
            "remote-as": "64512",
            "description": "AWS-Secondary",
            "soft-reconfiguration": {
              "inbound": "''"
            }
          }
        },
        "network": {
          "10.10.0.0/16": "''"
        }
      }
    }
  }
}

Gdzie:

• AS 65001 – numer systemu autonomicznego (ASN) przypisany do sieci klienta
• AS 64512 – ASN po stronie AWS (domyślny dla VGW)
• network 10.10.0.0/16 – podsieci ogłaszane do AWS przez BGP
• soft-reconfiguration inbound – pozwala na dynamiczną zmianę polityk bez resetowania sesji BGP

Warstwa 3: Mechanizm failoveru

Dzięki BGP, gdy jeden z tuneli VPN przestawał odpowiadać (np. z powodu awarii łącza internetowego w danym oddziale), sieć automatycznie przełączała ruch na tunel zapasowy. Proces ten trwał zazwyczaj kilkanaście sekund – czas wymagany do wygaśnięcia sesji BGP (BGP hold timer) i przeliczenia tras.

Dla skrócenia czasu failoveru skonfigurowaliśmy:

• BGP Keepalive: 10 sekund (domyślnie 60)
• BGP Hold Timer: 30 sekund (domyślnie 180)
• Dead Peer Detection (DPD) na tunelach IPsec: interwał 10 sekund, timeout po 3 próbach

To pozwoliło zredukować czas przełączania do około 30–40 sekund, co w przypadku systemów logistycznych było akceptowalne.

Wyzwania, które napotkaliśmy

Projekt nie był pozbawiony trudności. Poniżej opisujemy najważniejsze problemy i sposób ich rozwiązania:

Problem 1: Nadpisywanie konfiguracji przez UniFi Controller

Unifi Controller ma tendencję do nadpisywania konfiguracji CLI przy każdej zmianie w GUI lub aktualizacji firmware. Rozwiązanie polegało na umieszczeniu konfiguracji w pliku config.gateway.json w odpowiedniej ścieżce kontrolera, co zapewniało trwałość ustawień BGP i VTI po każdym restarcie.

Problem 2: MTU i fragmentacja pakietów

Tunele IPsec dodają nagłówek enkapsulacji, co zmniejsza efektywne MTU. Standardowe MTU 1500 bajtów po enkapsulacji IPsec (ESP + UDP encapsulation) spada do ~1436 bajtów. Nieodpowiednie MTU powodowało „czarne dziury" – pakiety zbyt duże do przesłania przez tunel były cicho odrzucane zamiast fragmentowane.

Rozwiązanie:

• Ustawienie MTU na interfejsach VTI na 1436
• Konfiguracja MSS clamping (TCP MSS adjust) na firewallu

Problem 3: Asymetryczny routing

Przy dwóch tunelach VPN i BGP istniało ryzyko asymetrycznego routingu – ruch wychodzący szedł jednym tunelem, a powracający innym. W przypadku firewalli z inspekcją stanu (stateful inspection), taki ruch mógł być odrzucany.

Rozwiązanie: konfiguracja BGP z preferencjami tras (AS-path prepending) na tunelu zapasowym, tak aby tunel primary był zawsze preferowany przy normalnej pracy.

Wyniki wdrożenia

Czego nauczył nas ten projekt?

1. Nie zawsze trzeba wymieniać sprzęt

Unifi Security Gateway to budżetowe urządzenie, ale pod maską działa EdgeOS (fork Vyatta/VyOS), który oferuje zaawansowane funkcje sieciowe dostępne przez CLI. Wiele firm zbyt pochopnie decyduje się na wymianę sprzętu, nie wykorzystując pełnego potencjału istniejącej infrastruktury.

2. CLI to potężne narzędzie

Interfejsy graficzne urządzeń sieciowych celowo ukrywają zaawansowane funkcje, aby uprościć obsługę. Jednak w rękach doświadczonego inżyniera, dostęp do CLI otwiera możliwości porównywalne ze sprzętem klasy enterprise.

3. BGP sprawdza się nawet w małych sieciach

BGP jest powszechnie kojarzony z dużymi operatorami ISP i centrami danych. Ten projekt udowodnił, że dynamiczny routing ma sens również w sieciach firm średniej wielkości – szczególnie, gdy łączymy się z chmurą publiczną, która wymaga BGP do pełnej funkcjonalności failoveru.

4. Dokumentacja jest kluczowa

Cała konfiguracja CLI musiała być precyzyjnie udokumentowana, ponieważ zmiany w UniFi Controller mogły ją nadpisać. Stworzenie szczegółowej dokumentacji pozwoliło na powtarzalność konfiguracji dla nowych oddziałów i ułatwiło późniejsze utrzymanie.

Alternatywy – co wybralibyśmy dziś?

Gdybyśmy mieli realizować ten sam projekt w 2026 roku, rozważylibyśmy również:

Więcej o podejściu SparkSome do projektowania infrastruktury IT i dedykowanych rozwiązań VPN piszemy w powiązanych artykułach.

Powiązane tematy

• Jak zaprojektować infrastrukturę IT w firmie? — od serwera do architektury WAN
• Dedykowane rozwiązanie OpenVPN — kiedy standardowy VPN nie wystarczy
• Diagnostyka sieci LAN – warstwa L1 i L2 — rozwiązywanie problemów sieciowych na najniższym poziomie
• Bezpieczeństwo sieci – protokoły ARP i BGP — zagrożenia związane z protokołami L2/L3
• Chmura czy własny serwer? — analiza strategii przechowywania danych
• Ile kosztuje godzina przestoju IT? — dlaczego failover ma znaczenie finansowe

FAQ – Projektowanie systemów sieciowych i VPN do AWS