13
Unerklärlich - diverse Hosts sind via diverse Mobilfunk Provider nicht erreichbar
Hallo zusammen,
ich stehe seit fast einer Woche vor einem Problem und kann mir keinen Reim drauf machen. Vielleicht sehe ich vor lauter Bäumen den Wald nicht und ihr könnt mir ein paar Tips bei der Fehlersuche und Beseitigung geben.
Wir nutzen zwei Internetleitungen in der Firma, eine bei UnityMedia (=WAN1) und die andere bei Telekom (=WAN2). Unsere Firma befindet sich im PLZ-Bereich 896xx Nähe Ulm. Wir haben also zwei verschiedene öffentliche WAN IP-Adressen. Beide Leitungen hängen an einer pfSense. Es gibt einen Webserver in der DMZ, der via NAT und Portforwarding durch die WAN1-Leitung (=UnityMedia) von außen erreicht wird. Dieser ist jedoch seit einer Woche nicht mehr von außen abrufbar, allerdings nur wenn der Endanwender über seinen Mobilfunkprovider Datentarif surft. Sitzt jemand zu Hause im Home-Office oder sonstwo, dann kann er die Webseite ganz normal erreichen ohne jegliche Einschränkungen.
Nun, wir haben diverse Tests gemacht, um die Sache etwas einzugrenzen. Ich habe die Webseite aus über 10 (!) verschiedenen Hosts aus ganz Deutschland und sogar EU aufgerufen, alles Festnetz-Internetanschlüsse ==> alles OK, kein Problem!.wir haben an den smartphones von verschiedenen Leuten probiert die Seite aufzurufen und alle getesteten Mobilfunkprovider schlagen FEHL, also Vodafone, Telekom, E-Plus. Nur ein einziger Mobilfunkprovider war in der Lage die Seite aufzurufen, habe nicht mehr genau im Kopf welche SIM-Karte der Mitarbeiter nutzte, ich glaube das war irgendein Abkömmling von O2 oder was anderes.
Die Webseite steht bis heute nicht für Mobilfunkanwender zur Verfügung und ich habe sämtliche traceroute Ergebnisse überprüft, die mir aber leider kein klares Bild ergeben. Da uns zwei verschiedene Internetleitungen zur Verfügung stehen in der Firma haben wir natürlich auch testweise die andere Leitung als Eingang versucht. Wir haben die Konfiguration also von WAN1 (=UnityMedia) auf WAN2 (=Telekom) umgeschaltet. DNS außen vor gelassen weil wir direkt mit IP und Netcat getestet haben um DNS-Fehler auszuschließen. Sowohl Eingang- als auch Rückroute gingen dabei über WAN2 (erfolgreich getestet). Trotz allem bleibt das Problem weiterhin bestehen. Mit dem Latein am Ende.
Dann kam seit gestern folgendes Phänomen hinzu an meinen eigenen Internetanschluss zuhause (=Kabelanschluss bei UnityMedia). Ich kann seit zwei Tagen die webseite tempr.email (37.120.161.148) nicht aufrufen. Auch Pings schlagen fehl. Bei mir zuhause hat sich absolut nichts verändert. Diesen Host allerdings kann ich problemlos von der Firma aus aufrufen, aus beiden Internetprovidern (WAN1+WAN2) aus.
Nun ein paar technische Informationen:
tracert zu tempr.email [37.120.161.148] von meinem Anschluss zuhause aus (=UnityMedia Kabelanschluss):
tracert tempr.email
Tracing route to tempr.email [37.120.161.148]
over a maximum of 30 hops:
1 <1 ms * <1 ms {von mir maskiert}
2 <1 ms <1 ms <1 ms {von mir maskiert}
3 15 ms 25 ms 14 ms HSI-KBW-134-3-228-1.hsi14.kabel-badenwuerttemberg.de [134.3.228.1]
4 24 ms 12 ms 18 ms 172.30.9.85
5 14 ms 15 ms 21 ms de-str01c-rc1-ae43-0.aorta.net [84.116.190.181]
6 23 ms 22 ms 13 ms de-fra01b-rc1-ae4-0.aorta.net [84.116.140.201]
7 12 ms 14 ms 10 ms de-fra01b-ri1-ae0-0.aorta.net [84.116.134.6]
8 20 ms 38 ms 18 ms 213.46.179.118.aorta.net [213.46.179.118]
9 * * * Request timed out.
10 * * * Request timed out.
11 * * * Request timed out.
man sieht hier deutlich, dass bei aorta.net Schluss ist.
traceroute zu unserer Firmen-Webseite, als wir WAN1 (=UnityMedia) als Eingang/Ausgang statisch konfiguriert hatten
1 abgekürzt/maskiert
2 abgekürzt/maskiert
...
...
11 letzter Knoten hier 84.116.191.198. Der vorletzte Hop war 84.116.133.114 (PTR=de-fra01b-rc1-ae5-0.aorta.net). Auffallend, dass auch hier aorta.net auftaucht. Diese IP-Adressen gehören beide zum Adressblock des Providers Liberty Global B.V. mit der ASN 6830 in Vaduz, Schweiz. Der reverse hostname suffix deutet auf aorta.net. Nach etwas Recherche fand ich heraus --> Liberty Global ist Mutterkonzern von UnityMedia.
Domain Name: aorta.net
Registry Domain ID: 1948069_DOMAIN_NET-VRSN
Registrar WHOIS Server: whois.enterprice.net
Registrar URL: http://www.epag.de/en/whois/
Updated Date: 2018-09-10T08:10:16Z
Creation Date: 1998-09-10T04:00:00Z
Registrar Registration Expiration Date: 2019-09-09T04:00:00Z
Registrar: EPAG Domainservices GmbH
Registrar IANA ID: 85
Registrar Abuse Contact Email: legal@tucows.com
Registrar Abuse Contact Phone: +1.4165350123
[...]
Weitere Infos auf www.epag.de
traceroute zu unserer Firmen-Webseite, als wir WAN2 (=Telekom) als Eingang/Ausgang statisch konfiguriert hatten
==> bricht ab beim Knoten 217.7.70.42. Diese IP-Adresse gehört zum Adressblock des Providers Deutsche Telekom AG mit der ASN 3320 in Wesel, NRW. Hier also keine Spur von aorta.net ?
Im Internet konnte ich keine Infos zu diesem Phänomen finden. Das Einzige was ich damit in Zusammenhang bringen könnte wäre ein kürzlich gestartetes Router-Experiment, welches vorzeitig abgebrochen wurde weil es doch einige Provider betroffen hatte und ihre Router zum Absturz führte. Dass ein Provider aber mit abgestürzte Router so viele Tage keine Stellungnahme bietet wäre schon komisch. Demnach müssten ja auch zig andere Personen außer mir/uns betroffen sein.
Hier der Link zu Golem --> https://www.golem.de/news/internet-infrastruktur-fehlerhafte-router-stop ...
bedanke mich für jeden hilfreichen Tip und Idee zur Fehlersuche.
Panguu
ich stehe seit fast einer Woche vor einem Problem und kann mir keinen Reim drauf machen. Vielleicht sehe ich vor lauter Bäumen den Wald nicht und ihr könnt mir ein paar Tips bei der Fehlersuche und Beseitigung geben.
Wir nutzen zwei Internetleitungen in der Firma, eine bei UnityMedia (=WAN1) und die andere bei Telekom (=WAN2). Unsere Firma befindet sich im PLZ-Bereich 896xx Nähe Ulm. Wir haben also zwei verschiedene öffentliche WAN IP-Adressen. Beide Leitungen hängen an einer pfSense. Es gibt einen Webserver in der DMZ, der via NAT und Portforwarding durch die WAN1-Leitung (=UnityMedia) von außen erreicht wird. Dieser ist jedoch seit einer Woche nicht mehr von außen abrufbar, allerdings nur wenn der Endanwender über seinen Mobilfunkprovider Datentarif surft. Sitzt jemand zu Hause im Home-Office oder sonstwo, dann kann er die Webseite ganz normal erreichen ohne jegliche Einschränkungen.
Nun, wir haben diverse Tests gemacht, um die Sache etwas einzugrenzen. Ich habe die Webseite aus über 10 (!) verschiedenen Hosts aus ganz Deutschland und sogar EU aufgerufen, alles Festnetz-Internetanschlüsse ==> alles OK, kein Problem!.wir haben an den smartphones von verschiedenen Leuten probiert die Seite aufzurufen und alle getesteten Mobilfunkprovider schlagen FEHL, also Vodafone, Telekom, E-Plus. Nur ein einziger Mobilfunkprovider war in der Lage die Seite aufzurufen, habe nicht mehr genau im Kopf welche SIM-Karte der Mitarbeiter nutzte, ich glaube das war irgendein Abkömmling von O2 oder was anderes.
Die Webseite steht bis heute nicht für Mobilfunkanwender zur Verfügung und ich habe sämtliche traceroute Ergebnisse überprüft, die mir aber leider kein klares Bild ergeben. Da uns zwei verschiedene Internetleitungen zur Verfügung stehen in der Firma haben wir natürlich auch testweise die andere Leitung als Eingang versucht. Wir haben die Konfiguration also von WAN1 (=UnityMedia) auf WAN2 (=Telekom) umgeschaltet. DNS außen vor gelassen weil wir direkt mit IP und Netcat getestet haben um DNS-Fehler auszuschließen. Sowohl Eingang- als auch Rückroute gingen dabei über WAN2 (erfolgreich getestet). Trotz allem bleibt das Problem weiterhin bestehen. Mit dem Latein am Ende.
Dann kam seit gestern folgendes Phänomen hinzu an meinen eigenen Internetanschluss zuhause (=Kabelanschluss bei UnityMedia). Ich kann seit zwei Tagen die webseite tempr.email (37.120.161.148) nicht aufrufen. Auch Pings schlagen fehl. Bei mir zuhause hat sich absolut nichts verändert. Diesen Host allerdings kann ich problemlos von der Firma aus aufrufen, aus beiden Internetprovidern (WAN1+WAN2) aus.
Nun ein paar technische Informationen:
tracert zu tempr.email [37.120.161.148] von meinem Anschluss zuhause aus (=UnityMedia Kabelanschluss):
tracert tempr.email
Tracing route to tempr.email [37.120.161.148]
over a maximum of 30 hops:
1 <1 ms * <1 ms {von mir maskiert}
2 <1 ms <1 ms <1 ms {von mir maskiert}
3 15 ms 25 ms 14 ms HSI-KBW-134-3-228-1.hsi14.kabel-badenwuerttemberg.de [134.3.228.1]
4 24 ms 12 ms 18 ms 172.30.9.85
5 14 ms 15 ms 21 ms de-str01c-rc1-ae43-0.aorta.net [84.116.190.181]
6 23 ms 22 ms 13 ms de-fra01b-rc1-ae4-0.aorta.net [84.116.140.201]
7 12 ms 14 ms 10 ms de-fra01b-ri1-ae0-0.aorta.net [84.116.134.6]
8 20 ms 38 ms 18 ms 213.46.179.118.aorta.net [213.46.179.118]
9 * * * Request timed out.
10 * * * Request timed out.
11 * * * Request timed out.
man sieht hier deutlich, dass bei aorta.net Schluss ist.
traceroute zu unserer Firmen-Webseite, als wir WAN1 (=UnityMedia) als Eingang/Ausgang statisch konfiguriert hatten
1 abgekürzt/maskiert
2 abgekürzt/maskiert
...
...
11 letzter Knoten hier 84.116.191.198. Der vorletzte Hop war 84.116.133.114 (PTR=de-fra01b-rc1-ae5-0.aorta.net). Auffallend, dass auch hier aorta.net auftaucht. Diese IP-Adressen gehören beide zum Adressblock des Providers Liberty Global B.V. mit der ASN 6830 in Vaduz, Schweiz. Der reverse hostname suffix deutet auf aorta.net. Nach etwas Recherche fand ich heraus --> Liberty Global ist Mutterkonzern von UnityMedia.
Domain Name: aorta.net
Registry Domain ID: 1948069_DOMAIN_NET-VRSN
Registrar WHOIS Server: whois.enterprice.net
Registrar URL: http://www.epag.de/en/whois/
Updated Date: 2018-09-10T08:10:16Z
Creation Date: 1998-09-10T04:00:00Z
Registrar Registration Expiration Date: 2019-09-09T04:00:00Z
Registrar: EPAG Domainservices GmbH
Registrar IANA ID: 85
Registrar Abuse Contact Email: legal@tucows.com
Registrar Abuse Contact Phone: +1.4165350123
[...]
Weitere Infos auf www.epag.de
traceroute zu unserer Firmen-Webseite, als wir WAN2 (=Telekom) als Eingang/Ausgang statisch konfiguriert hatten
==> bricht ab beim Knoten 217.7.70.42. Diese IP-Adresse gehört zum Adressblock des Providers Deutsche Telekom AG mit der ASN 3320 in Wesel, NRW. Hier also keine Spur von aorta.net ?
Im Internet konnte ich keine Infos zu diesem Phänomen finden. Das Einzige was ich damit in Zusammenhang bringen könnte wäre ein kürzlich gestartetes Router-Experiment, welches vorzeitig abgebrochen wurde weil es doch einige Provider betroffen hatte und ihre Router zum Absturz führte. Dass ein Provider aber mit abgestürzte Router so viele Tage keine Stellungnahme bietet wäre schon komisch. Demnach müssten ja auch zig andere Personen außer mir/uns betroffen sein.
Hier der Link zu Golem --> https://www.golem.de/news/internet-infrastruktur-fehlerhafte-router-stop ...
bedanke mich für jeden hilfreichen Tip und Idee zur Fehlersuche.
Panguu
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 417701
Url: https://administrator.de/contentid/417701
Ausgedruckt am: 21.11.2024 um 17:11 Uhr
13 Kommentare
Neuester Kommentar
Moin,
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.52.1 - 0 | 51 | 51 | 2 | 7 | 107 | 5 |
| Request timed out. - 100 | 11 | 0 | 0 | 0 | 0 | 0 |
| de-str01c-rc1-ae32-0.aorta.net - 0 | 51 | 51 | 26 | 57 | 269 | 26 |
| de-fra01b-rc1-ae4-0.aorta.net - 0 | 50 | 50 | 26 | 54 | 242 | 34 |
| de-fra01b-ri1-ae0-0.aorta.net - 0 | 50 | 50 | 27 | 52 | 224 | 35 |
| 213.46.179.118.aorta.net - 0 | 50 | 50 | 30 | 59 | 273 | 30 |
| app.tempr.email - 0 | 50 | 50 | 29 | 55 | 268 | 53 |
Sieht für mich so aus, als würde der Server bestimmte IP Subnetze per iptables o.ä. Funktionen einfach blockieren.
Gruß,
Dani
man sieht hier deutlich, dass bei aorta.net Schluss ist.
Das ist ganz einfach, warum da Schluss ist:|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.52.1 - 0 | 51 | 51 | 2 | 7 | 107 | 5 |
| Request timed out. - 100 | 11 | 0 | 0 | 0 | 0 | 0 |
| de-str01c-rc1-ae32-0.aorta.net - 0 | 51 | 51 | 26 | 57 | 269 | 26 |
| de-fra01b-rc1-ae4-0.aorta.net - 0 | 50 | 50 | 26 | 54 | 242 | 34 |
| de-fra01b-ri1-ae0-0.aorta.net - 0 | 50 | 50 | 27 | 52 | 224 | 35 |
| 213.46.179.118.aorta.net - 0 | 50 | 50 | 30 | 59 | 273 | 30 |
| app.tempr.email - 0 | 50 | 50 | 29 | 55 | 268 | 53 |
Sieht für mich so aus, als würde der Server bestimmte IP Subnetze per iptables o.ä. Funktionen einfach blockieren.
==> bricht ab beim Knoten 217.7.70.42. Diese IP-Adresse gehört zum Adressblock des Providers Deutsche Telekom AG mit der ASN 3320 in Wesel, NRW. Hier also keine Spur von aorta.net ?
Mit dieser Information würde ich einmal den Support der DTAG konfrontieren. Wobei hast du eine SDSL Leitung wirds zeit- und nervenintensiv. Mit einer Standleitung (CC oder DCIP) bekommst das Fachpersonal mit dem Rückruf an die Hand.Gruß,
Dani
Abend Nachbar,
lass das mal von Unitymedia prüfen, ich hatte ebenfalls so einen unerklärlichen Fall (allerdings international), dass zu und von einem UM Kunden keine Mails nach Südamerika gingen. Ende vom Lied war genau diese Fehlerhaften Routings. Da kannst du nur eines tun: schauen, dass das Ticket in den 3rd Level kommt und nicht locker lassen.
Viel Erfolg!
lass das mal von Unitymedia prüfen, ich hatte ebenfalls so einen unerklärlichen Fall (allerdings international), dass zu und von einem UM Kunden keine Mails nach Südamerika gingen. Ende vom Lied war genau diese Fehlerhaften Routings. Da kannst du nur eines tun: schauen, dass das Ticket in den 3rd Level kommt und nicht locker lassen.
Viel Erfolg!
Hallo,
ich habe bei uns monatelang auch ein ähnliches Problem gehabt, nämlich das man vom Handy aus keine eMails mehr abrufen konnte vom Firmen-Exchange. VPN, VoIP, etc. ging auch nicht mehr, man konnte das Firmennetz überhaupt nicht mehr erreichen übers Handynetz. Im heimischen oder firmischen WLAN funktionierte es dagegen immer. Es funktionierte aber auch nicht immer nicht. Mal ging es, mal nicht, und ich konnte es auch an keinem Provider festmachen. Es trat auch immer zu selten auf (bzw. meldeten sich die Mitarbeiter zu selten), um es zu finden. Da keine Verbindung zustande kam, war auch in keinem Log was zu finden. Die einzige Konstante war das Mobilnetz, vom Festnetz ging es immer. Deshalb suchte ich den Schuldigen zuerst irgendwie bei den Providern.
Es hat wie gesagt Monate gedauert, bis ich merkte, das das Problem bei uns lag bzw. an der Firewall. Die fragte nämlich diverse Realtime Black Lists (RBLs) ab, und blockierte dadurch munter allerhand Mobil- und Dialup-IPs, weil diese in einer bestimmten sehr restriktiven RBL standen. Nachdem ich die betreffende RBL gelöscht hatte und nun nicht mehr abfrage, funktioniert alles wieder wunderbar.
Vllt. hast Du in Deiner pfSense auch was ähnliches laufen, was das hier blocken könnte?
cu,
ipzipzap
ich habe bei uns monatelang auch ein ähnliches Problem gehabt, nämlich das man vom Handy aus keine eMails mehr abrufen konnte vom Firmen-Exchange. VPN, VoIP, etc. ging auch nicht mehr, man konnte das Firmennetz überhaupt nicht mehr erreichen übers Handynetz. Im heimischen oder firmischen WLAN funktionierte es dagegen immer. Es funktionierte aber auch nicht immer nicht. Mal ging es, mal nicht, und ich konnte es auch an keinem Provider festmachen. Es trat auch immer zu selten auf (bzw. meldeten sich die Mitarbeiter zu selten), um es zu finden. Da keine Verbindung zustande kam, war auch in keinem Log was zu finden. Die einzige Konstante war das Mobilnetz, vom Festnetz ging es immer. Deshalb suchte ich den Schuldigen zuerst irgendwie bei den Providern.
Es hat wie gesagt Monate gedauert, bis ich merkte, das das Problem bei uns lag bzw. an der Firewall. Die fragte nämlich diverse Realtime Black Lists (RBLs) ab, und blockierte dadurch munter allerhand Mobil- und Dialup-IPs, weil diese in einer bestimmten sehr restriktiven RBL standen. Nachdem ich die betreffende RBL gelöscht hatte und nun nicht mehr abfrage, funktioniert alles wieder wunderbar.
Vllt. hast Du in Deiner pfSense auch was ähnliches laufen, was das hier blocken könnte?
cu,
ipzipzap
Wenn ich irgendwohin getracert habe, habe ich oft keine Antworten mehr erhalten, obwohl die Seiten funktionierten. Deswegen empfinde ich persönlich den Test als unzuverlässig.
Hat evtl die Webseite irgendwelche Schutzmechanismen/Bottraps? Kopier mal eine phpinfo ins Root und schau ob diese evtl erreicht wird.
Hat evtl die Webseite irgendwelche Schutzmechanismen/Bottraps? Kopier mal eine phpinfo ins Root und schau ob diese evtl erreicht wird.
Was versprichst du dir von einer "phpinfo ins root"? Wenn es um Netzprobleme geht
@Dani:
Wie kommst du drauf, dass der Server tempr.email bestimmte Subnetze blockiert? Das deckt sich aber nicht mit meiner Erfahrung, dass ich diesen Server von meinem Heimplatz (=UM) nicht erreichen kann, aber vom Firmenplatz (=WAN1 UM) erreichen kann. Es sind also beide UM-Anschlüsse, jedoch in der Firma ein Bussinessanschluss mit anderem IP-Adressbereich. Dass der Fehler bei der DTAG liegen soll, ist nach den bisherigen Tests auch nicht klar.
@ipzipzap: nein, in der pfSense ist sowas nie konfiguriert worden und an der Konfiguration hat sich ja auch sonst nichts geändert. Aber trotzdem danke für den Tip.
@NordicMike: nein, an dem Host wurde auch nichts verändert. Und ich habe auch anderen Host getestet in der DMZ, exakt dasselbe. Es liegt nicht am Webserver selbst. Wie gesagt, der Webserver wird ja auch problemlos erreicht für alle anderen Anfragen, die nicht von Mobilfunk stammen. Ausserdem habe ich auch andere Ports und Regeln getestet, indem ich z.B. auf dem Host mit netcat einfach einen lauschenden Port öffne und mich darauf von außen verbinde und teste. Exakt dasselbe Problem.
Die Sache mit tempr.email bei mir zuhause habe ich erwähnt, weil sie auch von jetzt auf nachher kam, seit 3-4 Tagen ca habe ich das Problem. Es hat nichts mit der Mobilfunkproblematik gemeinsam aus unsrer Firma, aber es könnte vielleicht wirklich an gecrashten Routern von diversen Providern liegen?
Die Frage ist nur --> welchen Kundendienst soll ich da kontaktieren? Unitymedia? Telekom? Vodafone? Eplus? O2? .... Fragezeichen²
Wie kommst du drauf, dass der Server tempr.email bestimmte Subnetze blockiert? Das deckt sich aber nicht mit meiner Erfahrung, dass ich diesen Server von meinem Heimplatz (=UM) nicht erreichen kann, aber vom Firmenplatz (=WAN1 UM) erreichen kann. Es sind also beide UM-Anschlüsse, jedoch in der Firma ein Bussinessanschluss mit anderem IP-Adressbereich. Dass der Fehler bei der DTAG liegen soll, ist nach den bisherigen Tests auch nicht klar.
@ipzipzap: nein, in der pfSense ist sowas nie konfiguriert worden und an der Konfiguration hat sich ja auch sonst nichts geändert. Aber trotzdem danke für den Tip.
@NordicMike: nein, an dem Host wurde auch nichts verändert. Und ich habe auch anderen Host getestet in der DMZ, exakt dasselbe. Es liegt nicht am Webserver selbst. Wie gesagt, der Webserver wird ja auch problemlos erreicht für alle anderen Anfragen, die nicht von Mobilfunk stammen. Ausserdem habe ich auch andere Ports und Regeln getestet, indem ich z.B. auf dem Host mit netcat einfach einen lauschenden Port öffne und mich darauf von außen verbinde und teste. Exakt dasselbe Problem.
Die Sache mit tempr.email bei mir zuhause habe ich erwähnt, weil sie auch von jetzt auf nachher kam, seit 3-4 Tagen ca habe ich das Problem. Es hat nichts mit der Mobilfunkproblematik gemeinsam aus unsrer Firma, aber es könnte vielleicht wirklich an gecrashten Routern von diversen Providern liegen?
Die Frage ist nur --> welchen Kundendienst soll ich da kontaktieren? Unitymedia? Telekom? Vodafone? Eplus? O2? .... Fragezeichen²
-> UM.
Wieso UM? Wenn ich die Telekomleitung als Ein-/Ausgang in der Firma nutze und die UM-Leitung nicht anfasse, dann besteht das Problem weiterhin. Das kann also nicht 100%ig an UM liegen?
Zitat von @certifiedit.net:
Was versprichst du dir von einer "phpinfo ins root"? Wenn es um Netzprobleme geht
Was versprichst du dir von einer "phpinfo ins root"? Wenn es um Netzprobleme geht
Wie geschrieben, ich möchte damit ausschließen, dass ein Bottrap auf der Webseite die Probleme verursacht. Und damit wäre es eingrenzt, dass es ein reiner Netzwerkfehler ist, weil auf den tracert kein Verlass ist.
@NordicMike: gut gemeinter Ratschlag, aber daran liegt's nicht weil ich ja auch mit anderen Ports mittels "netcat" getestet habe.
Aber sapperlott!!! jetzt plötzlich tut wieder alles, ohne dass ich je was verändert habe. Ein Kollege hatte vor knapper Woche bereits eine Email an den Support von Vodafone gesendet. Er hat heute morgen eine Antwort erhalten, dass sie komische Resultate bekämen, die sie aber nicht interpretieren können weil das nur unsere IT auf unsrer Seite erklären könnte. (Blödsinn?). Seitdem geht's aber komischerweise. Wer weiß also, was die da gemacht oder resettet haben. Die Kommunikation mit Vodafone-Support lief schon einige Tage.
Das Problem ist also heute morgen endlich (!) gelöst. Wir werden wohl nie erfahren, was die Ursache war
aber ich bin ja glücklich, dass es wieder tut.
an alle Beteiligten ==> vielen Dank!
PS: Das Problem von mir zuhause mit Festnetz UnityMedia besteht jedoch weiterhin. Ich kann den Host tempr.email [37.120.161.148] immer noch nicht erreichen. So langsam bestärkt sich immer weiter der Verdacht, dass ein Routing-/Gatewayproblem bei diesem großen Unternehmen aorta.net existiert(e) und die das nach und nach korrigieren und wieder fixen. Ich denke, dass die nicht nur UM Verkehr routen, sondern dass auch mehrere Provider und Blöcke über deren gateways abgewickelt werden. Würde mich also nicht wundern, wenn dieses Router-Experiment und die BGP crashes von neulich auch Hardware von aorta.net erwischt haben. Natürlich würden die das niemals offenkundig zugeben.
Aber sapperlott!!! jetzt plötzlich tut wieder alles, ohne dass ich je was verändert habe. Ein Kollege hatte vor knapper Woche bereits eine Email an den Support von Vodafone gesendet. Er hat heute morgen eine Antwort erhalten, dass sie komische Resultate bekämen, die sie aber nicht interpretieren können weil das nur unsere IT auf unsrer Seite erklären könnte. (Blödsinn?). Seitdem geht's aber komischerweise. Wer weiß also, was die da gemacht oder resettet haben. Die Kommunikation mit Vodafone-Support lief schon einige Tage.
Das Problem ist also heute morgen endlich (!) gelöst. Wir werden wohl nie erfahren, was die Ursache war
aber ich bin ja glücklich, dass es wieder tut.an alle Beteiligten ==> vielen Dank!
PS: Das Problem von mir zuhause mit Festnetz UnityMedia besteht jedoch weiterhin. Ich kann den Host tempr.email [37.120.161.148] immer noch nicht erreichen. So langsam bestärkt sich immer weiter der Verdacht, dass ein Routing-/Gatewayproblem bei diesem großen Unternehmen aorta.net existiert(e) und die das nach und nach korrigieren und wieder fixen. Ich denke, dass die nicht nur UM Verkehr routen, sondern dass auch mehrere Provider und Blöcke über deren gateways abgewickelt werden. Würde mich also nicht wundern, wenn dieses Router-Experiment und die BGP crashes von neulich auch Hardware von aorta.net erwischt haben. Natürlich würden die das niemals offenkundig zugeben.
Hallo Panguu
tempr.email sperrt tatsächlich IP-Adressen, wenn eine gewissen Anzahl an gleichzeitigen Verbindungen überschritten wird. Denn natürlich kämpfen wir auch gegen Missbrauch des Dienstes, vor allem wenn es um automatisierte Zugriffe geht.
Wir haben jetzt einige Regeln aufgehoben, vielleicht kannst Du jetzt wieder auf tempr.email zugreifen.
Natürlich müssen wir diese Schutzmaßnahme nochmals überarbeiten, da mittlerweile viele Provider aufgrund des IPv4-Mangels eine IP-Adresse auf mehrere Kunden aufteilen und sich nur noch der Port je Anschluss unterscheidet.
Du kannst Dich gern bei weiteren Fragen, direkt an den Support von tempr.email wenden.
LG
Frank
tempr.email sperrt tatsächlich IP-Adressen, wenn eine gewissen Anzahl an gleichzeitigen Verbindungen überschritten wird. Denn natürlich kämpfen wir auch gegen Missbrauch des Dienstes, vor allem wenn es um automatisierte Zugriffe geht.
Wir haben jetzt einige Regeln aufgehoben, vielleicht kannst Du jetzt wieder auf tempr.email zugreifen.
Natürlich müssen wir diese Schutzmaßnahme nochmals überarbeiten, da mittlerweile viele Provider aufgrund des IPv4-Mangels eine IP-Adresse auf mehrere Kunden aufteilen und sich nur noch der Port je Anschluss unterscheidet.
Du kannst Dich gern bei weiteren Fragen, direkt an den Support von tempr.email wenden.
LG
Frank
da mittlerweile viele Provider aufgrund des IPv4-Mangels eine IP-Adresse auf mehrere Kunden aufteilen
gleichzeitig? :schock:
Ja, Pyur zum Beispiel. Da haben alle Anschlüsse in einem Straßenzug teilweise die gleiche IP, nur der Port ist unterschiedlich. So kommen auch mal Captcha-Abfragen, wenn man in Google suchen will
