Teamspeak 2 Serverproblem

[H0MER]

Moin Moin Forum.

Ich habe folgendes Problem:

Ich habe nach dieser Anleitung http://www.tutorials.de/forum/webserver ... erver.html
einen Teamspeak 2 Server auf meinem Debian Sarge System installiert.

Der Server an sich läuft auch und ist über das normal Lan verfügbar.
Leider kann niemand von ausserhalb connecten.
Die Fehlermeldung, die die externen Clients bekommen sagt, dass sie sich nicht verbinden konnten oder kein Server auf dem System läuft.

Ich habe für den Teamspeak Server folgende Regel in meiner IPTables eingerichtet:

Code: Alles auswählen

$IPTABLES -t filter -A INPUT -i $EXTDEV -p udp --dport 8767 -j ACCEPT

Ich habe in diesem Forum diesen :
http://www.debianforum.de/forum/viewtop ... =teamspeak
Thread gefunden, jedoch bin ich mir nicht so sicher, was ich dort als ip eintragen muss.
Meine WAN ip, meine IP des Interfaces, welches am DSL-Modem hängt oder kann ich auch nen dyndns Eintrag nehmen?

Vielen Danke schon mal im Voraus

mfg
H0MER

[nepos]

Und hast du auch eine Regel in der OUTPUT-Chain, die die Antwortpakete durchlaesst?

[H0MER]

Hi ...
ich habe mir eben mal meine Firewallkonfig angeguckt (ist die die auch hier im Wiki zu finden ist, mit kleinen Änderungen) und habe keine explizite output regel finden können ( bin auch eher Anfänger auf dem IPTables Gebiet).
FTP und HTTP klappt aber auch ohne, dass ich eine Regel einstellen musste.
Das verrückte ist, dass ich auf meinem Windows Rechner hinter dem Router auch testweise nen Teamspeak Server aufgesetzt hatte.
Für den Server hatte ich dann eine Forwarding Rule gemacht und da klappte das dann ohne Probleme.
Ich bin da leider mit meinem Latein ein bisschen am Ende.

Hier mal meine komplette Firewall konfig :
http://nopaste.debianforum.de/4400

mfg
H0MER

[nepos]

Hm ok, da du als Default-Policy fuer OUTPUT ein ACCEPT drin hast, brauchts da keine extra Regel fuer.
Im Moment sehe ich leider nicht, wo das Problem liegen koennte. Du machst das eigentlich schon korrekt, auch mit statefull, was vieles vereinfacht. Siehst du in den Logs vom Teamspeak Server eventuell was, das dir weiterhelfen koennte?
Passt das mit dem Port?
Laut deiner HowTo sollte es reichen, wenn du ankommende UDP-Pakete auf Port 8767 zulaesst. Die entsprechende Regel hast du eigentlich schon in deinem Skript, wenn auch auskommentiert.

[DynaBlaster]

Passt das mit dem Port?
Laut deiner HowTo sollte es reichen, wenn du ankommende UDP-Pakete auf Port 8767 zulaesst. Die entsprechende Regel hast du eigentlich schon in deinem Skript, wenn auch auskommentiert.

Die Default-Policy der INPUT-Chain ist doch ebenfalls auf ACCEPT, das Script verbietet nur später explizit einige Ports - IMHO wäre der Weg andersherum eigentlich sinnvoller - erst alles verbieten und dann entsprechende Löcher bohren, aber nun denn: so wie das Script arbeitet, ist UDP 8767 eh erreichbar - sofern der Dienst dort richtig läuft.

Code: Alles auswählen

$IPTABLES -t filter -P INPUT ACCEPT
$IPTABLES -t filter -P OUTPUT ACCEPT
$IPTABLES -t filter -P FORWARD ACCEPT
...
$IPTABLES -t filter -A INPUT -i $EXTDEV -p tcp -s 0/0 -d 0/0 --dport 1:1024 --syn -j REJECT

In dem von dir gepostetetn Thread wurde das Problem gelöst, indem der TS-Server die richtige IP zugewiesen bekommen hat: evtl. lauscht der TS-Server am falschen Interface (also nur an eth0) bzw. bezieht seine IP nicht vom ppp0-Device.

Was sagt:

Code: Alles auswählen

netstat -tulpen

[H0MER]

Hi ...
an sich hatte ich die Zeile, wo ich den udp Port 8767 zulasse, nicht auskommentiert.
Da ich es bis jetzt nicht hinbekommen habe den Server zum laufen zu bekommen, habe ich das wieder auskommentiert.

Die Ausgabe von

Code: Alles auswählen

netstat -tulpen

ist hier :
http://nopaste.debianforum.de/4401

Ich hatte mal testweise diese IP Einstellung gemacht.
Jedoch hatte ich die interne IP vom dem Interface verwendet, welches am Modem hängt.
Das hat aber das Problem leider nicht gelöst.
Ich konnte danach nicht mal mehr über mein Lan auf den Server zugreifen.
Habe das aber noch nicht mit meiner WAN adresse versucht, was ich auch irgendwie komisch finden würde, da ich dann ja bei jedem 24h disconnect diese config ändern müsste.

@DynaBlaster:
Sollte ich denn lieber

Code: Alles auswählen

$IPTABLES -t filter -P INPUT REJECT
$IPTABLES -t filter -P OUTPUT ACCEPT
$IPTABLES -t filter -P FORWARD ACCEPT 

machen?

[DynaBlaster]

Code: Alles auswählen

$IPTABLES -t filter -P INPUT REJECT

Diese Option für das Setzen der Default-Policy gibt es nicht. Sie müsste so lauten und bewirkt, dass alles, was später nicht explizit erlaubt wird, kommentarlos verworfen wird. REJECT antwortet ja mit einem "DESTINATION IS UNREACHABLE" - bei DROP gibt es überhaupt keine Antwort.

Wie gesagt, REJECT als Default-Policy geht nicht, also:

Code: Alles auswählen

iptables -t filter -P INPUT DROP

Habe das aber noch nicht mit meiner WAN adresse versucht, was ich auch irgendwie komisch finden würde, da ich dann ja bei jedem 24h disconnect diese config ändern müsste.

Ja, aber genauso habe ich den beschriebenen Bug aus dem geposteteten Thread verstanden. Die Ausgabe von "netstat -tulpen" ist jedenfalls in Ordnung: danach lauscht der TS-Server (die "server_linux" Einträge) auf allen Interfaces und es dürfte eigentlich kein Problem vorhanden sein.

Probier es mal mit der WAN-Adresse, wenn das Problem dadurch gelöst wird, würde ich dir empfehlen, den TS-Server irgendwie über die ip-up und ip-down-Scripte automatisch bei der 24h-Trennung runterzufahren und anschließend neu zu starten. Für die Clients von außerhalb ist ein Reconnect aufgrund der sich ändernden WAN-IP ja eh notwendig - Der einzige Nachteil ist halt, daß die LAN-Clients aufgrund des Neustarts die Verbindung ebenfalls verlieren und neu connecten müssen.

[H0MER]

Halli Hallo.

Das Problem ist "gelöst".
Ich habe nur keine Ahnung warum .

Ich habe gestern versucht erst mal mein Firewallscript so abzuändern, dass es Standardmässig nicht mehr alle ankommenden Pakete akzeptiert.

Nach langem hin und her bin ich zu diesem Ergebnis gekommen:

http://nopaste.debianforum.de/4407

Wäre nett, wenn jemand das Kommentieren könnte, da ich mir bei dieser Zeile nicht sicher bin:

Code: Alles auswählen

$IPTABLES -t filter -A INPUT -i eth1 -s 0/0 -d 0/0 -j ACCEPT

Das Problem war, dass ich nachdem ich die Policy auf Drop geändert hatte, nicht mehr übers Lan zugreifen konnte und habe mir dann diese Regel hinzugefügt.
Es funzt auch, jedoch würde ich gerne wissen, ob es evtl. eine "offizielle Verfahrensweise" für die Lösung des Problems gibt.

Ok .. zurück zum ursprünglichen Problem.
Nachdem ich lange hin und hergefrickelt hatte, musste ich den Rechner mal neustarten.
Es tat mir in der Seele weh .
Ich habe dann mal testweise, bei der Serverkonfiguration für den Port meine Wan IP eingetragen und eine Verbindung war sofort möglich.
Ich kann jedoch nicht sagen, ob das jetzt am Neustart lag oder an der Serverkonfiguration, denn danach habe ich diesen Eintrag aus der Server.ini wieder gelöscht.
Und eine externe Verbindung zum Server war immer noch Möglich.
Ich habe leider nicht getestet, ob eine Verbindung direkt nach dem Neustart möglcih gewesen wäre.

Wie gesagt.
Ich habe einiges gemacht, jedoch nix, von dem ich jetzt sagen könnte, das es mein Problem gelöst hat.
Aber es ist gelöst.

Vielen Dank an dieser Stelle noch mal an alle, die mir geholfen haben das Problem zu lösen.

mfg
H0MER

[DynaBlaster]

Code: Alles auswählen

$IPTABLES -t filter -A INPUT -i eth1 -s 0/0 -d 0/0 -j ACCEPT

Diese Zeile akzeptiert einfach jedes Paket, das an eth1 ankommt, und für den Router bestimmt ist.

Das ist in Ordnung so, dem systematischen Aufbau deines Scripts folgend, würde die Zeile allerdings so aussehen:

Code: Alles auswählen

$IPTABLES -t filter -A INPUT -i $INTDEV -s $INTLAN -j ACCEPT

[H0MER]

Super

Vielen vielen Dank nochmal.

mfg
H0MER

ps. Hast du evtl nen gutes Tutorial, wo die Grundlagen zu IP-Tables beschrieben werden?
Habe alles gefunden. Nur nicht das Richtige .

[DynaBlaster]

Leider nicht, ich habe alles nach dem Trial & Error-Verfahren gemacht. Deshalb bin ich ja auch ein Verechter von "erst einmal alles verbieten, und danach einzelne Dienste explizit erlauben". Übrigens nicht nur für die INPUT-CHAIN, das geht in der FORWARD- und OUTPUT-CHAIN genauso, wird dann aber meist etwas unübersichtlich.

Als Grundlage habe ich eigentlich nur diesen Thread hier (http://www.debianforum.de/forum/viewtopic.php?t=3419) benutzt, bei tiefergehenden Problemen dann die Manpage von iptables und http://www.netfilter.org.

Ach ja, der ganze Kram mit den $Variablen im Skript hat nicht explizit was mit mit iptables zu tun, diese Dinge lernst du besser in Tutorials zu Shell-Scripting kennen. Ein iptables-Script ist halt auch nur ein Shellscript, welches bestimmte Kommandos nacheinander ausführt. Und damit man sich etwas Schreibarbeit spart, kann man halt Variablen definieren und dann später im Script weiterverwenden - praktischerweise kann man das gleiche Script dann durch die Änderungen dieser "Platzhalter" an gänzlich andere Netzstrukturen anpassen, ohne das ganze Script von oben bis unten durchzugehen, was bei grossen Scripten ziemlich fehlerangällig sein kann.