🛡️ Konfigurowalny sieciowy zapora Trooper.AI

Przepływ ruchu

Twoja serwer GPU działa za naszą infrastrukturą NAT i warstwą bezpieczeństwa sieciowego, co oznacza, że cały ruch przechodzi przez nasz firewall sieciowy Trooper.AI zanim dotrze do serwera.

Ruch jest domyślnie blokowany, ale można go włączyć przez ustawienia zapory sieciowej, jeśli jest to konieczne.

Ta architektura pozwala na centralne zarządzanie bezpieczeństwem sieci, pozwalając jednocześnie w pełni skupić się na tworzeniu i uruchamianiu obciążeń związanych ze sztuczną inteligencją.

Jak korzystać z wbudowanego Firewalla na poziomie sieci

Interfejs zapory sieciowej Trooper.AI zapewnia rodzimą zaporę umieszczoną bezpośrednio przed Twoim serwerem GPU. Pozwala to kontrolować ruch sieciowy przed dotarciem pakietów do systemu operacyjnego serwera GPU. Możesz również ograniczać wychodzący ruch, jeśli zechcesz, dla celów bezpieczeństwa lub wydajności.

Ta warstwa bezpieczeństwa jest całkowicie zintegrowana z infrastrukturą Trooper.AI i dostępna przez Akcja > „Reguły zapory”.

Interfejs działa w następujący sposób:

• (1) Tabela zasad – Wyświetla wszystkie skonfigurowane zasady firewalla. Zasady można sortować, edytować lub usuwać.
• (2) Domyślne trasy – Określa domyślne zachowanie dla ruchu, który nie pasuje do żadnej reguły.
• (3) Edytor zasad – Dodawaj nowe zasady opierając się na zakresach portów, zakresach adresów IP oraz akcji (Zezwól/Zablokuj)

Ta konstrukcja pozwala kontrolować ekspozycję sieciową twojego serwera GPU bez modyfikacji konfiguracji systemu operacyjnego.

Zewnętrzny Zapora Sieciowa

Firewall sieciowy poziomu Trooper.AI zapewnia precyzyjną kontrolę nad wyjściowym ruchem sieciowym pochodzącym z Twojego serwera GPU Blib. Ta funkcja umożliwia organizacjom wdrażanie ścisłych środków zgodności regulacyjnej, optymalizację wykorzystania pasma oraz poprawę bezpieczeństwa operacyjnego.

Uwaga: Zasady wyjściowe mogą blokować lub ograniczać prędkość pobierania pakietów i modeli (apt, pip, Hugging Face). W przypadku problemów z połączeniem sprawdź najpierw reguły zapory sieciowej.

Interfejs działa w następujący sposób:

• (1) Tabela zasad – Wyświetla wszystkie skonfigurowane zasady firewalla wyjściowego. Zasady można sortować, edytować lub usuwać.
• (2) Domyślne trasy – Wychodzący ruch jest domyślnie zezwolony.
• (3) Edytor zasad – Dodawaj nowe zasady opierając się na zakresach portów, zakresach adresów IP oraz akcji (Zezwól/Zablokuj). Dla reguły zezwalającej można ustawić limit prędkości do maksymalnie 50 Mbit/s.

Wdrożenie zapory sieciowej zapewnia całkowite oddzielenie między wdrażaniem polityki bezpieczeństwa a środowiskiem wykonawczym serwera:

• Wszelkie filtrowanie odbywa się na warstwie infrastruktury sieciowej przed transmisją pakietów
• Procesy aplikacyjne nie mają widoczności ani możliwości modyfikacji konfiguracji zapory sieciowej
• Ochrona przed potencjalnym naruszeniem składników serwerowych próbujących ominąć ograniczenia

Zalecane presetowe reguły zapory sieciowej

Aby ułatwić zabezpieczenie wychodzącego ruchu, Trooper.AI oferuje dwa gotowe zestawy domyślne, które polecamy do ogólnego użytku. Możesz zastosować jeden z nich automatycznie podczas zamawiania nowego serwera GPU Blib – wystarczy wybrać go w oknie zamówienia i zostanie skonfigurowany od razu po uruchomieniu serwera, bez konieczności ręcznego tworzenia reguł. Wolisz zdecydować później? Zamów z opcją „Brak ustawień domyślnych” i odtwórz dowolny zestaw samodzielnie w każdej chwili przez panel administracyjny.

Oba zestawy reguł kształtują jedynie ruch wychodzący (twoja maszyna → internet). Porty publiczne wejściowe oraz SSH pozostają domyślnie otwarte, a zasady są oceniane od góry do dołu — pierwsze dopasowane правило wygrywa

• 🟢 Zrównoważony — nastepna domyślna rekomendacja dla prawie wszystkich: pozostaje całkowicie otwarty na standardową pracę z AI, jednocześnie cicho blokując znane spam, robaki i nadużycia botnetów.
• 🔴 Rygorystyczny — ścisła lista dopuszczonych połączeń dla czystych serwerów inferencji, które potrzebują tylko niezbędnych usług.

Aplikuj przy zamówieniu lub odtwórz później samodzielnie: wybierz zestaw domyślny w oknie zamówienia, aby został zastosowany automatycznie, albo odtwórz go każdego razu pod Zarządzaj → Twój serwer → 🛡️ Zapora sieciowa → Wychodzący korzystając z poniższych tabel.

Zawsze włączona ochrona (wszystkie wstępne ustawienia, w tym „Brak wstępnego ustawienia“): wielowarstwowe mitygowanie ataków typu DDoS, limity połączeń/zalaniania na poziomie IP, izolacja klientów oraz ochrona wyjścia sieci prywatnych (RFC1918) są automatycznie stosowane i nie mogą zostać wyłączone.

🔴 Zrównoważony (zalecany)

Wszystko pozostaje otwarte dla normalnej pracy z AI — apt, pip/uv, Hugging Face, Docker, baz danych oraz własnych API — podczas gdy zestaw blokad zgodny z najlepszymi praktykami branżowymi zapobiega nadużyciom spamu, robaków i sieci botów. UDP wychodzący jest wyłączony domyślnie, oprócz DNS i synchronizacji czasu.

Efekt końcowy: całe wychodzące połączenia TCP pozostają otwarte z wyjątkiem wymienionych portów wykorzystywanych do nadużyć; wychodzący ruch UDP jest ograniczony tylko do DNS (53) i NTP (123). Protokół QUIC/HTTP-3 automatycznie przechodzi na TCP 443, dzięki czemu pobieranie danych nie ulega zakłóceniu. ICMP (ping / odkrywanie ścieżki MTU) pozostaje nadal dostępny.

🔴 Surowy (Zaawansowany)

Wyjściowe dostępne są tylko niezbędności — idealnie dla czystych urządzeń inferencji/AI. Wszystko poza listą zezwoleniami jest blokowane (domyślnie zablokuj).

Efekt końcowy: apt, pip/uv, git (HTTPS oraz SSH), pobieranie z Hugging Face i Docker działają poprawnie; wszystko na niestandardowych portach jest blokowane. ICMP pozostaje dostępny. Najlepiej działa, gdy Twoje aplikacje korzystają tylko ze standardowych portów.

🔒 Blokada IP dla SSH (opcjonalnie)

Jeśli włączono podczas zamawiania, dodane zostaną dwa zasady przychodzące, dzięki którym tylko Twój adres IP może uzyskać dostęp do SSH, podczas gdy Twoje publiczne porty aplikacji pozostają otwarte dla wszystkich:

Jeśli się zmieni Twój adres IP, zaktualizuj źródło w Zarządzaj → Zapora sieciowa → Wejściowe.

Jak zweryfikować lub odtworzyć

• Sprawdź: otwórz Zarządzaj → Twój serwer → 🛡️ Zapora sieciowa → Wychodzące. Złoty znacznik na karcie pokazuje, ile reguł jest aktywnych; porównaj je z tabelą powyżej.
• Odtwórz na istniejącej maszynie: w zakładce Wychodzące, dodaj jedno правило na wiersz w tej samej kolejności (górne = najwyższy priorytet), następnie kliknij Aplikuj teraz
• Możesz zrobić to później: zacznij od Brak wstępnych ustawień, a reguły dodaj kiedy tylko zechcesz – zmiany wejdą w życie po kliknięciu Aktualizuj teraz

Reguły są sprawdzane od góry do dołu – pierwsze dopasowanie wygrywa. Trzymaj dwie reguły Zezwalaj dla DNS/NTP wyżej niż każdą ogólną regułę Blokuj, w przeciwnym razie rozpoznawanie nazw i synchronizacja czasu ulegną awarii.

Rozwiązywanie problemów

Sprawdź te kroki, jeśli nie możesz się połączyć z usługami na swoim serwerze GPU po wprowadzeniu zmian w Firewalle lub warstwie sieciowej. Jeśli nadal nie masz dostępu do maszyny, najpierw sprawdź ustawienia firewalla, a następnie skontaktuj się z nami: Kontakt z wsparciem

WAŻNE: Wyłączanie lokalnej Zapory Sieciowej (jeśli została przypadkowo włączona)

Jeśli lokalny zapora sieciowa, taka jak UFW, została włączona na serwerze i powoduje problemy z łącznością, można ją wyłączyć za pomocą:

sudo ufw disable

Wyjście:

Firewall stopped and disabled on system startup

Następnie wyłącz usługę:

sudo systemctl disable ufw

Wyjście:

Synchronizing state of ufw.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install disable ufw
Removed /etc/systemd/system/multi-user.target.wants/ufw.service.

Powinieneś całkowicie usunąć wszelką lokalną Zaporę sieciową na swoim serwerze GPU. To ułatwi Ci życie!

Rozwiązywanie problemów: Dlaczego moje reguły zapory sieciowej nie działają zgodnie z oczekiwaniami?

Reguły zapory sieciowej są oceniawane od góry do dołu.

Pierwsza reguła dopasowująca ruch zostanie zastosowana, a żadne kolejne nie będą sprawdzane.

Przykład nieprawidłowej kolejności:

1  Deny  0.0.0.0/0      Port 14141
2  Allow 78.168.0.0/16  Port 14141

W tym przypadku reguła 1 blokuje cały ruch SSH zanim reguła 2 zostanie osiągnięta.

Prawidłowa kolejność:

1  Allow 78.168.0.0/16  Port 14141
2  Deny  0.0.0.0/0      Port 14141

Zawsze umieszczać bardziej specyficzne reguły zezwalające powyżej ogólnych reguł blokujących

Rozwiązywanie problemów: Dlaczego moja reguła zapory sieciowej nie pasuje do mojego adresu IP?

Reguły zapory sieciowej używają zakresów CIDR, aby określić dopuszczalne lub zablokowane adresy IP.

Upewnij się, że zakres faktycznie obejmuje Twój adres IP.

Przykłady:

Jeśli zakres CIDR jest nieprawidłowy, reguła zapory ogniowej nigdy nie dopasuje się do Twojego połączenia.

Rozwiązywanie problemów: Dlaczego mój port jest nadal zablokowany?

Upewnij się, że w zaporze jest poprawny port zezwolony. Poprawne porty znajdziesz w panelu zarządzania Twojego Bliba. Jeśli w zaporze zostanie dopuszczony nieprawidłowy port, ruch nigdy nie dotrze do Twojego serwera z kartą graficzną.

Rozwiązywanie problemów: Zrozumienie kontroli ruchu wychodzącego lub dlaczego połączenie wychodzące nadal działa?

Ruch wyjściowy w zaporze Trooper.AI odnosi się wyłącznie do aktywnie inicjowanych połączeń sieciowych przez Twoją kartę GPU Server Blib. Ta różnica jasno określa, że:

• „Wychodzące połączenia” = Połączenia, w których serwer działa jako klient (inicjujący komunikację).
• «Ruch zwrotny» = Odpowiedzi na wcześniej nawiązane połączenia przychodzące (gdy zewnętrzne systemy pełnią rolę klientów)
• Możesz ograniczyć wychodzący ruch SSH jednocześnie utrzymując dostęp SSH wejściowy dla połączeń zdalnych.
• Ograniczenia ruchu wychodzącego stosują się równomiernie do wszystkich protokołów – włączając HTTP. Nawet jeśli skonfigurujesz ZABRONIONE dla wszystkich portów wychodzących, usługi oparte na HTTP, takie jak WebProxy, Jupyter i OpenWebUI, nadal będą działać, ponieważ ich połączenia pochodzą zewnętrznie, co oznacza, że polegają one na ruchu przychodzącym

Uwaga ważna: Zezwolony połączenie przychodzące może generować legalny ruch powrotny w celu utrzymania ciągłości sesji – pozostaje ono niezależne od reguł wyjściowych, chyba że zostały one jawnie ograniczone.

Wszystkie zasady dotyczące wychodzącego ruchu dotyczyją wyłącznie połączeń zainicjowanych wewnętrznie przez instancję Twojego serwera GPU.

Rozwiązywanie problemów: Dlaczego APT/PIP lub inne zadania systemowe przestały działać?

🚨 Upewnij się, że Twoje reguły zapory wyjściowej pozwalają na niezbędny dostęp sieciowy dla menedżerów pakietów (pip, apt-get) oraz aktualizatorów systemowych w celu bezpiecznego pobierania krytycznych łatek i aktualizacji systemu operacyjnego. Sprawdź, czy standardowe repozytoria i serwery aktualizacji są dodane do białej listy, aby zapewnić płynne rozdzielanie zależności i operacje konserwacyjne.

Rozwiązywanie problemów: Dlaczego interfejs sieciowy jest zablokowany?

Zabezpieczenie sieciowe Trooper.AI kontroluje wszystkie wejściowe i wyjściowe porty, w tym te wykorzystywane przez interfejsy internetowe.

Jeśli port używany przez usługi takie jak:

• OpenWebUI
• Notatnik Jupyter
• panele sterowania
• niestandardowe narzędzia AI

interfejs sieciowy będzie również niedostępny, jeśli jest zablokowany w firewalle.

Wspólną bezpieczną konfiguracją jest ograniczenie dostępu do zakresu adresów IP twojej firmy.

Przykład:

Allow 203.0.113.0/24  Port 14511
Deny  0.0.0.0/0       Port 14511

Pozwala to tylko użytkownikom z Twojej organizacji uzyskać dostęp do bezpiecznego interfejsu sieciowego.

Rozwiązywanie problemów: Dlaczego SSH jest niedostępne?

W przypadku niepowodzenia dostępu SSH, sprawdź następujące elementy:

1. Nie instaluj lokalnej zapory sieciowej UFW, która zablokuje twój wewnętrzny port SSH 22
2. Twój adres IP musi znajdować się w dopuszczalnym zakresie CIDR
3. Reguła zezwalająca na publiczny port SSH (np. 14511 – nie 22, bo to jest port wewnętrzny) musi znajdować się powyżej wszelkich reguł blokujących.

Ponadto sprawdź ustawienie SSH Allow na samym dole tabeli konfiguracji zapory.

Jeśli SSH jest wyłączone na dole ustawień zapory ogniowej, serwer będzie akceptował połączenia SSH tylko z adresów IP, które są dozwolone przez powyższe reguły.

Rozwiązywanie problemów: Dlaczego ruch jest nadal blokowany, mimo że dodałem regułę?

Ruchnik, który nie pasuje do żadnej reguły, będzie kierowany zgodnie z Domyslnymi Szlakami określonymi w ustawieniach zapory sieciowej.

Jeśli reguła nie dopasuje się dokładnie (zły zakres adresów IP, zły port lub złe ustawienie kolejności), ruch może przejść do domyślnej reguły odrzucenia.

Zawsze weryfikuj:

• kolejność reguł - wygrywa pierwsze dopasowanie (od góry do dołu)
• Zakres CIDR - zobacz przykłady
• numer portu - widoczny na pulpicie zarządzania
• domyślne zachowanie trasy

Ostateczna sprawdzenie: Spróbuj kliknąć UMOŻLIW TUTAJ WSZYSTKO i sprawdź, czy działa. Jeśli tak, problemem jest reguła wyżej, która nie pasuje poprawnie.