← Back to blog

CloudSigma Virtual Router: praktyczny przewodnik po łączności w chmurze i łączności hybrydowej

Category
CloudSigma Virtual Router: praktyczny przewodnik po łączności w chmurze i łączności hybrydowej

Dlaczego warto używać wirtualnego routera?

Twoi klienci potrzebują niezawodnego dostępu do aplikacji, ale jej baza danych nie powinna być wystawiona do internetu. Twój zespół potrzebuje dostępu administracyjnego bez otwierania każdego serwera, a istniejące systemy mogą musieć pozostać połączone w miarę przenoszenia obciążeń do chmury. To przede wszystkim wymagania biznesowe: zapewnić dostępność usług, ograniczyć zbędny dostęp i jasno określić odpowiedzialność za sieć.

Model CloudSigma Virtual Router odpowiada na te potrzeby, łącząc najważniejsze funkcje sieciowe w jednej bramie. Zamiast traktować każde połączenie jako odrębne zadanie, zespoły mogą pracować w oparciu o wspólny projekt tras, publikowanych usług i reguł dostępu.

Cztery przypadki użycia pokazują, w czym takie podejście może pomóc:

  • Segmentowane aplikacje: oddzielenie obciążeń webowych, aplikacyjnych i danych, z dopuszczeniem tylko tych połączeń, których każda usługa faktycznie potrzebuje.
  • Łączność między lokalizacjami a chmurą: połączenie siedzib klientów i środowisk chmurowych tam, gdzie obsługiwane rozwiązania VPN odpowiadają wymaganiom.
  • Wzorce dla klientów MSP: zapewnienie dostawcom usług zarządzanych spójnej podstawy dla sieci klientów, z izolacją oceniana dla każdego środowiska.
  • Migracja etapowa: utrzymanie wymaganych połączeń podczas przenoszenia obciążeń między dotychczasową infrastrukturą a CloudSigma.

Zamierzoną korzyścią jest prostszy, bardziej powtarzalny projekt sieci, a nie obietnica, że każde obciążenie wymaga takiej samej konfiguracji. Zacznij od tego, co musi być połączone i co musi pozostać prywatne.

Co łączy CloudSigma Virtual Router

Wirtualny router przekazuje ruch IP między sieciami programowo, wykorzystując informacje o routingu do wyboru ścieżki wyjściowej.

Planowana oferta CloudSigma łączy łączność WAN i podstawowe usługi sieciowe w jednym modelu bramy, zamiast wymagać od klientów samodzielnego składania każdej podstawowej funkcji. Proponowany zestaw możliwości obejmuje siedem obszarów:

  • Routing statyczny i prywatne interfejsy sieciowe: definiowanie ścieżek między podłączonymi sieciami a innymi miejscami docelowymi.
  • Serwer DHCP: przekazywanie ustawień sieciowych klientom zamiast ręcznego konfigurowania każdego adresu.
  • Przekazywanie DNS: przekazywanie zapytań o rozpoznawanie nazw do nadrzędnego resolvera.
  • Destination NAT i przekierowanie portów: mapowanie wybranego ruchu przychodzącego na usługę wewnętrzną.
  • Przekierowanie adresów 1:1: mapowanie jednego adresu na inny tam, gdzie wymaga tego projekt sieci.
  • Zapora warstwy 4: kontrola ruchu na podstawie adresów sieciowych, protokołów transportowych i portów.
  • IPsec i OpenVPN: obsługa planowanych połączeń VPN, przy czym aktualne tryby i zakres dostępności wymagają potwierdzenia.

Jeden punkt konfiguracji może ułatwić przegląd zależności aplikacji i zapewnić wspólny wzorzec dla przyszłych środowisk. Routing, mapowanie adresów i polityka dostępu pozostają odrębnymi elementami: trasa sprawia, że miejsce docelowe jest osiągalne, a reguły zapory określają, jaki ruch jest dozwolony.

Pakiety przychodzące trafiają do wirtualnego routera; jego tablica routingu wskazuje wyszukiwanie trasy i wybraną ścieżkę wyjściową nad podstawą zasobów obliczeniowych.

Rysunek 1. Routing wybiera ścieżkę wyjściową. Jasne linie przedstawiają inne możliwe wyjścia, a nie zablokowany ruch.

Źródło opisuje model pojedynczej instancji, a nie potwierdzoną usługę zarządzaną ani projekt wysokiej dostępności. Przed wdrożeniem potwierdź aktualne możliwości, sposób podłączenia do sieci, publiczny adres IP i zakres ruchu, wydajność oraz odpowiedzialność operacyjną. Diagramy wyjaśniają koncepcje; nie są zwalidowanymi planami wdrożenia.

Jak to zrobić: połączenie aplikacji trójwarstwowej

Weźmy aplikację z publiczną usługą webową, prywatną warstwą aplikacyjną i prywatną bazą danych. Celem jest wyraźna ścieżka od warstwy webowej przez aplikacyjną do danych, bez dawania użytkownikom internetu bezpośredniego dostępu do warstw wewnętrznych.

  1. Rozdziel segmenty. Umieść obciążenia webowe, aplikacyjne i danych w odrębnych sieciach prywatnych z osobnymi podsieciami. Podłącz je przez obsługiwane interfejsy routera i sprawdź izolację na niższych warstwach. Reguły routera nie sprawdzają ruchu, który pozostaje w obrębie tej samej sieci LAN.
  2. Zdefiniuj wymagane ścieżki. Zapisz źródło, cel, protokół i port dla każdego dozwolonego połączenia. Skonfiguruj trasy i reguły dostępu dla ruchu z warstwy webowej do aplikacyjnej oraz z aplikacyjnej do bazy danych. Ogranicz administrowanie do zatwierdzonych źródeł i prywatnej ścieżki dostępu; nie przyznawaj ogólnego dostępu między warstwami.
  3. Udostępnij tylko usługę webową i przetestuj. Skonfiguruj wymagany destination NAT lub mapowanie portów do warstwy webowej, wraz z odpowiadającymi im regułami zapory. Pozostaw usługi aplikacyjne i bazodanowe niewystawione. Przetestuj dozwolone połączenia, ścieżki powrotne i odmowę dostępu, w tym próby dotarcia do bazy danych bezpośrednio z warstwy webowej lub z internetu.
  4. Przypisz odpowiedzialność operacyjną. Ustal, kto utrzymuje konfigurację, instaluje poprawki, wykonuje kopie zapasowe i prowadzi monitoring oraz w jaki sposób przeglądane są zmiany. Przed użyciem produkcyjnym sprawdź reprezentatywny ruch aplikacji i wymagania dotyczące odtwarzania. Aktualizuj mapę dostępu w miarę zmian w aplikacji.

Router z jawnie skonfigurowanymi trasami i polityką dostępu łączy się z warstwami Web, App i Data w trzech odrębnych prywatnych podsieciach.

Rysunek 2. Koncepcyjna segmentacja aplikacji: trzy sieci prywatne, z jawnie skonfigurowanymi trasami i polityką dostępu.

Omów z CloudSigma wymagania dotyczące łączności i dostępu Twojej aplikacji, aby ocenić, czy model Virtual Router pasuje do Twojego środowiska.

Cennik i potencjalne oszczędności

Model cenowy oferuje trzy opcje miesięczne:

Miesięczny cennik CloudSigma Virtual Router: Small $35, Medium $70, Large $140.

Dla ilustracji: Small za $35/miesiąc jest tańszy o $8,75 od porównywalnego miesięcznego kosztu sieci wynoszącego $43,75 — to oszczędność rzędu 20%. Jest to porównanie hipotetyczne, a nie zmierzony benchmark względem hiperskalerów. Rzeczywiste oszczędności zależą od regionu, ruchu, publicznych adresów IP, wymagań dotyczących VPN i zakresu wsparcia.

Przed wdrożeniem potwierdź dostępność pakietów i zakres wliczonych usług.


O CloudSigma

CloudSigma dostarcza elastyczną infrastrukturę chmurową dla przedsiębiorstw i dostawców usług, kładąc nacisk na lokalne świadczenie usług, współpracę z partnerami i kontrolę nad środowiskami chmurowymi.

Preslav Dobrev

Preslav Dobrev

Author · CloudSigma

Preslav Dobrev is a Creative designer at CloudSigma, focusing on consistent business identity using traditional and innovative marketing channels. He is adept at merging artistic vision with strategic marketing to create impactful brand narratives.

Comments

No comments yet. Be the first.