Jak przenieść serwer Minecraft na ochronę DDoS bez downtime

Po co w ogóle przenosić serwer pod ochronę

Jeśli czytasz ten poradnik, prawdopodobnie już spotkałeś się z atakami DDoS na swój serwer Minecraft. Albo jeszcze nie spotkałeś, ale rozumiesz, że to kwestia czasu. Ataki na serwery Minecraft to rzeczywistość, z którą żyją tysiące administratorów każdego dnia.

Główny strach przy podłączaniu ochrony DDoS to downtime. Gracze nie będą mogli wejść, ktoś pójdzie na inny serwer, donaty przepadną. Znajome? Dobra wiadomość: przy prawidłowym podejściu przeniesienie można zrobić w ogóle bez przestoju. Gracze nawet nie zauważą, że coś się zmieniło.

W tym poradniku omówimy cały proces krok po kroku - od przygotowania do końcowej weryfikacji.

Jak działa ochrona DDoS przez DNS

Zanim zaczniesz grzebać w ustawieniach, warto zrozumieć bazową zasadę. Większość usług ochrony (w tym MineGuard) działa według schematu reverse proxy:

1. Gracz łączy się z domeną twojego serwera (np. play.myserver.ru)
2. DNS kieruje go nie na twoje prawdziwe IP, tylko na IP filtra ochrony
3. Filtr sprawdza ruch, odsiewa śmieci
4. Czysty ruch jest przesyłany na twój prawdziwy serwer

Cała magia dzieje się na poziomie DNS. Po prostu zmieniasz, gdzie wskazuje domena - i ruch zaczyna iść przez filtr. Sam serwer przy tym dalej pracuje jak pracował.

Krok 1: Przygotowanie - backup i obniżenie TTL

Przed jakimikolwiek zmianami - backup. Tak, nie ruszamy samego serwera, ale nawyk robienia backupu przed każdą manipulacją uratował niejeden projekt.

Co zbackupować:

• Config strefy DNS (screenshot lub eksport rekordów)
• Ustawienia firewalla na serwerze
• Configi BungeeCord/Velocity, jeśli używasz proxy

Obniżamy TTL rekordów DNS

To krytycznie ważny krok, który wielu pomija. TTL (Time To Live) to czas, przez jaki DNS resolvery cache'ują rekord. Jeśli masz TTL ustawione na 86400 (24 godziny), to po zmianie DNS część graczy będzie chodzić na stare IP jeszcze całą dobę.

Wejdź w panel zarządzania DNS (Cloudflare, Hetzner DNS, dowolny inny dostawca) i ustaw TTL dla rekordu A twojej domeny gry na minimum - 60 lub 120 sekund. Zrób to 24-48 godzin przed przeniesieniem. Trzeba poczekać, aż stary wysoki TTL wygaśnie u wszystkich resolverów.

Jeśli używasz Cloudflare z włączonym proxowaniem (pomarańczowa chmurka) - TTL jest zarządzany automatycznie, tu nic nie trzeba zmieniać.

Krok 2: Rejestracja i konfiguracja ochrony

Rejestrujemy się w panelu zarządzania ochrony DDoS. Na przykładzie MineGuard:

1. Tworzymy konto na stronie
2. Dodajemy nową sieć (network) - to kontener dla ustawień twojego serwera
3. Wybieramy taryfę - na początek pasuje bazowa, później zawsze można skalować

Po utworzeniu sieci dostaniesz adres filtra - to może być adres IP lub rekord CNAME typu filter.mineguard.net. Właśnie na ten adres później skierujemy DNS.

Ważny moment: nie spiesz się od razu zmieniać DNS. Najpierw trzeba w pełni skonfigurować ochronę.

Krok 3: Dodanie domeny i backendu

W panelu ochrony trzeba wskazać dwa kluczowe parametry:

Domena (lub poddomena) - adres, pod którym gracze łączą się z serwerem. Na przykład play.myserver.ru lub po prostu myserver.ru.

Backend - prawdziwy adres IP twojego serwera Minecraft i port. Na przykład 185.100.50.25:25565. To adres, gdzie filtr będzie przesyłał czysty ruch.

W MineGuard robi się to w sekcji ustawień sieci:

• Backend Address: podajemy IP i port serwera
• Backend Protocol: TCP (standard dla Minecraft Java Edition)

Jeśli masz kilka serwerów za BungeeCord lub Velocity - wskazuj IP serwera proxy, a nie poszczególnych serwerów backendu.

Krok 4: Konfiguracja Proxy Protocol (jeśli potrzeba)

Proxy Protocol to sposób przekazywania prawdziwego adresu IP gracza przez proxy. Bez niego twój serwer będzie widział wszystkie połączenia jako idące z IP filtra, a nie od prawdziwych graczy.

Kiedy Proxy Protocol jest potrzebny:

• Chcesz widzieć prawdziwe IP w logach
• Masz system banów po IP
• Używasz pluginów, związanych z IP gracza

Kiedy można się bez niego obyć:

• Mały serwer, gdzie IP nie jest krytyczne
• Używasz autoryzacji tylko po nicku

Konfiguracja po stronie BungeeCord:

W config.yml BungeeCord znajdź sekcję listeners i dodaj:

listeners:
  - proxy_protocol: true

Dla Velocity w velocity.toml:

haproxy-protocol = true

Dla Paper/Spigot bezpośrednio (bez BungeeCord) potrzebny będzie plugin HAProxyDetector lub podobny.

Po włączeniu Proxy Protocol po stronie serwera - włącz go i w panelu ochrony. Kolejność jest ważna: najpierw serwer, potem ochrona. Jeśli włączyć Proxy Protocol tylko po jednej stronie, połączenia się popsują.

Krok 5: Przełączanie DNS

Wszystko skonfigurowane, przetestowane lokalnie (do tego wrócimy) - pora przełączyć DNS. To właściwie moment przeniesienia.

Wariant A: Używasz rekordu A

Wchodzimy w panel DNS i zmieniamy rekord A domeny gry z prawdziwego IP serwera na IP filtra ochrony.

Było:

play.myserver.ru  A  185.100.50.25

Jest:

play.myserver.ru  A  104.167.24.91

Wariant B: Używasz CNAME

Niektóre usługi ochrony dają rekord CNAME. W tym przypadku usuwamy stary rekord A i tworzymy CNAME:

play.myserver.ru  CNAME  yournetwork.filter.mineguard.net

Wariant C: Cloudflare + ochrona

Jeśli domena jest na Cloudflare, można użyć CNAME z włączonym proxowaniem (pomarańczowa chmurka). Cloudflare będzie proxował ruch HTTP/HTTPS, a dla ruchu gry Minecraft trzeba wyłączyć proxowanie (szara chmurka) i użyć zwykłego CNAME lub rekordu A na filtr.

Ważne żeby pamiętać: Cloudflare proxuje tylko ruch webowy. Gry TCP/UDP Minecrafta przez pomarańczową chmurkę nie pójdą (jeśli nie ma Cloudflare Spectrum, ale to drogie i osobny temat).

Po zapisaniu rekordu DNS zmiany zaczną się propagować. Dzięki niskiemu TTL, który ustawiliśmy w kroku 1, większość graczy przełączy się na nową trasę w ciągu kilku minut.

Krok 6: Sprawdzenie działania

DNS się zaktualizował, teraz sprawdzamy, że wszystko działa.

Sprawdzenie resolve DNS:

nslookup play.myserver.ru

lub

dig play.myserver.ru +short

W odpowiedzi powinien być IP filtra ochrony, a nie prawdziwy IP serwera.

Sprawdzenie połączenia:

Uruchamiamy klient Minecraft i łączymy się z serwerem po domenie. Jeśli wszedł normalnie, widzisz świat, możesz się ruszać - bazowe sprawdzenie przeszedł.

Sprawdzenie IP w logach:

Wejdź na serwer i popatrz na ostatni log. Jeśli Proxy Protocol jest skonfigurowany, w logach powinny być prawdziwe IP graczy, a nie IP filtra. Jeśli widzisz IP filtra - przeczytaj jeszcze raz krok 4.

Sprawdzenie przez panel ochrony:

W panelu MineGuard można zobaczyć aktywne połączenia, statystyki ruchu i bieżące zagrożenia. Jeśli widzisz przychodzące połączenia - znaczy ruch idzie przez filtr.

Sprawdzenie pingu:

Ping może się trochę podnieść (o 1-5 ms) z powodu dodatkowego hopa przez filtr. To normalne i niezauważalne dla graczy. Jeśli ping wzrósł znacznie (o 50+ ms), sprawdź geograficzne położenie filtra - idealnie powinien być bliżej głównej publiczności serwera.

Krok 7: Zamykamy bezpośredni dostęp do serwera

To krok, o którym zapominają najczęściej. Jeśli prawdziwe IP serwera jest znane atakującym (a najpewniej jest znane), po prostu będą bić bezpośrednio, omijając ochronę.

Konfiguracja firewalla:

Zezwalamy na połączenia przychodzące na port gry (25565) tylko z adresów IP filtra ochrony. W iptables wygląda to mniej więcej tak:

iptables -A INPUT -p tcp --dport 25565 -s IP_FILTRA -j ACCEPT
iptables -A INPUT -p tcp --dport 25565 -j DROP

Każda usługa ochrony ma listę adresów IP, z których przychodzi ruch. Upewnij się, że dodałeś wszystkie adresy, inaczej część graczy nie będzie mogła się połączyć.

Zmiana IP (jeśli skompromitowane):

Jeśli atakujący znają prawdziwe IP serwera, firewall pomoże od bezpośrednich ataków na port Minecrafta, ale nie uratuje od ataków volumetric na sam IP. Idealnie - zmienić IP u hostera i nikomu go nie pokazywać. Nowe IP wskazać tylko w ustawieniach ochrony jako backend.

Co robić, jeśli coś poszło nie tak

Gracze nie mogą się połączyć po zmianie DNS:

• Sprawdź, czy DNS się zaktualizował (nslookup/dig)
• Poproś graczy o wyczyszczenie cache DNS (ipconfig /flushdns na Windows)
• Sprawdź, czy adres backendu w panelu ochrony jest podany poprawnie
• Upewnij się, że firewall serwera zezwala na połączenia z IP filtra

Połączenie jest, ale serwer laguje:

• Sprawdź obciążenie na samym serwerze - może być niezwiązane z ochroną
• Zobacz, czy nie ma strat pakietów na trasie przez mtr lub traceroute
• Zwróć się do supportu usługi ochrony z wynikami diagnostyki

W logach IP filtra zamiast prawdziwych IP graczy:

• Proxy Protocol nie jest skonfigurowany lub jest skonfigurowany tylko po jednej stronie
• Przeczytaj krok 4 i sprawdź konfigurację i na serwerze, i w panelu ochrony

Część graczy wchodzi, część nie:

• DNS jeszcze się nie zaktualizował u wszystkich - poczekaj (zależy od starego TTL)
• Jeśli minęło więcej niż doba - problem jest w czym innym, sprawdzaj firewall i routing

Rollback: jeśli wszystko jest naprawdę źle, po prostu zwróć rekord DNS na poprzedni IP serwera. Po kilku minutach (dzięki niskiemu TTL) wszystko wróci jak było. Właśnie po to robiliśmy backup konfiguracji DNS.

Rekomendacje po przeniesieniu

Po udanym przeniesieniu nie zapomnij:

1. Podnieść TTL z powrotem do 3600-86400 sekund. Niski TTL tworzy zbędne obciążenie na serwery DNS.
2. Skonfigurować powiadomienia w panelu ochrony, żeby dostawać komunikaty o atakach.
3. Przestudiować ustawienia firewalla w panelu - można ograniczyć połączenia po wersji protokołu, włączyć capchę dla podejrzanych połączeń, skonfigurować rate limiting.
4. Nie ujawniać prawdziwego IP - nie wskazuj go w publicznych configach, rekordach DNS dla innych poddomen na tym samym IP, trackerach serwerów.
5. Sprawdzić rekordy SRV - jeśli używasz SRV dla Minecrafta, upewnij się, że też wskazują na chroniony adres.

Podsumowanie

Przeniesienie serwera Minecraft pod ochronę DDoS to nie rocket science. Cały proces sprowadza się do: przygotowałem DNS, skonfigurowałem filtr, przełączyłem rekord, sprawdziłem działanie. Przy prawidłowym przygotowaniu (zwłaszcza z niskim TTL) downtime wynosi zero.

Główne - nie spieszyć się i sprawdzać każdy krok. Lepiej wydać dodatkowe 30 minut na przygotowanie, niż potem zastanawiać się, czemu 200 graczy nie może wejść na serwer.