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.
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.
- 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.
- 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.
- 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.
- 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.
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:
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.



Comments
No comments yet. Be the first.