DNS-Problem - Nach ifdown eth0 gehts kurzzeitig

E

e1i7e

New Member
Hallo,

habe derzeit Probleme mit meinem Debian 5.0 x32 Root...

Folgendes: Ich versuche, mich per Wget zu Uploaded.to zu verbinden.
Als Name-Server habe ich in der /etc/network/interfaces den Google-DNS 8.8.8.8 eingetragen.

Wenn ich jetzt in der Konsole wget uploaded.to mache, passiert folgendes:
Code: 
--2010-08-19 21:49:05--  http://uploaded.to/
Resolving uploaded.to... 81.95.13.171
Connecting to uploaded.to|81.95.13.171|:80... failed: Connection timed out.
Retrying.

--2010-08-19 21:52:15--  (try: 2)  http://uploaded.to/
Connecting to uploaded.to|81.95.13.171|:80...

Und das geht immer so weiter.. Die IP stimmt - wenn ich die im Browser eingebe, geht alles. Über Iceweasel per VNC geht das über den Server auch. Nur php und die Konsole kann da irgendwie nicht drauf zugreifen?!

Wenn ich jetzt ifdown eth0 und ifup eth0 ausführe, geht das (manchmal) kurzzeitig wieder..

Kennt ihr da evtl. ne Lösung bzw nen Problem?


Hier nochmal die Konfiguration aus der /etc/network/interfaces:

Code: 
ds80-***-**.**:~# cat /etc/network/interfaces
# generated by FAI
auto lo eth0
iface lo inet loopback
iface eth0 inet static
  address 80.***.**.**
  netmask 255.255.255.0
  gateway 80.237.159.**
  dns-nameservers 8.8.8.8 80.237.128.144 80.237.128.145
auto eth1
iface eth1 inet static
  address 10.102.16.170
  netmask 255.255.255.252
 
Da die IP stimmt (erstmal egal, welcher DNS nun geantwortet hat), ist es kein DNS-Problem.
Derartige Seiten haben manchmal die seltsamsten Mechanismen implementiert, um sich vor mißbräuchlicher Nutzung zu schützen.
Versuch einfach mal, wget einen "gebräuchlichen" User-Agenten (mittels -U) mitzugeben, vielleicht reicht das schon.
 
Okay, also ich habe jetzt mal "Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:1.6) Gecko/20040206 Firefox/1.0.1" als User-Agent mitgesendet. Geht aber leider trotzdem nicht..

Bei einem anderen Hoster habe ich auch das Problem, dass er zwar per Wget geht, per php aber nen Timeout kommt.. Ich versteh diese ****** Schutz-Mechanismen nicht :D Hab sogar extra den Header, welchen Firefox sendet, mittels Curl gesendet, geht aber trotzdem nicht..

Hatte bis vor ca. nen Monat nen anderen Server bei nem anderen Provider - da ging alles. Daher dachte ich liegt an dem DNS oder so, aber anscheind ja nicht..

Weißt du sonst vllt. noch was anderes, was ich versuchen könnte?
 
Solche Mechanismen sind oft nicht nur recht obskur, sondern auch Geschäftsgeheimnis des Hostes.

Denkbar ist vieles. Header wie z.B. Referrer, Zahl paralleler Sessions, MTU, Quell-Port (und dessen Änderung pro Request, das könnte mit dem ifdown/ifup korrelieren) und natürlich die Quell-IP (die o.g. sieht nach HostEurope aus).

Halt alles zum Stichwort "Fingerprinting".
 
Da schon der (TCP-)Verbindungsaufbau fehlschlaegt, wird's an den Request-Headern/User-Agent wohl nicht liegen, da diese zu dem Zeitpunkt noch gar nicht gesendet wurde.

Was sagt denn ein ping/traceroute?
 
Aber dem Hoster könnte ein vorhergehender Verbindungsversuch nicht gepaßt haben und die IP temporär gebannt sein.
 
Tracert ergibt das:
Code: 
ds80-237-**.**:~# tracert uploaded.to
traceroute to uploaded.to (81.95.13.171), 30 hops max, 40 byte packets
 1  ds80-237-159-2.dedicated.hosteurope.de (80.237.159.2)  0.135 ms  0.171 ms  0                                                    .171 ms
 2  xe-0-0-0.cr-altair.cgn2.he-core.de (80.237.129.66)  0.834 ms  0.854 ms  0.87                                                    8 ms
 3  xe-0-0-0.cr-merak.fra2.he-core.de (80.237.129.85)  4.113 ms  4.115 ms  4.114                                                     ms
 4  xae0-499.fra20.core-backbone.com (80.81.192.187)  4.831 ms  5.126 ms  5.126                                                     ms
 5  xae0-632.nbg20.core-backbone.com (81.95.15.202)  8.078 ms  8.079 ms  8.079 m                                                    s
 6  81.95.13.171 (81.95.13.171)  8.481 ms  8.019 ms *

Ping folgendes:
Code: 
ds80-237-***-**:~# ping uploaded.to
PING uploaded.to (81.95.13.171) 56(84) bytes of data.


Ich hab auch schon an nen Bann gedacht, nur mich iritiert, dass nach ifdown eth0 und ifup eth0 alles (kurzzeitig) wieder geht... Kann dann ja eig kein Bann sein, würde ich sagen. Oder? irgendwas muss ifdown und ifup ja bewirken
 
Hmm, sehr eigenartig - also ein ping geht nicht, aber ein traceroute erreicht das Ziel...

Ich wuerde dann evtl. mal schauen, ob am lokalen System irgendwelche iptables Regeln gesetzt sind, die das beeinflussen koennten. Und der naechste Schritt waere dann wohl, mit tcpdump zu schauen, was wirklich raus geht und was zurueck kommt (und am besten wget mit Browser vergleichen).
 
You must log in or register to reply here.
Back
Top