16
Routing Problem Client zu Server
Hallo,
ich betreibe einen kleinen Teamspeak 3 Server (schon seit Jahren). Der Server läuft stabil auf einer eigenen Windows VM auf einem ESXI Server bei mir zu Hause.
Soweit so gut. Vor ziemlich genau einer Woche haben sich 2 Clients bei mir zeitgleich unabhängig voneinander gemeldet, dass Sie keine Verbindung mehr zum Server herstellen können.
Der Server lief aber ganz normal weiter, in den Server logs nichts auffälliges und alle anderen Clients hatten keine Probleme.
Also ging ich auf die Suche. Die beiden Clients sind beim selben Provider mit der gleichen Anbindung (also Technisch). Die Clients hatten ansonsten keine Internetprobleme. Trotzdem habe ich empfohlen alles mal neu zu starten und die IP-Konfigs angeschaut, alles normal.
Einer der Clients hat einen traceroute gestartet und siehe da, gleich nach dem Router als es weiter ging zum ersten Server des Providers "Zielhost nicht erreichbar".
Wenn ich den traceroute starte (natürlich von extern) findet sich eine Route zum Server. Logisch, alle anderen Clients funktionieren ja auch.
Kann mir jemand bei der weiteren Diagnose helfen? Irgendwie komme ich nicht mehr weiter. Aktualisiert sich die Routing table des Providers wieder mal?
Bevor jemand mit Workarounds kommt: Es muss ganz einfach auch so gehen. Ein VPN ist für diese Clients keine Option.
ich betreibe einen kleinen Teamspeak 3 Server (schon seit Jahren). Der Server läuft stabil auf einer eigenen Windows VM auf einem ESXI Server bei mir zu Hause.
Soweit so gut. Vor ziemlich genau einer Woche haben sich 2 Clients bei mir zeitgleich unabhängig voneinander gemeldet, dass Sie keine Verbindung mehr zum Server herstellen können.
Der Server lief aber ganz normal weiter, in den Server logs nichts auffälliges und alle anderen Clients hatten keine Probleme.
Also ging ich auf die Suche. Die beiden Clients sind beim selben Provider mit der gleichen Anbindung (also Technisch). Die Clients hatten ansonsten keine Internetprobleme. Trotzdem habe ich empfohlen alles mal neu zu starten und die IP-Konfigs angeschaut, alles normal.
Einer der Clients hat einen traceroute gestartet und siehe da, gleich nach dem Router als es weiter ging zum ersten Server des Providers "Zielhost nicht erreichbar".
Wenn ich den traceroute starte (natürlich von extern) findet sich eine Route zum Server. Logisch, alle anderen Clients funktionieren ja auch.
Kann mir jemand bei der weiteren Diagnose helfen? Irgendwie komme ich nicht mehr weiter. Aktualisiert sich die Routing table des Providers wieder mal?
Bevor jemand mit Workarounds kommt: Es muss ganz einfach auch so gehen. Ein VPN ist für diese Clients keine Option.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 12328154414
Url: https://administrator.de/contentid/12328154414
Printed on: May 24, 2024 at 18:05 o'clock
16 Comments
Latest comment
Das zu debuggen ist eine Wissenschaft für sich, aber prinzipiell können sich beide Betroffenen bei ihrem Provider melden, den Traceroute auf den Tisch legen und darum bitten dass das Problem weg geht.
Wenn du mir deine IP zukommen lässt (per PN) kann ich mal schauen, was ich in unseren BGP-Tables dazu finde und ob es nicht vielleicht doch an deinem Provider liegen könnte (z.B. Blackholing der IP).
Wenn du mir deine IP zukommen lässt (per PN) kann ich mal schauen, was ich in unseren BGP-Tables dazu finde und ob es nicht vielleicht doch an deinem Provider liegen könnte (z.B. Blackholing der IP).
2
Der Name des Providers wäre noch interessant.
Bedenke auch das Traceroute zumindestens bei Winblows auf Basis von ICMP arbeitet und deshalb sehr oft auf den Provider Routern geblockt ist, was dann ebenfalls zu dieser Fehlermeldung führt. Die ist also, was das Routing anbetrifft, wenig aussagekräftig.
Sinnvoller ist es einen Traceroute auf TCP Basis zu verwenden.
https://www.namecheap.com/support/knowledgebase/article.aspx/9777/2194/h ...
Sinnvoller ist es einen Traceroute auf TCP Basis zu verwenden.
https://www.namecheap.com/support/knowledgebase/article.aspx/9777/2194/h ...
Moin @alex156,
dieses Problem, sprich ein nicht funktionierendes Routing zwischen ISP zu ISP, sehen wir bei den WAN Anschlüssen unserer Kunden leider immer häufiger. 😔
Normalerweise verschwindet dieses Problem nach 1-2 Tagen von ganz alleine.
Gruss Alex
Kann mir jemand bei der weiteren Diagnose helfen? Irgendwie komme ich nicht mehr weiter. Aktualisiert sich die Routing table des Providers wieder mal?
dieses Problem, sprich ein nicht funktionierendes Routing zwischen ISP zu ISP, sehen wir bei den WAN Anschlüssen unserer Kunden leider immer häufiger. 😔
Normalerweise verschwindet dieses Problem nach 1-2 Tagen von ganz alleine.
Gruss Alex
ein nicht funktionierendes Routing zwischen ISP zu ISP
Wohl kaum wenn alles bei einem einzigen ISP betrieben wird... 
Zitat des TO: "Die beiden Clients sind beim selben Provider mit der gleichen Anbindung (also Technisch)"
Es sei denn der ISP hat seine Hausaufgaben im eigenen, internen Netz nicht gemacht.
Moin @aqui,
Zitat des TO: "Die beiden Clients sind beim selben Provider mit der gleichen Anbindung (also Technisch)"
Es sei denn der ISP hat seine Hausaufgaben im eigenen, internen Netz nicht gemacht.
ähm, der TO schreibt lediglich, das die beiden problematischen Client beim selben ISP sind, nicht jedoch, dass auch der Server beim gleichen ISP steht. 😉
Gruss Alex
ein nicht funktionierendes Routing zwischen ISP zu ISP
Wohl kaum wenn alles bei einem einzigen ISP betrieben wird... Zitat des TO: "Die beiden Clients sind beim selben Provider mit der gleichen Anbindung (also Technisch)"
Es sei denn der ISP hat seine Hausaufgaben im eigenen, internen Netz nicht gemacht.
ähm, der TO schreibt lediglich, das die beiden problematischen Client beim selben ISP sind, nicht jedoch, dass auch der Server beim gleichen ISP steht. 😉
Gruss Alex
1
Dürfte wirklich das klassische Routing-Problem eines ISP sein. Eben weil beide Clients denselben ISP haben.
Früher(TM) waren diverse MMO-Foren voll von solchen Problemen. Wobei es da eher nur um schlechte Latenz ging.
Machen kann man da herzlich wenig, da es auf ISP-Seite liegt, wie die routen.
Man kann aber den Weg gehen, mit dem ISP-Support von den betroffenen Clients aus ein Traceroute an deinen Server zu machen. Eventuell sieht dann sogar der Supportmensch, dass er selber den Server erreichen kann, die Clients aber nicht.
k.
Früher(TM) waren diverse MMO-Foren voll von solchen Problemen. Wobei es da eher nur um schlechte Latenz ging.
Machen kann man da herzlich wenig, da es auf ISP-Seite liegt, wie die routen.
Man kann aber den Weg gehen, mit dem ISP-Support von den betroffenen Clients aus ein Traceroute an deinen Server zu machen. Eventuell sieht dann sogar der Supportmensch, dass er selber den Server erreichen kann, die Clients aber nicht.
k.
1
Wenn der Server Port customizebar ist einfach mal auf einen anderen UDP Port wechseln. Wenn Provider blocken, blocken sie ja oft nur die Standard Ports.
Moin @aqui,
fall jetzt bitte nicht tot um, aber die meisten ISP's bei uns in Deutschland können nicht wirklich gut auf IP oder Port Ebene blocken, weil deren, auf hoch performantes Routing ausgelegte Hardware, das schlichtweg nicht wirklich hergibt.
Gruss Alex
Wenn der Server Port customizebar ist einfach mal auf einen anderen UDP Port wechseln. Wenn Provider blocken, blocken sie ja oft nur die Standard Ports.
fall jetzt bitte nicht tot um, aber die meisten ISP's bei uns in Deutschland können nicht wirklich gut auf IP oder Port Ebene blocken, weil deren, auf hoch performantes Routing ausgelegte Hardware, das schlichtweg nicht wirklich hergibt.
Gruss Alex
Dort kommt in der Regel ja nur Juniper, Cisco und manchmal auch etwas Alcatel zum Einsatz und die können das alles in Silizium ohne jeglichen Einfluss auf die IP Forwarding Performance...
Moin @aqui,
und genau das mit "ohne jeglichen Einfluss auf die IP Forwarding Performance" haben mir mehre Techniker bei diversen Providern genau andersherum erzählt. Sprich bis zu einer geringen Menge an Filtereinträgen, die im unteren vierstelligem Bereich liegt, können die schon Filtern, aber darüber wir die Hardware sau langsam.
Wie gesagt, das habe ich mir so nicht selber ausgedacht sondern, genau so wurde es mir mittlerweile schon von mehreren ISP Technikern erklärt.
Gruss Alex
Dort kommt in der Regel ja nur Juniper, Cisco und manchmal auch etwas Alcatel zum Einsatz und die können das alles in Silizium ohne jeglichen Einfluss auf die IP Forwarding Performance...
und genau das mit "ohne jeglichen Einfluss auf die IP Forwarding Performance" haben mir mehre Techniker bei diversen Providern genau andersherum erzählt. Sprich bis zu einer geringen Menge an Filtereinträgen, die im unteren vierstelligem Bereich liegt, können die schon Filtern, aber darüber wir die Hardware sau langsam.
Wie gesagt, das habe ich mir so nicht selber ausgedacht sondern, genau so wurde es mir mittlerweile schon von mehreren ISP Technikern erklärt.
Gruss Alex
Moinsen Alex!
haben mir mehre Techniker bei diversen Providern genau andersherum erzählt.
Falsche Clientel befragt! Frage einen der Hersteller SEs, dann bekommst du auch belastbare Antworten.
Moin @aqui,
da dies eine öffentliche Unterhaltung ist, muss ich jetzt im wahrsten Sinne des Wortes, etwas um den heissen Brei herumreden.
Zuerst hatte ich mein Anliegen eigentlich ans BSI gemeldet, die haben es auch dankend angenommen.
Nach einer gewissen zeit habe ich keine Veränderungen gesehen und habe daraufhin beim BSI etwas nachgebohrt.
Daraufhin bekam ich vom BSI eine Antwort, die ich zuerst nicht wirklich glauben wollte.
Dann habe ich bei mehreren Providern selbst angerufen und musste feststellen, das das BSI mich mit deren Antwort doch nicht veräppelt hat.
Glaub mir, ich bin über den Zustand auch nicht glücklich, da ich deswegen auf den SGW's unserer Kunden, nach wie vor und das schon seit duzenden Monaten, immer wieder denselben Mist sehen muss. 😭
Aqui, weil es eben ist wie es ist, muss sich fast jeder Anschlussinhaber in Deutschland, leider auch fast komplett selbst verteidigen. 😔
Gruss Alex
Falsche Clientel befragt! Frage einen der Hersteller SEs, dann bekommst du auch belastbare Antworten.
da dies eine öffentliche Unterhaltung ist, muss ich jetzt im wahrsten Sinne des Wortes, etwas um den heissen Brei herumreden.
Zuerst hatte ich mein Anliegen eigentlich ans BSI gemeldet, die haben es auch dankend angenommen.
Nach einer gewissen zeit habe ich keine Veränderungen gesehen und habe daraufhin beim BSI etwas nachgebohrt.
Daraufhin bekam ich vom BSI eine Antwort, die ich zuerst nicht wirklich glauben wollte.
Dann habe ich bei mehreren Providern selbst angerufen und musste feststellen, das das BSI mich mit deren Antwort doch nicht veräppelt hat.
Glaub mir, ich bin über den Zustand auch nicht glücklich, da ich deswegen auf den SGW's unserer Kunden, nach wie vor und das schon seit duzenden Monaten, immer wieder denselben Mist sehen muss. 😭
Aqui, weil es eben ist wie es ist, muss sich fast jeder Anschlussinhaber in Deutschland, leider auch fast komplett selbst verteidigen. 😔
Gruss Alex
@aqui:
Das mag alles sein, wenn du direkt auf dem FPC filterst. Aber bei Providern hast du gerne PPP-Sessions die dann per RADIUS eine Portfilterregel bekommen. Nur so kannst du nämlich den Businesskunden weiterhin ungefiltert Internet bereitstellen.
Und auf PPP-Sessions kannst du eben nur vergleichsweise wenig Filter anwenden bis die Hardware lahm wird.
Das mag alles sein, wenn du direkt auf dem FPC filterst. Aber bei Providern hast du gerne PPP-Sessions die dann per RADIUS eine Portfilterregel bekommen. Nur so kannst du nämlich den Businesskunden weiterhin ungefiltert Internet bereitstellen.
Und auf PPP-Sessions kannst du eben nur vergleichsweise wenig Filter anwenden bis die Hardware lahm wird.
1
Moin @LordGurke,
vielen Dank für deine ausführliche Antwort.
eine kleine Frage zu dieser.
Meine Anfrage damals beim BSI, betraf aber nicht die Filterung einer einzelnen PPP Session, sondern eher einen flächendeckenden Ausschluss z.B. bestimmter IP's und auch kleinerer IP-Bereiche.
Gelten hier auch ähnliche Restriktionen, sprich, dass man nur eine bestimmte Menge an IP's global sperren kann, bis die Hardwareperformance anfängt empfindlich einzubrechen?
Gruss Alex
Das mag alles sein, wenn du direkt auf dem FPC filterst. Aber bei Providern hast du gerne PPP-Sessions die dann per RADIUS eine Portfilterregel bekommen. Nur so kannst du nämlich den Businesskunden weiterhin ungefiltert Internet bereitstellen.
Und auf PPP-Sessions kannst du eben nur vergleichsweise wenig Filter anwenden bis die Hardware lahm wird.
Und auf PPP-Sessions kannst du eben nur vergleichsweise wenig Filter anwenden bis die Hardware lahm wird.
vielen Dank für deine ausführliche Antwort.
eine kleine Frage zu dieser.
Meine Anfrage damals beim BSI, betraf aber nicht die Filterung einer einzelnen PPP Session, sondern eher einen flächendeckenden Ausschluss z.B. bestimmter IP's und auch kleinerer IP-Bereiche.
Gelten hier auch ähnliche Restriktionen, sprich, dass man nur eine bestimmte Menge an IP's global sperren kann, bis die Hardwareperformance anfängt empfindlich einzubrechen?
Gruss Alex
Wenn es das denn nun war bitte deinen Thread hier dann auch als erledigt schliessen!