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
| Parametr | Przed wdrożeniem | Po wdrożeniu |
| Łączność z AWS | Brak (dostęp przez internet publiczny) | Dedykowane tunele VPN IPsec |
| Redundancja | Brak – single point of failure | Automatyczny failover BGP (2 tunele/oddział) |
| Czas przełączenia przy awarii | Brak automatycznego przełączania | ~30–40 sekund |
| Bezpieczeństwo transmisji | Nieszyfrowane lub VPN ręczny | IPsec z AES-256 + SHA-256 |
| Zarządzanie routingiem | Brak / statyczny | Dynamiczny (BGP) |
| Wymiana sprzętu | – | Brak – wykorzystanie istniejących USG |
| Koszty inwestycji sprzętowej | – | 0 PLN (brak nowego sprzętu) |
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ż:
| Rozwiązanie | Zalety | Wady | Koszt |
| Unifi USG + BGP (CLI) – nasze rozwiązanie | Brak wymiany sprzętu, niski koszt | Ograniczona skalowalność, ryzyko nadpisania konfiguracji | Niski |
| WireGuard na dedykowanym Linux | Szybszy, nowocześniejszy VPN, pełna kontrola | Wymaga dodatkowego serwera w każdym oddziale | Średni |
| Dedykowany VPN (OpenVPN) | Elastyczność, otwarte źródło | Wolniejszy od WireGuard/IPsec, wymaga serwera | Średni |
| AWS Transit Gateway + SD-WAN | Centralne zarządzanie, skalowalne | Wysokie koszty AWS, wymaga wymiany routerów na SD-WAN | Wysoki |
| Wymiana na MikroTik / pfSense | Natywne BGP w GUI, profesjonalne funkcje | Koszt nowego sprzętu, nauka nowej platformy | Średni |
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
