webserver vanaf bepaalde locatie niet te bereiken

[Verwijderd]

Ik heb een probleem met een specifieke webserver dat mij en de beheerder voor een raadsel stellen. Misschien dat een kundig persoon hier een antwoord weet.

Het gaat om www.tmlp.com. Ik kan niets dat op die server staat (via http) benaderen. Echter: alleen bij mij thuis, -en- op m'n werk. Wanneer ik de website via een terminal server (die ergens anders in dezelfde stad waar ik werk staat) benader, is er niets aan de hand. Sterker nog: -iedereen- die ik het heb gevraag heeft geen enkel probleem met het benaderen van de website. Inclusief iemand die in dezelfde plaats woont en dezelfde ISP gebruikt. Het treedt bij alle PC's bij mij thuis en op m'n werk op, inclusief een aantal PC's waar een verse Windows XP installatie op staat. Het is geen DNS-probleem: de domeinnaam wordt naar het juiste IP-adres geresolved.

Ik heb het er met de beheerder van het domein over gehad, en met hem ben ik erachter gekomen dat ik een andere webserver die achter dezelfde router staat wel kan bereiken, wat zou suggereren dat er iets met de webserver zelf aan de hand is. Echter, dan zou niemand hem moeten kunnen benaderen, terwijl het op maar twee locaties gebeurt.

Als ik een proxyserver instel, is er overigens geen probleem en kan ik de website gewoon benaderen...

Heeft iemand enig idee wat er hier aan de hand kan zijn?

[ Voor 171% gewijzigd door Verwijderd op 27-02-2006 19:49 ]

[Verwijderd]

ALLEEN http niet bereikbaar?
Lijkt er haast wel op dat er een deny all op je ip staat ofzo?

Kan je ftp, smtp, pop3 enzo wel bij?

[ Voor 18% gewijzigd door Verwijderd op 27-02-2006 19:49 ]

[Verwijderd]

Geen idee, ik heb geen ftp/pop/smtp account daar. De enige mogelijkheid die ik heb om het te testen is via http. En dan zou er een deny all op zowel mijn ip als dat van mijn werk moeten staan.

Edit: ik heb even via de WXP command-line ftp client geprobeerd te verbinden (kijken of hij zowieso een welkom-message geeft), en dat geeft mij het volgende resultaat:

ftp> open tmlp.com
Verbonden met tmlp.com.
Verbinding verbroken door externe host.

Geen idee wat ik daarvan moet maken.

[ Voor 86% gewijzigd door Verwijderd op 27-02-2006 19:59 ]

[royco_100]

Ik kan de site hier ook niet bereiken!

[doctormetal]

royco_100 schreef op maandag 27 februari 2006 @ 19:52:
Ik kan de site hier ook niet bereiken!

Vanaf mijn locatie (caiway) lukt het ook niet.

[JasperE]

Misschien kom je hier verder mee:
http://www.dnsstuff.com/tools/tracert.ch?ip=69.64.111.246

Die traceroute 'komt wel aan', kijk dan op je eigen pc waar je vastloopt.

[ Voor 30% gewijzigd door JasperE op 27-02-2006 20:04 ]

[Verwijderd]

Interessant dat er blijkbaar meerdere mensen zijn die hem niet kunnen bereiken..

OD-Frozen schreef op maandag 27 februari 2006 @ 20:03:
Die traceroute 'komt wel aan', kijk dan op je eigen pc waar je vastloopt.

Bedankt, ik had het zelf ook al geprobeerd en bij mij kwam hij niet verder dan ma1-gw4-ge0-etcetera. Maar volgens mij komt die dnsstuff tracert ook niet verder: na ma1-gw4-ge0-etcetera zegt hij immers 'unknown.conversent.net (router did not respond).' Voor zover ik zie komt hij dus ook niet verder.

Ik heb dit ook aan de beheerder gemeld, die vertelt mij dat ma1-gw4-bla een router in Massachusetts is, en de laatste 'tussenstop' tot zijn router. Die blokt echter alle ping-requests, dus dat zou verklaren waarom zowel ik als dnsstuff niet verder komen.

[ Voor 8% gewijzigd door Verwijderd op 27-02-2006 20:16 ]

[killercow]

hier het zelfde (multikabel, noord holland),

Obviously een kapotte route.

[Verwijderd]

misschien heb je er niets aan, maar ik kom er ook niet op (speedlinq in het oosten van het land)

code:

 11   104 ms   106 ms   104 ms  206.111.13.29.ptr.us.xo.net [206.111.13.29]
 12   105 ms   105 ms   105 ms  p5-0-0.RAR2.NYC-NY.us.xo.net [65.106.3.41]
 13   110 ms   110 ms   110 ms  p4-1-0.MAR2.Cambridge-MA.us.xo.net [65.106.3.34]

 14   110 ms   109 ms   110 ms  p15-0.CHR1.Cambridge-MA.us.xo.net [207.88.86.46]

 15     *        *        *     Request timed out.

[WooK]

ik zie hem wel, misschien een fatsoenlijke hostingpartij zoeken?

[Verwijderd]

Vergeten te vermelden,

Hij werkt hier perfect. @home, blok oldenzaal.

[Sendy]

Je schrijft "Ik kan niets dat op die server staat (via http) benaderen.". Kan je dat preciseren? Krijg je geen verbinding, geen data of krijg je een 404?

Je kan dit uitvinden door met ethereal het verkeer te sniffen. TCP heeft een three-way handshake: Eerst een "syn" van de source, dan een "ack+syn" van de target en als laatste een "ack" van de source. Nu is de verbinding gemaakt.

Gebruik dus ethereal, en typ het command dat je wil sturen naar de webserver met een telnet client:

telnet www.server.nl 80

GET /index.html HTTP/1.1
Host: www.server.nl

Je kan eens kijken of de verbinding wordt gemaakt, of dat de 3-way handshake wordt verbroken.

edit:

Oh ja, je moet twee enters doen na de Host:

[ Voor 9% gewijzigd door Sendy op 27-02-2006 22:35 ]

[Wildfire]

Hier gebeurt er niets, de site laad niet... (TweakDSL via Tiscali hier)

-- Edit: via telnet nadat ik een paar keer op enter heb gedrukt en dan maar exit typ:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head>
<title>501 Method Not Implemented</title>
</head><body>
<h1>Method Not Implemented</h1>
<p>exit to /index.html not supported.<br/></p>
<hr />
<address>Apache/2.0.51 (Fedora) Server at default Port 80</address>
</body></html>

[ Voor 92% gewijzigd door Wildfire op 27-02-2006 20:45 ]

[Verwijderd]

Sendy schreef op maandag 27 februari 2006 @ 20:20:
Je schrijft "Ik kan niets dat op die server staat (via http) benaderen.". Kan je dat preciseren? Krijg je geen verbinding, geen data of krijg je een 404?

Je kan dit uitvinden door met ethereal het verkeer te sniffen. TCP heeft een three-way handshake: Eerst een "syn" van de source, dan een "ack+syn" van de target en als laatste een "ack" van de source. Nu is de verbinding gemaakt.

Bedankt voor de suggestie, ik heb ethereal gedownload maar ik ben bang dat het mij iets boven de pet gaat. Als leek kijkende lijkt mij dat ik niet verder kom dan de syn, maar wat dat inhoudt en wat ik eraan kan doen is me een raadsel...

C:

No.     Time        Source                Destination           Protocol Info
      1 0.000000    192.168.2.14          69.64.111.246         TCP      3142 > http [SYN] Seq=0 Ack=0 Win=16384 Len=0 MSS=1460
      2 2.460795    192.168.2.2           239.255.255.250       SSDP     NOTIFY * HTTP/1.1
      3 2.461311    192.168.2.2           239.255.255.250       SSDP     NOTIFY * HTTP/1.1
      4 2.461856    192.168.2.2           239.255.255.250       SSDP     NOTIFY * HTTP/1.1
      5 2.462437    192.168.2.2           239.255.255.250       SSDP     NOTIFY * HTTP/1.1
      6 2.462974    192.168.2.2           239.255.255.250       SSDP     NOTIFY * HTTP/1.1
      7 2.463516    192.168.2.2           239.255.255.250       SSDP     NOTIFY * HTTP/1.1
      8 2.464018    192.168.2.2           239.255.255.250       SSDP     NOTIFY * HTTP/1.1
      9 2.464624    192.168.2.2           239.255.255.250       SSDP     NOTIFY * HTTP/1.1
     10 2.465167    192.168.2.2           239.255.255.250       SSDP     NOTIFY * HTTP/1.1
     11 2.465655    192.168.2.2           239.255.255.250       SSDP     NOTIFY * HTTP/1.1
     12 2.466149    192.168.2.2           239.255.255.250       SSDP     NOTIFY * HTTP/1.1
     13 2.466836    192.168.2.2           239.255.255.250       SSDP     NOTIFY * HTTP/1.1
     14 2.923986    192.168.2.14          69.64.111.246         TCP      3142 > http [SYN] Seq=0 Ack=0 Win=16384 Len=0 MSS=1460
     15 8.858512    192.168.2.14          69.64.111.246         TCP      3142 > http [SYN] Seq=0 Ack=0 Win=16384 Len=0 MSS=1460
     16 22.459898   192.168.2.2           239.255.255.250       SSDP     NOTIFY * HTTP/1.1
     17 22.460234   192.168.2.2           239.255.255.250       SSDP     NOTIFY * HTTP/1.1
     18 22.460921   192.168.2.2           239.255.255.250       SSDP     NOTIFY * HTTP/1.1
     19 22.461457   192.168.2.2           239.255.255.250       SSDP     NOTIFY * HTTP/1.1
     20 22.462003   192.168.2.2           239.255.255.250       SSDP     NOTIFY * HTTP/1.1
     21 22.462534   192.168.2.2           239.255.255.250       SSDP     NOTIFY * HTTP/1.1
     22 22.463069   192.168.2.2           239.255.255.250       SSDP     NOTIFY * HTTP/1.1
     23 22.463589   192.168.2.2           239.255.255.250       SSDP     NOTIFY * HTTP/1.1
     24 22.463927   192.168.2.2           239.255.255.250       SSDP     NOTIFY * HTTP/1.1
     25 22.464469   192.168.2.2           239.255.255.250       SSDP     NOTIFY * HTTP/1.1
     26 22.464958   192.168.2.2           239.255.255.250       SSDP     NOTIFY * HTTP/1.1
     27 22.465484   192.168.2.2           239.255.255.250       SSDP     NOTIFY * HTTP/1.1
     28 22.466132   192.168.2.2           239.255.255.250       SSDP     NOTIFY * HTTP/1.1

[ Voor 90% gewijzigd door Verwijderd op 28-02-2006 00:08 . Reden: Overbodige zooi weggehaald ]

[Sendy]

Misschienk kan je alle overbodige headers, de lege regels, en de SSDP dingen weggooien. Die SSDP zijn een beetje vaag. De destination is 239.255.255.250, zegt je dat (of anderen) wat?

In deze dump zie ik dat er alleen een SYN van jou naar hem gestuurd lijkt te worden. De machine aan de andere kant antwoord dus helemaal niets op jouw SYN. Bij mij lijkt-ie precies hetzelfde te doen. De telnet kan helemaal geen verbinding maken.

Dan lijkt het me het probleem van de andere kant. Een verkeerde route of ander prutswerk kan dit verklaren

edit:

Oww, juk.. SSDP heeft te maken met UPnP. Gebruik je dat?

[ Voor 16% gewijzigd door Sendy op 27-02-2006 22:50 ]

[Verwijderd]

Sendy schreef op maandag 27 februari 2006 @ 22:47:
Misschienk kan je alle overbodige headers, de lege regels, en de SSDP dingen weggooien.

Goed idee.

Die SSDP zijn een beetje vaag. De destination is 239.255.255.250, zegt je dat (of anderen) wat?

Zegt mij niets, nee.. Ik kan het de beheerder nog vragen, misschien dat het hem wat zegt.

In deze dump zie ik dat er alleen een SYN van jou naar hem gestuurd lijkt te worden. De machine aan de andere kant antwoord dus helemaal niets op jouw SYN. Bij mij lijkt-ie precies hetzelfde te doen. De telnet kan helemaal geen verbinding maken.

Dan lijkt het me het probleem van de andere kant. Een verkeerde route of ander prutswerk kan dit verklaren

Okee... Maar, waarom treedt dit probleem voor andere mensen hier dan niet op? En wat is er te doen aan een verkeerde route?

edit:

Oww, juk.. SSDP heeft te maken met UPnP. Gebruik je dat?

Yep. Uitzetten haalt niets uit.

[Sendy]

Misschien kan je er nu nog een code=c tag van maken, dan komen de spaties beter uit (betere tips zijn welkom).

Zo'n route probleem heeft juist als symptoom dat verschillende mensen verschillend gedrag ervaren (een pakketje voor de ene persoon gaat via een werkende route, een pakketje voor een ander persoon gaan via een niet-werkende route). Echter, het zou wel vreemd zijn als dat internet-wijd verkeerd gaat.

Met meest waarschijnlijker is dat je gewoon geblockt bent

Als je er echt niet uitkomt moet de beheerder van de webserver beter kijken. Hij is de enige die kan zien of het verkeer van jou op zijn server aankomt en dat de pakketjes teruggestuurt worden. Als de pakketjes ergens middenin blijven steken dan zou ik jou of de beheerder van de webserver aanraden ergens een andere abbonement te nemen

[Black Piet]

Site is ook vanaf hier (casema; postc 2743) niet te bereiken. Succes met bovenstaande oplossingen

[Verwijderd]

Sendy schreef op dinsdag 28 februari 2006 @ 00:04:
Zo'n route probleem heeft juist als symptoom dat verschillende mensen verschillend gedrag ervaren (een pakketje voor de ene persoon gaat via een werkende route, een pakketje voor een ander persoon gaan via een niet-werkende route). Echter, het zou wel vreemd zijn als dat internet-wijd verkeerd gaat.

Kan, maar andere webservers achter die router kan ik prima benaderen, dus waarom worden die pakketjes dan niet verkeerd geroute?

Met meest waarschijnlijker is dat je gewoon geblockt bent

Lijkt me sterk, ik ben daar nog nooit geweest, en bovendien zou 75% van de posters hier dan ook geblockt zijn..

Als je er echt niet uitkomt moet de beheerder van de webserver beter kijken. Hij is de enige die kan zien of het verkeer van jou op zijn server aankomt en dat de pakketjes teruggestuurt worden. Als de pakketjes ergens middenin blijven steken dan zou ik jou of de beheerder van de webserver aanraden ergens een andere abbonement te nemen

Ik zal eens met hem bekijken of er zowieso iets van mij bij hem binnenkomt, ja. Bedankt voor de tips.

[b19a]

Ik kan de site ook niet bereiken vanuit Groningen met SpeedLinq. Succes met het probleem!

[Verwijderd]

Nogmaals wat dingen gecheckt, het kan simpelweg geen routing probleem zijn. Er zijn verschillende webservers achter die router die ik zonder probleem kan benaderen. Als het routing was, dan zou ik ook niet bij die andere servers kunnen komen, toch?

[Sendy]

Niet per sé, de server zelf kan ook een verkeerde instelling hebben. Maar dit lijkt toch niet zo waarschijnlijk.

[Verwijderd]

Misschien is het een PMTU probleem http://www.linux.com/howt...kbook.mtu-discovery.shtml, is de server misschien een linux bakkie en/of heeft 'ie een linux firewall ?

[Verwijderd]

Okee, ik heb weer met de beheerder gesproken, en wat blijkt? Volgens hem zijn na herhaaldelijke hack-aanvallen vanuit Amsterdam een hele zooi IP ranges van 80.0.0.0 tot 84.0.0.0 geblokt voor alle soorten toegang tot die server. Ik weet niet welke ranges het precies zijn (de terminal server waarmee ik wel toegang had heeft bijvoorbeeld een 81.x.x.x adres), en een proxy waarmee het werkt heeft een 80.x.x.x adres, maar waarschijnlijk ligt het probleem dus inderdaad in een ban. Sendy, I stand corrected.

Er wordt nu gekeken naar een minder drastische beveiligingsmaatregel... Als daar resultaat uit komt zal ik het hier nog wel posten voor future reference, maar voorlopig lijkt dit het te zijn. Erg bedankt allemaal voor jullie bijdragen!

Edit: Het blijkt dat alles geblokt is, -behalve- twee kleine ranges in 80.x en 81.x...

...precies die ranges waar de proxy en de terminal server in vielen. Bizarro-world. In ieder geval lijkt het erop dat dit inderdaad de oorzaak was.

[ Voor 15% gewijzigd door Verwijderd op 28-02-2006 23:00 ]