Firewall pentru serverul Metin2 pe FreeBSD, fără să blochezi jucătorii

Serverul tău Metin2 ascultă pe multe porturi: unele pentru jucători, altele doar pentru „discuțiile interne” dintre procesele jocului și pentru baza de date. Dacă toate sunt deschise spre internet, oricine poate bate la ușa bazei tale de date. Un **firewall** lasă să treacă doar ce trebuie. Dar un firewall greșit te poate bloca și pe tine, și pe jucători, deci îl punem cu grijă.

Cuvinte pe care le vei întâlni

Ce porturi trebuie să fie publice și care nu

Exemplul de mai jos e din pachetul pe care l-am verificat. Numerele tale le găsești în fișierele CONFIG (vezi lecția despre CONFIG și porturi).

De ce e nevoie de toate porturile PORT ale canalului, nu doar de primul? Pentru că fiecare proces al canalului ține alte hărți. Când jucătorul se mută pe o hartă din alt proces, clientul se conectează la portul acelui proces. Dacă uiți unul, jucătorii rămân blocați la teleportarea pe anumite hărți.

Ca să vezi toate porturile pentru jucători dintr-o dată:

find /usr/home/game -name CONFIG -exec grep -H "^PORT" {} +

(Calea e un exemplu.) Iar ca să vezi ce ascultă de fapt serverul, cu jocul pornit:

sockstat -4 -l

Pasul 1: Află numele interfeței de rețea

ifconfig

Caută blocul care are IP-ul public al serverului (de exemplu inet 203.0.113.10). Numele de la începutul blocului, de exemplu vtnet0:, e interfața ta. Nu alege lo0: aceea e doar „în interiorul” serverului.

Pasul 2: Scrie regulile

Fă o copie dacă fișierul există deja, apoi creează /etc/pf.conf cu acest conținut (înlocuiește vtnet0 și porturile cu ale tale):

ext_if = "vtnet0"
ssh_port = "22"
joc_tcp = "{ 11000, 13000, 13001, 13002, 13010, 13011, 13012, 13099 }"

set skip on lo0

block in all
pass out all keep state
pass in on $ext_if proto tcp to port $ssh_port keep state
pass in on $ext_if proto tcp to port $joc_tcp keep state
pass in on $ext_if inet proto icmp all keep state

Rând cu rând:

La pf, ultima regulă care se potrivește câștigă. De aceea block in all stă sus, iar excepțiile (pass) vin după. Porturile care nu apar în nicio regulă pass, cum sunt 15000, 14000 sau 3306, rămân blocate din afară.

Pasul 3: Verifică regulile fără să le aplici

pfctl -nf /etc/pf.conf

-n înseamnă „doar verifică, nu aplica”. Dacă nu afișează nimic, sintaxa e corectă. Dacă vezi o eroare cu număr de rând, corectează acel rând.

Pasul 4: Pornește cu plasă de siguranță

Pornirea firewall-ului printr-o sesiune SSH poate „îngheța” chiar fereastra în care lucrezi. De aceea pornim întâi un cronometru care oprește firewall-ul singur după 5 minute (300 de secunde), orice s-ar întâmpla:

nohup sh -c "sleep 300; pfctl -d" &
sysrc pf_enable=YES
service pf start

Bucată cu bucată: prima linie pornește cronometrul în fundal (nohup îl ține viu chiar dacă se închide fereastra; poate apărea un fișier nohup.out, e normal). sysrc pf_enable=YES spune sistemului să pornească pf și după restart. service pf start îl pornește acum.

În cele 5 minute, din ferestre noi:

1. Intră pe SSH. Trebuie să meargă.
2. Intră în joc, alege fiecare canal și teleportează-te pe câteva hărți.

Dacă totul merge, pornește din nou firewall-ul după ce cronometrul l-a oprit:

service pf restart

Ce ar trebui să vezi: pfctl -s rules afișează regulile tale, iar jucătorii intră normal. Dacă ceva nu a mers, așteaptă cele 5 minute, firewall-ul se oprește singur, corectezi și reîncerci.

Dacă te-ai blocat oricum: intră prin consola de urgență a firmei de hosting și scrie pfctl -d (oprește pf).

Pasul 5: Verifică din afară

De pe calculatorul tău, în PowerShell:

Test-NetConnection 203.0.113.10 -Port 11000
Test-NetConnection 203.0.113.10 -Port 3306

Ce ar trebui să vezi: la 11000, TcpTestSucceeded : True. La 3306, False. Testezi doar serverul tău, nu al altora.

MySQL: încă un strat

Chiar dacă firewall-ul îl blochează, e bine ca MySQL să asculte doar „în interior”. Uită-te cu sockstat -4 -l | grep 3306. Dacă vezi 127.0.0.1:3306, e perfect. Dacă vezi *:3306, în fișierul de configurare MySQL se poate pune bind-address = 127.0.0.1. Locul fișierului diferă de la o instalare la alta, deci fă asta întâi pe serverul de test.

Firewall-ul nu oprește atacurile DDoS

Un firewall pe server decide ce porturi sunt deschise. Nu poate opri un atac DDoS mare: traficul acela umple „țeava” până la server înainte ca pf să apuce să-l vadă. Pentru asta e nevoie de filtrare la nivel de rețea, înainte de server. La Zentaris Host, serverele au protecție Anti-DDoS la nivel de rețea. Detalii în articolul despre protecția DDoS pentru Metin2.

Greșeli des întâlnite

• Ai uitat portul SSH în reguli. Te blochezi afară la prima repornire.
• Ai deschis doar primul port al canalului. Jucătorii intră, dar nu se pot teleporta pe unele hărți.
• Ai adăugat un canal nou și nu l-ai trecut în pf.conf. Canalul apare „offline” pentru toată lumea.
• Ai deschis 3306 „ca să meargă” un program de pe PC-ul tău. Folosește în schimb un tunel SSH sau un panou web protejat.
• Ai pornit și pf, și ipfw. Alege unul singur.

Întrebări frecvente

Pot folosi ipfw în loc de pf?

Da, FreeBSD le are pe amândouă. Logica e aceeași: blochezi tot, deschizi SSH și porturile jocului. Alege unul și folosește-l doar pe el.

Trebuie să deschid și porturile P2P?

Nu, dacă toate canalele sunt pe același server. P2P e traficul dintre procesele jocului, care rămâne în interior.

După restartul serverului, firewall-ul mai e pornit?

Da, dacă ai rulat sysrc pf_enable=YES. Verifici cu service pf status.

Ce urmează

SSH și porturile sunt închise. Dar mai sunt și alte uși: site, panou, baze de date, patcher. Le iei pe rând în lecția despre protecția împotriva accesului neautorizat. Toate lecțiile sunt în lista tutorialelor Metin2.