Konfiguracja sieci
Po uruchomieniu usługi serwera dedykowanego Klient otrzymuje parametry sieciowe niezbędne do podłączenia serwera do sieci publicznej oraz — jeżeli zostało to zamówione — do sieci prywatnej lub dodatkowych usług sieciowych. Konfiguracja sieciowa może obejmować publiczną adresację IP, interfejsy sieciowe serwera, rekordy DNS, sieć wewnętrzną oraz ochronę AntyDDoS.
Zakres dostępnych opcji zależy od konfiguracji usługi, rodzaju serwera, przydzielonej adresacji oraz dodatkowych usług zakupionych przez Klienta. Część informacji i operacji może być dostępna bezpośrednio w Strefie Klienta, natomiast niektóre zmiany mogą wymagać kontaktu z Atman poprzez zgłoszenie.
Publiczna adresacja IP
Publiczna adresacja IP umożliwia komunikację serwera z Internetem. Po uruchomieniu usługi Klient otrzymuje dane adresowe przypisane do serwera lub usługi sieciowej.
Standardowy zestaw informacji może obejmować:
Adres IP serwera — podstawowy publiczny adres IPv4 przypisany do usługi.
Maskę podsieci — parametr określający wielkość i zakres przydzielonej sieci.
Bramę domyślną — adres routera, przez który serwer komunikuje się z siecią zewnętrzną.
Dodatkowe adresy IP — jeżeli zostały zamówione, mogą być przypisane do tej samej usługi lub wykorzystywane przez maszyny wirtualne, usługi aplikacyjne, kontenery, firewalle, systemy wysokiej dostępności lub inne komponenty środowiska Klienta.
Adresację IPv6 — jeżeli jest dostępna i została przewidziana w konfiguracji usługi.
Po otrzymaniu danych sieciowych należy skonfigurować je w systemie operacyjnym serwera zgodnie z używaną dystrybucją lub systemem. W przypadku systemów Linux konfiguracja może być realizowana między innymi przez Netplan, NetworkManager, pliki konfiguracyjne interfejsów lub narzędzia właściwe dla danej dystrybucji. W systemach Windows konfiguracja odbywa się z poziomu ustawień karty sieciowej lub narzędzi administracyjnych systemu.
Po skonfigurowaniu adresacji należy wykonać podstawową weryfikację łączności:
sprawdzić, czy interfejs sieciowy jest aktywny,
sprawdzić poprawność adresu IP, maski i bramy,
wykonać test połączenia do bramy domyślnej,
wykonać test połączenia z Internetem,
zweryfikować działanie usług nasłuchujących na publicznym adresie IP,
sprawdzić reguły zapory systemowej, jeżeli usługi nie są dostępne z zewnątrz.
W przypadku problemów z komunikacją należy w pierwszej kolejności zweryfikować konfigurację systemu operacyjnego, status interfejsu sieciowego oraz reguły firewall. Jeżeli konfiguracja po stronie serwera jest poprawna, a problem nadal występuje, należy utworzyć zgłoszenie w Strefie Klienta.
Zarządzanie interfejsem sieciowym
Interfejs sieciowy serwera odpowiada za fizyczną lub logiczną komunikację serwera z siecią Atman oraz sieciami Klienta. W zależności od konfiguracji serwera może być dostępny jeden lub wiele interfejsów sieciowych.
Interfejsy mogą być wykorzystywane między innymi do:
Komunikacji publicznej — dostęp do Internetu oraz usług udostępnianych publicznie.
Komunikacji prywatnej — ruch wewnętrzny pomiędzy serwerami Klienta, środowiskami aplikacyjnymi, bazami danych lub systemami zaplecza.
Separacji ruchu — rozdzielenie ruchu produkcyjnego, administracyjnego, backupowego lub replikacyjnego.
Konfiguracji wysokiej dostępności — wykorzystanie wielu interfejsów, adresów IP lub mechanizmów redundancji po stronie systemu operacyjnego i aplikacji.
Wirtualizacji — przypisywanie adresów IP do maszyn wirtualnych, bridge’y, VLAN-ów lub interfejsów wirtualnych.
Po pierwszym uruchomieniu serwera należy sprawdzić, czy system operacyjny prawidłowo wykrywa karty sieciowe oraz czy aktywny jest właściwy interfejs. W szczególności warto zweryfikować:
nazwę interfejsu sieciowego,
status połączenia,
prędkość linku,
przypisaną adresację IP,
routing domyślny,
konfigurację DNS,
reguły firewalla,
ewentualną konfigurację VLAN, bridge, bondingu lub teaming.
W przypadku serwerów z wieloma kartami sieciowymi należy zwrócić uwagę, który port fizyczny odpowiada za komunikację publiczną, a który za komunikację prywatną lub administracyjną. Błędne przypisanie konfiguracji do niewłaściwego interfejsu może spowodować brak dostępu do serwera.
Jeżeli Klient planuje wdrożenie zaawansowanej konfiguracji sieciowej, takiej jak bonding, VLAN, bridge dla wirtualizacji, separacja ruchu aplikacyjnego lub środowisko HA, zalecane jest wcześniejsze zaplanowanie adresacji, routingu oraz podziału ról pomiędzy interfejsami.
Zarządzanie DNS
DNS umożliwia powiązanie nazw domenowych z adresami IP usług. Dzięki temu użytkownicy i aplikacje mogą korzystać z nazw, takich jak example.pl, zamiast bezpośrednich adresów IP.
W zależności od modelu obsługi domeny, rekordy DNS mogą być zarządzane:
Po stronie Klienta — u obecnego rejestratora domeny, operatora DNS lub w zewnętrznym panelu DNS.
Po stronie Atman — jeżeli Klient korzysta z usług DNS udostępnianych przez Atman lub domena została odpowiednio delegowana.
W zewnętrznych systemach DNS — na przykład u dostawców usług chmurowych, operatorów CDN, systemów ochrony aplikacyjnej lub wyspecjalizowanych dostawców DNS.
Najczęściej wykorzystywane rekordy DNS to:
A — wskazuje nazwę domenową na adres IPv5.
AAAA — wskazuje nazwę domenową na adres IPv6.
CNAME — tworzy alias do innej nazwy domenowej.
MX — określa serwery pocztowe obsługujące domenę.
TXT — wykorzystywany między innymi do SPF, DKIM, DMARC, weryfikacji domen i innych mechanizmów bezpieczeństwa.
PTR — rekord odwrotny, który mapuje adres IP na nazwę domenową. Jest szczególnie istotny przy konfiguracji usług pocztowych.
Po uruchomieniu serwera Klient może skierować domenę lub subdomenę na publiczny adres IP przypisany do usługi. W tym celu należy utworzyć lub zmodyfikować odpowiedni rekord DNS, najczęściej rekord typu A.
Należy pamiętać, że zmiany w DNS mogą nie być widoczne natychmiast. Czas propagacji zależy od ustawień TTL, operatora DNS oraz pamięci podręcznych po stronie resolverów. W praktyce część zmian może być widoczna po kilku minutach, ale pełna propagacja może potrwać dłużej.
W przypadku usług pocztowych należy dodatkowo zwrócić uwagę na poprawną konfigurację rekordów MX, SPF, DKIM, DMARC oraz PTR. Brak prawidłowej konfiguracji DNS może wpływać na dostarczalność wiadomości e-mail.
Sieć wewnętrzna
Sieć wewnętrzna umożliwia komunikację pomiędzy usługami Klienta bez konieczności wykorzystywania publicznego Internetu. Może być stosowana do budowy środowisk wieloserwerowych, systemów aplikacyjnych, baz danych, klastrów, backupu, replikacji oraz środowisk wysokiej dostępności.
Sieć wewnętrzna może być wykorzystywana między innymi do:
Komunikacji aplikacja–baza danych
Serwer aplikacyjny może komunikować się z serwerem bazodanowym po adresacji prywatnej, bez wystawiania bazy danych do Internetu.
Komunikacji pomiędzy serwerami Klienta
Kilka serwerów dedykowanych może wymieniać dane w ramach jednej wydzielonej sieci prywatnej.
Backupu i replikacji
Ruch związany z kopiami zapasowymi lub replikacją może być oddzielony od ruchu publicznego.
Środowisk HA
Sieć prywatna może być wykorzystywana do komunikacji pomiędzy węzłami klastra, synchronizacji stanu usług, heartbeatów oraz replikacji danych.
Separacji warstw środowiska
Możliwe jest rozdzielenie warstwy frontendowej, backendowej, bazodanowej i administracyjnej.
W przypadku korzystania z sieci wewnętrznej Klient powinien zaplanować prywatną adresację IP oraz sposób komunikacji pomiędzy serwerami. Najczęściej stosuje się adresację prywatną z zakresów RFC1918, na przykład:
10.0.0.0/8,
172.16.0.0/12,
192.168.0.0/16.
Po stronie systemu operacyjnego należy skonfigurować dodatkowy interfejs lub dodatkową adresację przypisaną do interfejsu prywatnego. W konfiguracji należy zwrócić uwagę, aby domyślna trasa do Internetu pozostała przypisana do interfejsu publicznego, a ruch wewnętrzny był kierowany przez interfejs prywatny.
W przypadku bardziej złożonych środowisk warto przygotować prosty plan adresacji, obejmujący:
nazwy serwerów,
adresy publiczne,
adresy prywatne,
role poszczególnych serwerów,
wymagane porty komunikacyjne,
reguły firewall,
wymagania dotyczące routingu,
zależności pomiędzy usługami.
Dostępność sieci wewnętrznej oraz sposób jej uruchomienia zależą od zamówionej konfiguracji. Jeżeli Klient chce połączyć kilka usług w jednej sieci prywatnej lub uruchomić dodatkową separację ruchu, powinien zweryfikować dostępne opcje w Strefie Klienta albo utworzyć zgłoszenie do Atman.
Ochrona AntyDDoS
Ochrona AntyDDoS służy do ograniczania skutków ataków typu Distributed Denial of Service, których celem jest zakłócenie dostępności usług przez wygenerowanie dużego wolumenu ruchu lub ruchu o charakterze aplikacyjnym/protokolarnym.
W przypadku serwerów dedykowanych ochrona AntyDDoS może być dostępna jako element usługi lub jako dodatkowa usługa przypisana do środowiska Klienta. Zakres ochrony zależy od wybranego wariantu usługi oraz konfiguracji sieciowej.
Ochrona AntyDDoS może obejmować między innymi:
Monitorowanie ruchu sieciowego
Ruch kierowany do usług Klienta jest analizowany pod kątem anomalii i wzorców charakterystycznych dla ataków DDoS.
Mitygację ataków wolumetrycznych
Systemy ochrony ograniczają wpływ dużych wolumenów niepożądanego ruchu na dostępność usług.
Filtrowanie ruchu niepożądanego
W zależności od charakteru ataku, ruch może być filtrowany lub ograniczany przed dotarciem do infrastruktury Klienta.
Ochronę dostępności usług
Celem usługi jest utrzymanie możliwie najwyższej dostępności zasobów Klienta w trakcie incydentu.
Obsługę operacyjną przez Atman
W razie problemów lub podejrzenia ataku Klient może kontaktować się z Atman poprzez zgłoszenie w Strefie Klienta.
Po uruchomieniu usługi Klient powinien zweryfikować, czy ochrona AntyDDoS jest aktywna dla właściwej usługi lub adresacji IP. Jeżeli ochrona jest prezentowana w Strefie Klienta jako osobna usługa, należy traktować ją jako element zabezpieczenia środowiska.
W przypadku podejrzenia ataku DDoS należy:
sprawdzić, czy problem dotyczy jednej usługi, wielu usług czy całej adresacji,
zweryfikować obciążenie serwera,
sprawdzić logi systemowe i aplikacyjne,
sprawdzić statystyki ruchu, jeżeli są dostępne,
ograniczyć zbędne publiczne usługi i porty,
utworzyć zgłoszenie w Strefie Klienta z opisem objawów.
W zgłoszeniu warto podać:
adres IP objęty problemem,
czas rozpoczęcia incydentu,
rodzaj niedostępnej usługi,
obserwowane objawy,
przykładowe logi lub komunikaty,
informację, czy problem występuje stale, czy okresowo,
informację, czy Klient obserwuje nietypowy ruch po stronie serwera.
Ochrona AntyDDoS nie zastępuje poprawnej konfiguracji bezpieczeństwa systemu operacyjnego i aplikacji. Klient nadal powinien stosować firewall, aktualizować system, ograniczać dostęp do usług administracyjnych, zabezpieczać aplikacje oraz monitorować własne środowisko. AntyDDoS należy traktować jako warstwę ochrony sieciowej, której celem jest zwiększenie odporności usługi na ataki przeciążeniowe.