Mir war es schon immer ein Dorn im Auge, dass die SRCDS-Server (Source/EP1-Engine) nicht immer hochfahren. Meine Vermutung lag war schon immer, dass der Server auf eine Verbindung zum Masterserver wartet.
Ich habe den Server so oft restartet, bis dieser nicht mehr online kam. Danach hab ich einen strace des Prozesses gemacht:
|
Quellcode
|
1
2
3
4
|
server@*****:~$ strace -p 9899 -s 80
Process 9899 attached - interrupt to quit
[ Process PID=9899 runs in 32 bit mode. ]
connect(17, {sa_family=AF_INET, sin_port=htons(27038), sin_addr=inet_addr("68.142.88.34")}, 16
|
Es kamen keine weiteren Meldungen, da der Server brav auf eine Antwort wartet, die er nie bekommen wird.
Ich hab dann kurz nach der IP gegoogelt und bin dann in der HLDS-Mailing-List gelandet.
In folgendem Thread wird das Problem beschrieben:
HLDS-Mailing-List
Die IP 68.142.88.34 ist ein Masterserver, der eigentlich schon vor längerer Zeit entfernt wurde. Die Adresse ist in den Binärdateien hardcoded. Der Port für den Server ist 27038
Hier der Beweis:
|
|
Quellcode
|
1
2
3
4
|
server@*****:~/server/pub_css/srcds/bin$ grep "68.142.88.34:27038" *
Übereinstimmungen in Binärdatei engine_amd.so.
Übereinstimmungen in Binärdatei engine_i486.so.
Übereinstimmungen in Binärdatei engine_i686.so.
|
Hier noch ein Thread mit einem Lösungsansatz:
HLDS-Mailing-List
In dem Thread wird beschrieben wie man mittels IP-Tables einfach eine Regel hinzugefügt. Da diese für Linux-Router (für Homeserver) ist, kommt die Regel für Root-Server (Server im Rechenzentrum) nicht in Frage.
Hier die Regel für Root-Server
Ab hier sollte der Admin wissen, was er macht. Man kann sich mit falschen Firewallregeln ganz schnell selbst aussperren. In so einem Fall hilft ein Reboot, da die Regeln nicht gespeichert sind.
Mit der Folgenden Regel kann man auf dem Root-Server ein "reject" festlegen (als
Root):
|
|
Quellcode
|
1
|
iptables -A OUTPUT -p tcp -d 68.142.88.34 --dport 27038 -j REJECT
|
Die Regel kann auch wieder folgendermaßen entfernt werden (als
Root):
|
|
Quellcode
|
1
|
iptables -D OUTPUT -p tcp -d 68.142.88.34 --dport 27038 -j REJECT
|
Oder alle Regeln entfernen:
|
|
Quellcode
|
1
|
iptables --flush
|
Hier der Test:
|
|
Quellcode
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
*****:~# iptables --flush
*****:~# time telnet 68.142.88.34 27038
Trying 68.142.88.34...
(mit STRG+C abgebrochen, dauert mir zu lange)
real 0m51.531s
user 0m0.000s
sys 0m0.000s
*****:~# iptables -A OUTPUT -p tcp -d 68.142.88.34 --dport 27038 -j REJECT
*****:~# time telnet 68.142.88.34 27038
Trying 68.142.88.34...
telnet: Unable to connect to remote host: Connection refused
real 0m3.001s
user 0m0.000s
sys 0m0.000s
|
Mit aktivierter Firewall-Regel wird der Verbindungsaufbau über Telnet nach 3 Sekunden abgebrochen.
Nachdem ich die Regel hinzugefügt habe, blieb der Server auch nach mehreren Restarts nicht mehr vor Meldung "Adding master server ...." stehen.
Damit auch nach dem Neustart die Firewallregeln wieder geladen werden, kann man bei Debian folgendermaßen vorgehen:
(Hier auch wieder als root anmelden)
Sollten ab diesen Schritten falsche Firewallregeln gespeichert werden, kann sich der Admin selbst aussperren. In diese Fall hilft dann nur noch das Notfallsystem (bietet fast jeder Anbieter im WI an) oder der Support, welcher in den meisten Fällen teuer ist.
|
|
Quellcode
|
1
|
iptables-save > /etc/firewall.conf
|
Dieser Befehl speichert alle aktuellen Regeln in der Datei /etc/firewall.conf.
|
|
Quellcode
|
1
2
3
|
echo "#!/bin/sh" > /etc/network/if-up.d/iptables
echo "iptables-restore < /etc/firewall.conf" >> /etc/network/if-up.d/iptables
chmod +x /etc/network/if-up.d/iptables
|
Die ersten beiden Befehle, die mit echo anfangen, speichern den Text in der Datei /etc/network/if-up.d/iptables. Der Befehl "iptables-restore < /etc/firewall.conf" stellt die Regeln wieder her.
chmod +x macht das Script ausführbar.
Nach dem Neustart wird automatisch die Regel/n geladen.
Ggf. übertrage ich das hier noch ins Wiki, da es dort übersichtlicher ist.
