Beiträge von master_d

Wenn du über die externe IP die Verbindung aufrufst, dann muss diese auch in der Whitelist auftauchen.

Und was die Befehle angeht, so meine ich damit die vom Webinterface an den Teamspeak3-Server gesendeten Befehle auf dem Query-Port.

Klingt nach einem Problem mit dem Query-Interface.

Ist das "zugreifende System", also das wo das Webinterface drauf läuft, bei dem TS3-Server in der Query-Whitelist eingetragen?

Aufgrund der Beschreibung gehe ich stark von einem Problem mit der "SPAM-Protection" im Query-System aus. Einfach zu viele Befehle gesendet, ohne die entsprechende Konfiguration.

Teamspeak ist seit 3.1 auch für IPv6 verwendbar.
Die IPv6-Adresse ist auch von außen erreichbar, und muss nur in deinem Router freigegeben werden.
Danach sollte auch von außen ein Zugriff auf deinen TS-Server möglich sein.

Schau also einfach mal auf dem Rechner mit dem TS-Server nach der IPv6-Adresse, und gibt die Ports 30033/tcp und 9987/udp für den Rechner/die IPv6-Adresse in deinem Router frei.
Danach sollten Leute von außen auf der Adresse eine Verbindung zu deinem TS-Server aufbauen können.

Und genau das, was ich erwartet habe, ist eingetreten.

Du hast einen Kabelanschluss, welcher zumeist über DS-Lite angesteuert wird.
Daher hast du wahrscheinlich an deinem Anschluss keine "eigene" IPv4-Adresse mehr. Dir bleibt nur eine Nutzung der IPv6-Adresse, sollte sich dies wirklich so darstellen.
Prüfe bitte einmal die Info-Seite deiner FritzBox, da sollten alle Informationen angezeigt werden (IPv4, falls vorhanden, IPv6-Adressen, etc).

Bei den normalen "Internet-Anschlüssen" handelt es sich immer um "Dial-Up-Verbindungen" (Telekom sei dank, die wollten damals auch bei DSL weiter nach Zeit abrechnen ). Daher ändert sich die IP (IPv4 und IPv6) mit jedem Verbindungsaubau.

Um dein Problem genauer auffassen zu können, wäre ein wenig mehr Information erforderlich.
- Welche Art von Internet-Anschluss ist hier das Problem (DSL/Kabel/etc.)?
- Welcher Router ist hier im Einsatz?

Danach kann man sich über das Problem genauer unterhalten, aber eine mögliche Lösung des Problems wäre hier "DynDNS", um der sich verändernden Adresse einen eigenen Namen zu verpassen.

Die Frage ist, von welcher Sichtweise man das ganze betrachtet.

Aber ja, die "Menge an Dokumentation" in diesem Bereich ist bestenfalls gerade ausreichend, eher mangelhaft.
Auch ich habe mich durch die vorhandene Dokumentation gewühlt, und verstehe noch immer nicht alles, daher wäre potentiell ein Tutorial eine sinnvolle Ergänzung.

Nur bei der "Fülle an Möglichkeiten" stellt sich die Frage, ob es bei einem Tutorial bleiben sollte. Ich denke eher, hier sollte einmal eher in die Richtung einer "ordentlichen Dokumentation" gedacht werden, welche das Gesamtspektrum abdeckt. Das sollte durchaus durch Beispiele, auch in Form eines Tutorials, unterstützt werden.

Am Rande könnte man sogar die Möglichkeiten zur Nutzung anderer Sprachen mit bedenken. Bspw. werden meine Plugins eher in C++/Qt verfasst, da dies bereits durch Teamspeak verwendet wird.

Es kommt immer darauf an, was du absichern möchtest.
Fail2Ban kann viele Dienste absichern, und daher ist es mit einer einfachen "Installation" eher nicht getan.

Aber allgemein gesagt, sind folgende Schritte notwendig.

1. installiere das Paket "fail2ban" über die Paketverwaltung deiner Distribution

2. erstelle die Datei "/etc/fail2ban/jail.local", um darin die Standardwerte aus der Datei "/etc/fail2ban/jail.conf" zu überschreiben. (DIes gilt analog für die anderen *.conf-Dateien, da diese vom Paketmanagement ausgetauscht/ergänzt werden können)

3. Prüfe, ob die notwendigen Einstellungen auch entsprechend gewirkt haben ("fail2ban status" gibt hier entsprechende Informationen über derzeit aktive Einstellungen, ansonsten einfach die Manpage zum Kommando "fail2ban" lesen).

Die einfachste Variante wäre hier einfach 2 DNS-Einträge anzulegen, da das TSDNS nicht wirklich weiter verwendet werden soll, bzw. zukünftig aus den Clients entfernt werden soll.

Lege also daher folgende DNS-Einträge an.

Einen "A-Record" mit bspw. "ts3.<domainname>".
Einen "SRV-Record" mit "_ts3._udp.<domainname>", "<Port>" "<A-Record>".

Nachfolgend Beispieleinträge:

voice01.<domainname>. 3600 IN A    <ip>
_ts3._udp.<domainname>. 3600 IN SRV 0 5 9987 voice01.<domainname>.

Mit dieser Konfiguration kann man einfach mit "<domainname>" zum Server verbinden, ohne dass man Port oder FQDN selbst kennen muss.

Das kann viele Ursachen haben.

Eine davon wäre, dass du einen falschen Benutzer verwendest.

Bitte einmal die vollständige Fehlermeldung posten, dann kann man dir besser helfen.

Das klingt für mich, als ob deine Datenbankdatei für den verwendeten Benutzer nicht "beschreibbar" ist.

Es wäre daher gut zu wissen, unter welchem Benutzer der Teamspeak-Server gestartet wird, und welche Berechtigungen die Dateien im entsprechenden Ordner derzeit haben.
Danach sollte es kein Problem sein, das deinige zu lösen.

NEIN!

Es können mit dieser Einstellung maximal 2 "offene" Verbindungsanfragen existieren, weitere werden ignoriert/verworfen.
pending - LEO: Übersetzung im Englisch ⇔ Deutsch Wörterbuch

Es werden also maximal 2 Verbindungen erlaubt, die nicht den Status "Connected" haben, sondern noch in einem vorherigen Status stecken/verblieben sind. Auf die Anzahl der "erfolgreichen" Verbindungen hat diese Einstellung keinen Einfluss.

PHP-Code, kein Problem

<?php
$handle = fsockopen("<server-ip>", 10011);
fwrite($handle, "serveredit virtualserver_hostmessage=TeamSpeak\s]\p[\sServer");
fclose($handle);
?>

OK. Trollmode deaktivieren
Du hast doch alles bereits gepostet. Unter dem von dir geposteten Link unter den Beispielen Abschnitt 4 steht alles, was du brauchst. Nur der genaue Parameter nennt sich halt etwas anders. Dies kann aber einfach per Printout geprüft werden, wie der sich nennt.
Funktionen dafür sind "var_dump" oder "print_r", welche dir die Variable in ihrer Struktur ausgeben.

Ansonsten sollte das wohl kein Problem darstellen-

Auch wenn man etwas in einem Screen startet, läuft es nur bis zu seinem eigenen Ende. Wenn also das "Script" aus irgendeinem Grund sich beendet, dann ist es auch in einem Screen aus.
Ein Screen dient nur der Tatsache, dass sich das Script ansonsten beenden würde, wenn die Terminal-Session geschlossen wird.

Ansonsten kann ich nur beipflichten, für Probleme solcher Art eine compiler-basierte Programmiersprache zu verwenden.

phpenmod curl

Potentiell nicht aktiviert ?

Notfalls mal per "phpinfo()", bzw. "php -i" nachschauen, ob es aktiviert ist, bzw. ob ein Symlink im Konfigurationsverzeichnis existiert.

Ich kann so keine Probleme in den Logs erkennen, daher gehe ich von einem "externen" Problem aus.

Daher stellt sich die Frage, ob irgend eine Art von Firewall eingerichtet ist, die den Zugriff auf die genannten Ports ggf. nicht gestattet.
Prüfe doch bitte einmal, ob das System über vordefinierte FW-Regeln verfügt.

iptables -L -nv
ip6tables -L -nv

FYI:
Wenn mich meine "laiensicht" nicht täuscht, muss im Impressum eine "ladungsfähige Anschrift" angegeben sein. Der Passus "auf Anfrage" ist nicht rechtskonform, und könnte zu Problemen führen.

Sorry, hatte ich irgendwie ganz verbaselt.

Gerade nochmals genauer auf deinen Screenshot geguckt. Es sieht so aus, als ob zwar das VisualStudio installiert wäre, aber keine Standardlibs vom Compiler. Zu erkennen an den rot unterschlängelten Include-Anweisungen. Also solltest du einmal prüfen, ob die Include-Pfade richtig gesetzt sind.
Wo genau die zu finden sind, kann ich dir allerdings nicht sagen. Meine Windows-Versionen erstelle ich auf Komanndozeile, da ich Qt-Creator verwende, und das zumeist unter Linux, wenn nicht ein "Windows-Problem" zu debuggen ist.

Dies wäre aber auch für dich eine Möglichkeit. Statt dem VisualStudio Qt-Creator zu verwenden, dann könntest du die Libs verwenden, die Teamspeak selbst mitbringt, um auch weiterführende Funktionen nutzen zu können.

Wie ist die Userverteilung?
Wie viele User sind dabei im gleichen Channel?
Paketverlust vom Server zu bestimmten Clients oder zu allen?

Die Daten müssen ja immer an alle User in dem Channel übertragen werden.

Es existieren von mehreren Personen in meinem Umfeld Beobachtungen, dass die genannte Box Probleme bereitet, wenn "mehrere Geräte" über diese Box auf das Internet zugreifen.
Es ist daher möglich, dass diese Box dein genanntes Problem auslöst.

Meine Empfehlung wäre hier auf einen "eigenen" Router umzusteigen, und eine entsprechende Fritz!Box-Cable zu kaufen, und entsprechend anzuschließen. Dies sollte das Problem beheben, wenn es mit der ConnectBox zu tun hat.

Die "GeoIP"-Daten müssen nicht immer 100%ig korrekt sein. Das Problem ist wahrscheinlich ein IP-Bereich, der vor kurzem den Standort gewechselt hat, womit die Datenbank potentiell veraltet ist, oder aber "doppelte Einträge" hat.

Der Information sollte man also keine 100%ige Wahrheit zusprechen.