Spis treści
Kolokowane serwery można połączyć z zasobami chmury publicznej bez kierowania ruchu przez publiczny internet. Służą do tego rozwiązania AWS Direct Connect i Azure ExpressRoute, które zapewniają prywatną łączność między infrastrukturą lokalną a środowiskiem chmurowym. W serwerowni fizyczne połączenie może być realizowane bezpośrednio między urządzeniami lub urządzeniem klienta a infrastrukturą operatora. Samo zestawienie łącza nie gwarantuje jednak bezpieczeństwa ani wysokiej dostępności. Trzeba odpowiednio zaplanować architekturę, adresację, routing BGP, segmentację, kontrolę dostępu, redundancję oraz monitoring. Dlatego z artykułu dowiesz się, jak zaprojektować prywatne połączenie między kolokowanymi serwerami a AWS lub Azure oraz jak zweryfikować jego bezpieczeństwo i niezawodność.
Model odpowiedzialności i zakres usług – o czym pamiętać przed wdrożeniem?
Przed rozpoczęciem wdrożenia należy ustalić, kto odpowiada za poszczególne elementy połączenia. W zależności od wybranego wariantu mogą być zaangażowane cztery strony – właściciel infrastruktury, operator serwerowni, operator telekomunikacyjny oraz dostawca chmury.
Zakres odpowiedzialności warto rozpisać dla:
- urządzeń sieciowych znajdujących się w szafie klienta,
- modułów optycznych i okablowania,
- bezpośrednich połączeń w serwerowni,
- konfiguracji BGP,
- zapór sieciowych i zasad dostępu,
- monitoringu oraz obsługi awarii.
Takie ustalenia są szczególnie ważne podczas diagnozowania problemów. Jeśli wiadomo, za który fragment odpowiada każda ze stron, łatwiej określić miejsce wystąpienia awarii i skrócić czas jej usunięcia.
Możliwe warianty połączenia – port czy partner?
Zarówno AWS, jak i Microsoft udostępniają kilka modeli połączenia. W przypadku AWS Direct Connect można wykorzystać dedykowane połączenie lub skorzystać z usług partnera. Azure ExpressRoute również pozwala na zestawienie połączenia za pośrednictwem partnera, a w określonych lokalizacjach dostępne jest rozwiązanie bezpośrednie, czyli ExpressRoute Direct.
Wybór wariantu powinien uwzględniać nie tylko cenę, ale również m.in. wymaganą przepustowość, lokalizację punktu dostępowego oraz dostępność niezależnych tras. Pod uwagę warto wziąć także czas uruchomienia, możliwość zwiększenia przepustowości oraz sposób obsługi awarii. Jeżeli serwery są już umieszczone w zaufanym centrum danych, warto sprawdzić dostępność odpowiedniego operatora lub punktu dostępowego w tej samej lokalizacji. Ograniczenie liczby odcinków między infrastrukturą klienta a dostawcą chmury upraszcza architekturę i ułatwia późniejszą diagnostykę.
Architektura połączenia kolokowanych serwerów z chmurą
Najprostszy model połączenia wygląda następująco:
kolokowane serwery dedykowane → przełącznik lub router klienta → połączenie bezpośrednie → operator albo port chmurowy → AWS/Azure → zasoby chmurowe.
Po stronie klienta warto wyznaczyć urządzenia brzegowe odpowiedzialne za wymianę tras i egzekwowanie zasad komunikacji. Pozwala to oddzielić ruch kierowany do chmury od pozostałej części infrastruktury. W AWS Direct Connect można wykorzystać prywatne interfejsy wirtualne oraz połączenia z usługami odpowiedzialnymi za obsługę wielu środowisk AWS. W Azure odpowiednikiem jest ExpressRoute z prywatnym peeringiem. W każdym przypadku trzeba wcześniej zaplanować adresację. Sieci po obu stronach nie powinny się nakładać, ponieważ utrudnia to jednoznaczny wybór tras.
W Azure dla prywatnego peeringu wymagane są dwie niezależne sesje BGP. Microsoft zaleca również wykorzystanie co najmniej dwóch obwodów ExpressRoute w różnych lokalizacjach peeringu, jeżeli istotna jest odporność na awarię całej lokalizacji.
Dobór przepustowości łącza – jakie aspekty przeanalizować?
Przepustowość łącza należy dobrać na podstawie rzeczywistego profilu ruchu. Nie wystarczy sprawdzić, ile danych przesyła pojedyncza aplikacja. Trzeba uwzględnić wszystkie procesy korzystające z połączenia.
Przed zamówieniem konkretnej usługi należy więc przeanalizować takie kwestie, jak:
- średnie i maksymalne wykorzystanie łącza,
- replikacja baz danych,
- kopie zapasowe,
- transfery między środowiskami,
- wymiana dużych zbiorów danych,
- ewentualny planowany wzrost liczby serwerów,
- dodatkowe obciążenie generowane przez systemy analityczne i AI (jeśli są wykorzystywane).
Nie można nigdy zakładać pracy łącza przy stałym wykorzystaniu bliskim 100%. Potrzebny jest zapas zarówno na chwilowe wzrosty ruchu, jak i na sytuację, w której część transmisji zostanie przejęta przez ścieżkę zapasową. Trzeba też sprawdzić limity konkretnej usługi. ExpressRoute ma określoną przepustowość obwodu współdzieloną przez skonfigurowane peeringi, natomiast AWS określa limity dotyczące między innymi interfejsów wirtualnych i rozgłaszanych prefiksów.
Routing BGP – stabilność i bezpieczeństwo
BGP odpowiada za wymianę informacji o dostępnych sieciach między infrastrukturą klienta a dostawcą chmury. Jego konfiguracja powinna być przygotowana zgodnie z zasadą ograniczonego zaufania. Dlatego należy dokładnie określić, jakie prefiksy są wysyłane do chmury i odbierane od niej. Trzeba też ustalić, która trasa jest podstawowa, a która zapasowa. Nie powinno się bez ograniczeń przyjmować całej tablicy tras. Filtrowanie prefiksów zmniejsza ryzyko błędnej propagacji tras i przypadkowego skierowania ruchu do niewłaściwego środowiska.
W Azure można wykorzystać uwierzytelnianie MD5 dla sesji BGP, a BFD pozwala szybciej wykrywać awarie połączenia. W przypadku dwóch ścieżek należy również określić, która z nich będzie preferowana i w jakich warunkach nastąpi przełączenie.
Segmentacja, izolacja środowisk, szyfrowanie i kontrola dostępu
Prywatna łączność nie oznacza, że każdy system znajdujący się po jednej stronie powinien mieć dostęp do wszystkich zasobów po drugiej. Segmentacja powinna być zaplanowana jeszcze przed uruchomieniem połączenia. W zależności od potrzeb można oddzielić np. środowiska produkcyjne, testowe, administracyjne, analityczne oraz przeznaczone do obliczeń AI. Oprócz podziału sieci należy stosować filtrowanie prefiksów i reguły zapór ograniczające komunikację do wymaganych adresów oraz portów.
Trzeba również rozróżnić prywatność połączenia od szyfrowania. ExpressRoute zapewnia prywatną ścieżkę, ale sam fakt wykorzystania tej usługi nie oznacza, że cały ruch aplikacyjny jest automatycznie szyfrowany. W zależności od architektury można zastosować TLS, IPsec lub MACsec.
Redundancja i wysoka dostępność
Pojedynczy tor transmisyjny jest krytycznym punktem awarii niezależnie od jego przepustowości. Problem może wystąpić w module optycznym, urządzeniu sieciowym, przewodzie, trasie światłowodowej albo u operatora. Dlatego dla systemów krytycznych należy projektować co najmniej dwa niezależne tory. Istotna jest przy tym rzeczywista ich niezależność. Dwa przewody prowadzone tą samą trasą do jednego przełącznika nie zapewniają takiej odporności jak połączenia korzystające z odrębnych urządzeń i dróg transmisyjnych.
W Azure każda sesja peeringu ExpressRoute składa się z pary niezależnych sesji BGP. Dodatkową odporność można uzyskać przez wykorzystanie wielu obwodów i lokalizacji. Podobne podejście należy stosować przy projektowaniu infrastruktury dla AWS Direct Connect.
Ważne do wykonania testy przed uruchomieniem – latency, jitter oraz utrata pakietów
Przed uruchomieniem produkcyjnym trzeba sprawdzić nie tylko, czy sesja BGP została zestawiona. Należy również zweryfikować jakość transmisji.
Podstawowy zestaw testów powinien obejmować badanie takich kwestii, jak:
- opóźnienia, w tym ich zmienność,
- utrata pakietów,
- przepustowość w obu kierunkach przy różnych poziomach obciążenia,
- poprawność routingu i działania ustalonych reguł bezpieczeństwa,
- zachowanie połączenia przy zwiększonym obciążeniu.
W przypadku aplikacji AI, replikacji i innych procesów przesyłających duże ilości danych szczególnie istotne jest sprawdzenie zachowania łącza pod obciążeniem. Wynik testu wykonanego przy niskim obciążeniu nie zawsze będzie reprezentatywny dla warunków produkcyjnych.
Monitoring SLA i szybka detekcja awarii
Monitoring powinien obejmować zarówno fizyczny stan połączenia, jak i jego warstwę logiczną. Sam fakt działania interfejsu nie oznacza jeszcze, że routing działa prawidłowo. Należy na bieżąco analizować m.in.:
- stan portów i interfejsów,
- sesje BGP,
- liczbę rozgłaszanych prefiksów,
- wykorzystanie przepustowości,
- błędy interfejsów,
- utratę pakietów i opóźnienia,
- przełączenia między trasami.
AWS umożliwia monitorowanie połączeń Direct Connect i interfejsów wirtualnych za pomocą Amazon CloudWatch. Dostępne są między innymi dane dotyczące ruchu oraz stanu połączeń. Monitoring powinien być powiązany z systemem alarmowym. Administrator powinien otrzymać informację nie tylko o całkowitym zerwaniu połączenia, ale także o utracie sesji BGP, wzroście błędów czy przekroczeniu ustalonych wartości opóźnienia.
Audyt bezpieczeństwa po wykonaniu połączenia – o czym należy pamiętać?
Przed uruchomieniem systemu warto przeprowadzić końcowy przegląd całej konfiguracji. Powinien on objąć zarówno urządzenia w serwerowni, jak i ustawienia po stronie chmury.
Należy sprawdzić przede wszystkim:
- poprawność adresacji i brak nakładających się zakresów,
- filtry prefiksów BGP oraz uwierzytelnianie sesji,
- preferencję tras podstawowych i zapasowych,
- reguły zapór sieciowych,
- separację poszczególnych środowisk,
- konfigurację szyfrowania, jeżeli jest wymagane,
- działanie monitoringu i alarmów.
Warto również zweryfikować, czy dostęp do zasobów chmurowych jest ograniczony do rzeczywiście potrzebnych systemów. Prywatna ścieżka komunikacyjna powinna być elementem kontrolowanej architektury, a nie sposobem na ominięcie istniejących mechanizmów bezpieczeństwa.
Dobrze zaprojektowane połączenie między kolokowanymi serwerami a chmurą łączy odpowiednią przepustowość, kontrolę routingu, segmentację i redundancję. Jeśli interesuje Cię kolokacja, skorzystaj z oferty polskiego centrum danych Sprint Data Center. Przygotujemy odpowiednią infrastrukturę IT pod serwery oraz pomożemy w wykonaniu bezpiecznego połączenia dostosowanego do wymagań danego środowiska informatycznego.
FAQ – odpowiedzi na często zadawane pytania
1. Czy Direct Connect i ExpressRoute zastępują połączenie VPN?
Nie zawsze. Prywatne połączenie może pełnić funkcję podstawowej ścieżki do chmury, natomiast VPN może zostać wykorzystany jako dodatkowa droga awaryjna. Przydatność tego rozwiązania zależy od wymaganej przepustowości, opóźnienia i krytyczności aplikacji.
2. Czy można korzystać z jednego połączenia dla wielu środowisk?
Tak. Można zaprojektować wspólną infrastrukturę IT dla wielu środowisk, ale konieczne jest odpowiednie rozdzielenie ruchu i kontrolowanie propagowanych tras. Przy większej liczbie systemów warto wcześniej zaplanować model segmentacji i zasady komunikacji między nimi.
3. Czy prywatne połączenie chroni przed nieautoryzowanym dostępem?
Samo w sobie nie gwarantuje takiej ochrony. Zapewnia prywatną drogę transmisji, ale nie zastępuje kontroli dostępu, zapór ani mechanizmów uwierzytelniania aplikacji. Zakres dostępnych sieci i usług powinien być ograniczony zgodnie z wymaganiami bezpieczeństwa.
4. Co jest potrzebne do uruchomienia BGP?
Potrzebne są między innymi odpowiednio skonfigurowane urządzenia sieciowe, numery systemów autonomicznych, adresy dla sesji BGP oraz ustalone prefiksy. Szczegółowe wymagania zależą od wybranego wariantu rozwiązania, czyli Direct Connect lub ExpressRoute.