Beiträge von Sebbo

    Hi,
    ein paar weitere Infos wären noch von Vorteil, um die Komplexität des Setups herauszufinden. ;)

    • Postfächer für eine oder auch mehrere Domains?
    • Werden Aliase benötigt?
    • Wünsche für die Software? Also willst du unbedingt eine bestimmte Software hierfür verwenden, weil du die aufgrund von anderen Software irgendwie z.B. benötigst?
    • Mit oder ohne SSL?
    • Was soll das Mail-Interface können? E-Mail Client oder eher eine Administrationsoberfläche?
    • Willst oder brauchst du eine Anti-Viren Lösung? (Wäre von Vorteil, wenn dir Spammer Fake-Dateien mit Viren senden. ;))
    • Willst oder brauchst du eine Anti-Spam Lösung?

    Wenn die Infos gegeben sind, kann man dir besser helfen. :)

    Nur als Info am Rande: Die DDoS-Protections lassen nur die Standard-Ports für TS3 durch. Dies sind alle zwischen 9000 und 9999 - UDP natürlich. Alle anderen werden nicht geprüft.


    Bzgl. Cloudflare selbst:

    Zitat von https://www.facebook.com/CloudFlare/posts/10152208305195432

    We can't protect traffic on anything that isn't web traffic going over ports 80 and 443.

    Verstehe. Angenommen beim Bootvorgang bist du aktuell im Verzeichnis "/root", dann wird auch dort die ts3server.pid angelegt. Prüfst du dann mit dem User den Status ab, findet er die Datei natürlich nicht, weil das Skript im lokalen Verzeichnis (".") nachschaut.


    Versuch mal das in der Datei:

    Code
    su - ts -c "./ts3server_startscript.sh start"


    Das sollte das Problem mit dem "Server seems to have died" lösen. Was man ggfs. noch beachten muss, ist der Stop-Befehl des Servers. Wenn du den Server herunterfährst, wird der TS3 nicht gestoppt, sondern gekillt. Das sorgt dafür, dass die ts3server.pid noch da ist, was aber nicht so sein sollte. Daher würde ich vorher noch sicherstellen, dass die auch weg ist.

    es gab einen Virtuellen Server welcher einen dreistelligen Port hatte (666)


    Das ist aber kein Standard-Port... :D


    Nur als grundlegende Info bzgl. Ports: Es gibt zwei, also eigentlich sogar drei Bereiche bei Ports, die man wissen sollte:

    • 0 bis 1023 (Well-Known Ports)
    • 1024 bis 49151 (Registered Ports)
    • 49152 bis 65535 (Dynamic Ports)

    Aus dem Bereich der Well-Known Ports sollte man nie einen Port verwenden, da sie standardisiert und für bestimmte Dienste reserviert sind. Manche Software und Betriebssysteme sind nicht mal in der Lage, einen dieser Ports zu verwenden, weil die Software entweder so programmiert ist, derartiges zu vermeiden oder weil man System-Rechte hierfür benötigt.


    Wenn man Ports braucht, sollte man diese aus den registered und/oder dynamic Ports nehmen. Eigentlich ist dafür nur der Registered Bereich vorgesehen, da der Dynamic für die Clients gedacht ist. Man kann für Server Dienste aber auch die Ports aus dem Dynamic Bereich verwenden. Hier gab und gibt es seit der damaligen Umstellung der Port-Bereiche immer noch Unklarheiten. Einige Router nutzen wohl auch noch Ports aus dem Registered Bereich für die Clients, da sie die höheren nicht unterstützen.


    Weitere Infos gibt's auf Wikipedia: https://de.wikipedia.org/wiki/…otokoll)#Standardisierung :)

    Das hat nur was mit DNS zu tun. Da ihr euch über eine IP verbindet bringt das nichts.


    Ich weis ja nicht, aber eine IP besteht bei mir aus Zahlen und nicht aus Buchstaben. Ich habe bisher nur Domains bei Verbindungsversuchen gelesen:

    Log Eintrag eines Benutzers:" Connect to server: join-fps.de
    Trying to resolve join-fps.de


    ...und hier nochmal: Connection Probleme


    Also erstmal kommt nicht mal der Ping an (nicht mal 1 Packet). Dann kann zwangsläufig der tracert nicht funktionieren (bitte berichtigen wenn ich falsch liege).


    Das ist falsch. Das eine kann trotz des anderen dennoch funktionieren.


    Der tracert ist deswegen falsch weil
    1. Zu viele Zeitüberschreitungen zu erkennen sind (ein paar sind "normal" aber so viele nicht)


    Ein Tracert kann nie "falsch" sein. Er macht genau das, was die Routen sagen. Ein Tracert kann auch 10 von 10 Zeitüberschreitungen z.B. haben und dennoch wäre er korrekt.


    Jede aufgeführte Zeile zeigt das Feedback eines Routers. Jeder Router steht für einen sogenannten "Hop" und wenn einer dieser Hops eben so konfiguriert ist, dass er keine Auskunft geben soll, dann macht er das auch nicht. Dennoch ist der Tracert dann aber korrekt. Im Normalfall ist aber mindestens der hauseigene Router, sowie der (eigene) Ziel-Server so eingerichtet, dass er entsprechend antwortet, da das Debuggen sonst u.U. sehr schwer werden kann.


    In diesem Fall hier, stimmt aber tatsächlich was nicht, da andere Clients (ich z.B.) eine komplette Routenverfolgung hinkriegen:

    Diese Messung wurde ~5 Minuten lang durchgeführt.


    Der tracert ist deswegen falsch weil
    2. kein Ziel angezeigt wird. Wenn kein Ziel angezeigt wird, wo hat der tracert dann geendet? Richtig, am letzten angezeigten Punkt. Aber wenn danach noch eine Zeitüberschreitung kommt war es wohl nicht das Ziel?!


    Huh? Nur, weil der Router keine Antwort liefert, heißt das doch nicht, dass er nicht existiert.


    Wie am Anfang des Befehls auch zu lesen ist, endet ein Tracert standardmäßig nach 30 Hops. Daher ist der 30. Hop auch der letzte in der Statistik gewesen. Ein Tracert macht vom Prinzip nichts anderes, wie ein Verbindungsaufbau von einem TS3 Client zum Server. Es sucht sich anhand von verschiedenen Protokollen und vordefinierten Routen den Weg zum Ziel-Server.


    Jeder kann seine Firewall so konfigurieren, dass sie genau diese Antwort zurück liefert. Dennoch wäre der Server aber erreichbar und da.


    In dem Screenshot von @NothingTV sieht man, dass er die Domain prinzipiell schon mal richtig auflöst: join-fps.de [51.254.244.184]


    Das zeigt uns, dass die Domain zur richtigen IP aufgelöst wird. Somit können wir ein DNS Problem ausschließen.


    Da andere Personen ohne Probleme auf den TS3 Server kommen, liegt auch kein allgemeiner Fehler am Server vor, weshalb es nur ein Firewall oder Routing Problem sein kann.


    Routing Problem? Aber gerade wurde doch noch gesagt, dass andere ohne Probleme drauf kommen? Ja, das ist korrekt. Allerdings hat nicht jeder Client die selben Routen. Das hängt vom Standort, dem Internet Provider und dessen statischen Routen, sowie der Auslastung und Verfügbarkeit einzelner Routen ab. Je nachdem, ob eine Route nämlich zu ausgelastet ist, werden andere Pakete wieder über eine andere Route versendet.


    Vermutlich würde ein Tracert mit noch mehr Hops keinen neuen Host anzeigen, weshalb ich vermute, dass entweder OVH oder der Client selbst ein kleines Problem hat. Der letzte bekannte und erreichbare Host gehört OVH, weshalb sich der Rest höchst wahrscheinlich nur noch im OVH Netz bewegen wird. Ich würde daher den OVH Support fragen, warum der Client mit der IP Adresse XYZ nicht weiter als bis zum Host be10-407.rbx-g1-a9.fr.eu (188.165.9.79) kommt, während andere Clients jedoch ohne Probleme zum Ziel-Server mit der IP ABC kommen. Vorher würde ich allerdings noch testen, ob es am PC/Notebook liegt und es nochmal von einem anderen Gerät aus versuchen. ;)


    Ob es sich um ein Routing Problem handelt, kann man hier etwas schwer prüfen, weil man noch jemanden benötigen würde, der über den selben zuletzt bekannten OVH Host geroutet wird. Wenn diese Person dann ohne Probleme auf den TS3 Server kommen sollte, dann kann man ein Routing Problem ausschließen.


    Da mein vorletzter Host der mit der IP 188.165.9.70 (be50-5.sbg-4a-a9.fr.eu) ist, vermute ich, dass entweder genau dieser eine Router aktuell Probleme hat oder die Client IP entweder an diesem Router oder am Ziel-Server selbst geblockt wird.


    Wurde bereits geprüft, ob die IP Adresse vom Client auf dem TS3 Server oder dem Linux/Windows Server gebannt ist? fail2ban könnte z.B. eine IP gebannt haben.

    @Pagian: Das ist logisch, allerdings war mir bis zu seinem Feedback danach nicht klar, wie sich wer verbindet.


    @Inception: Danke für die Log Datei. Ich kann ihr allerdings keinen Grund entnehmen, warum sich der Client disconnected.


    Ist der Client ggfs. gebannt? Via Firewall vom Server oder per Bann-Regel von TS3?

    Mhmm, ok.


    Ich komme ohne Probleme drauf. Kannst du uns bitte die Log-Datei des Clients zeigen, damit wir mal schauen können, ob hier irgendwas schief geht? Die aktuellste findet man im %appdata%\TS3Client\logs Verzeichnis.

    Hallo,
    nachfolgend kurz erklärt, wie du was sichern kannst. :)


    Identität exportieren

    • TS3 Client starten/öffnen
    • Einstellungen
    • Identitäten
    • Identität auswählen und Exportieren anklicken
    • Ggfs. Warnung mit "Ja" wegklicken
      Diese besagt nur, dass wir die Datei dann sicher aufbewahren sollten, da sonst andere mit unserer Identität ggfs. Rechte auf diversen Servern haben.
    • Speicherort und Dateiname wählen und auf "Speichern" klicken


    Der Import funktioniert über den selben Weg, nur dass man anstatt "Exportieren" eben "Importieren" anklickt. ;)


    Favoriten exportieren
    Achtung: Ältere Clients hatten ihre Favoriten in der Datei "bookmarks.ini" gespeichert.

    • Öffne das Fenster "Ausführen" (Tastenkombination Windows-Taste + R) oder die Suche aus dem Startmenü
    • Gib folgenden Code ein und bestätige ihn mit Enter, um den Ordner zu öffnen:

      Code
      %appdata%\TS3Client


    • Kopiere die Datei "settings.db" zu deinen Backups


    Hinweis: Solltest du zwischenzeitlich bereits neue Favoriten angelegt haben, empfehle ich dir, diese vorher manuell rauszuschreiben, um sie später in die Version des Backups wieder reinspeichern zu können, ansonsten wirst du diese beim Import verlieren.


    Importieren tust du diese, indem du auf dem Zielsystem den TS3 Client geschlossen hälst, die Datei wieder in das selbe Verzeichnis einfügst und vorhandene ggfs. überschreibst.


    Backup aller Einstellungen

    • Öffne das Fenster "Ausführen" (Tastenkombination Windows-Taste + R) oder die Suche aus dem Startmenü
    • Gib folgenden Code ein und bestätige ihn mit Enter, um den Ordner zu öffnen:

      Code
      %appdata%\TS3Client


    • Kopiere folgende Ordner und Dateien zu deinen Backups:

      • settings.db
      • ts3clientui_qt.secrets.conf
      • chats/ (optional; Enthält die Chat-Verläufe)
      • logs/ (optional; Enthält die Client-Logs)

    Auf dem Ziel-System installiert man nun den TS3 Client und importiert die obigen Dateien/Verzeichnisse wieder, während der TS3 Client geschlossen ist. Falls davon bereits was vorhanden ist, lösche oder überschreibe es mit den Daten vom Backup.

    Hallo,
    einige unserer Kunden hatten auch das Problem, nachdem wir umgezogen sind.


    Die betroffene(n) Person(en) soll(en) doch bitte mal folgende Schritte durchführen:

    • TeamSpeak 3 Client schließen
    • Eingabeaufforderung als Administrator öffnen
    • Befehl eingeben und Enter drücken:

      Code
      ipconfig /flushdns
    • TeamSpeak 3 Client starten und versuchen, auf den Server zu verbinden

    Hallo liebe Community,


    ich habe gerade eine recht interessante Competition gefunden, die die ein oder anderen hier vielleicht auch reizen könnte. :)


    IT-Talents sucht aktuell nach einer eigen programmierten Verschlüsselungslösung und vergibt hierfür entsprechende Preise, wenn's gut genug ist.


    Die Aufgabe besteht darin, eine Lösung zu entwickeln, welche ausgewählte Dateien und vielleicht sogar auch Verzeichnisse sicher und gut verschlüsselt und auch wieder entschlüsseln kann.

    Zitat von IT-Talents

    Ein passender Use Case wäre hier z.B., dass ein Nutzer seine persönlichen Daten auf einem Cloudspeicher sichern möchte, aber die Möglichkeit ausschließen will, dass der Cloudbetreiber die Daten lesen kann.


    Anforderungen, Code-Einreichung, Preise und weitere Infos findest du hier: https://www.it-talents.de/cms/…/code-competition-04-2016


    Happy coding! :)


    PS: Weder ich persönlich, noch TScon steht in Verbindung mit diesem Gewinnspiel. Habe es wie gesagt selbst nur zufällig gesehen.

    Hallo Ben und willkommen zurück,

    Wir haben sehr viele schöne neue Features, die ich ihnen hier präsentieren werde.


    Die Große Hosterliste ist wieder da, es wird reichlich auf die Unterstützung namenhafter Hoster gezählt.


    Eines dieser Feature ist wohl das, dass sämtliche Beiträge gelöscht wurden... Einige gaben sich viel Mühe, Ihre Threads und Antworten zu erstellen und das ist jetzt scheinbar alles weg... ;(


    Neue Features kann man implementieren, ohne die Daten zu schrotten und für den Notfall gibt es ein sogenanntes Backup... Für mich persönlich bedeutet das, dass ich nichts mehr schreiben werde, denn wer weis, wie lange es diesmal erhalten bleibt? Die Zeit verwende ich lieber für was anderes, anstatt's sie zu verschwenden...


    Die Webseite ist durch Transport Layer Security kurz SSL geschützt.


    Irgendwie stimmt das nicht... Transport Layer Security wird bei mir zu TLS und nicht SSL. SSL steht für Secure Sockets Layer. ;)


    So oder so: Es bringt aber nichts, eine SSL gesicherte Webseite zu haben, wenn diese mangelhaft eingerichtet ist und somit durch alle möglichen Sicherheitslücken gehackt werden kann. Nachfolgend eine kleine Liste mit den Sicherheitslücken, die deine Webseite aktuell vorweist:

    • SSL Zertifikats-Chain ist unvollständig
    • POODLE (SSLv3)
    • Forward Secrecy
    • Logjam Attack


    Somit kommen wir auch zum nächsten Punkt:

    Wir schreiben Datenschutz groß, [...]


    Aufgrund der vorher genannten SSL Geschichte kann man alle Logins, Aktionen (Klicks) und sonst was einfach mitschneiden. Da kriegt man ganz einfach und schnell die E-Mail Adressen von den Benutzern, was datenschutzrechtlich ein No-Go ist.


    Fazit: Ihr solltet wohl die ein oder anderen Themen nochmal anpacken und überarbeiten, sonst werden die User bald alle wegrennen und nie wieder kommen.


    Happy tweaking! ;)