Time out op website maar raar resultaat reverse DNS

[on4bam]

Hi,

Een website die ik het afgelopen jaar enkele keren bezocht geeft al enkele dagen een time out. Via een plugin in FF (IP Address and Domain Information) zie ik het IP van de server en het resultaat van een reverse DNS lookup. Ik zou verwachten dat ik daar ofwel de domeinnaam of de servernaam (bij shared hosting) zie staan maar in dit geval zie ik "smtp8.allytech.com". Bij de poorten staan zowel 80 als 443 op "closed".

Heb ik het juist oor dat er een misconfiguratie is op de server die zorgt dat een een request op de URL naar de mailserver gaat i.p.v. de webserver?

Een ping en een tracert naar het IP en domein werken normaal.

[ubremoved_539]

Reverse DNS is totaal niet van belang voor een website.

Je hebt een hostname, die resolved en op dat IP-adres moet een webserver draaien (die jou de juiste virtual host content geeft).

[on4bam]

OK, maar andere sites op dezelfde server geven ook time out. Dat er aangegeven wordt dat poort 80 en 443 dicht staan lijkt mij toch een configuratiefout? Als ik hetzelfde bekijk met de FF add-on op andere sites staan die 2 poorten open.

Ik zal de mensen van de site maar eens contacteren (voor een B&B is een site die offline staat een probleem).

[ubremoved_539]

Als poort 80 en 443 dicht staan dat is de server gewoon down... je zoekt het veel te ver.

Een configuratiefout zou ik dat trouwens niet meteen noemen

[on4bam]

Een paar andere servers met IP's +/-1 2 3.. zijn ook niet bereikbaar, anderen dan weer wel. Niks dringend voor mij, wel wat vervelend omdat ik nog iets wou nakijken.

[Ofloo]

Reverse dns is in iedergeval niet van belang.

* Firewall filter
* MTU probleem
* Slechte DNS server, check of alle dns servers hetzelfde soa record hebben
* Heeft deze server IPv6 misschien bereiken de andere deze via IPv6 ipv IPv4 ?
* .htaccess denied jouw IP ?
* http://isup.me

nmap -sT -p80,443 -P0 serverhost

* Poorten dicht van de reverse host of van je webserver host? Het A record van het PTR record hoeft niet perse jaar jouw IP gericht staan. Het kan best een ander IP hebben. Het is dus niet omdat jouw IP naar een bepaald PTR verwijst dat dit dan ook automatisch terug naar jouw IP verwijst.

[on4bam]

Ondertussen heb ik nog wat getest.

Website http://www.naupatagonia.com.ar/ is nog steeds onbereikbaar van op PC en laptop, zowel met Firefox (63.0.1) als met Chrome (70.0.3538.102) bij EDPnet.

Website is wel bereikbaar met Firefox/Android via Jim mobile maar NIET als ik via VPN op mijn Fritzbox connecteer.

Mijn IP staat niet op blacklists (via https://whatismyipaddress.com/blacklist-check)

Ik kan gewoon mailen naar hen.

Kan iemand die ook bij EDPnet zit eens kijken of het probleem algemeen voor EDPnet is? Mijn IP is momenteel 109.236.137.***

Edit: URL

[ubremoved_539]

Website http://www.naupatagonia.com.ar/ is nog steeds onbereikbaar van op PC en laptop, zowel met Firefox (63.0.1) als met Chrome (70.0.3538.102) bij EDPnet.

Post dan eens een trace route.

Mijn IP staat niet op blacklists (via https://whatismyipaddress.com/blacklist-check)

Wat heeft een mail blacklist te maken met of jij wel of niet een website kan bezoeken

Ik kan trouwens via TN ook gewoon de website bezoeken... heeft dus duidelijk iets te maken met EDPnet z'n routing.

[datakiller]

Ik kan trouwens via TN ook gewoon de website bezoeken... heeft dus duidelijk iets te maken met EDPnet z'n routing.

Kan iemand die ook bij EDPnet zit eens kijken of het probleem algemeen voor EDPnet is? Mijn IP is momenteel 109.236.137.***

Hier kan ik de website ook bezoeken (met EDPnet).

[heist_175]

ook bij EDPnet, IP adres 77.109.97.*

Code: Selecteer alles

  1    <1 ms    <1 ms    <1 ms  fritz.box [192.168.1.1]
  2     7 ms     6 ms     6 ms  bras01.bxl.be.edpnet.net [213.219.132.16]
  3     7 ms     7 ms     7 ms  br01.bxl.be.edpnet.net [212.71.11.1]
  4     6 ms     6 ms     6 ms  brx-b2-link.telia.net [62.115.46.29]
  5    10 ms    10 ms    10 ms  adm-bb3-link.telia.net [62.115.118.114]
  6    10 ms    10 ms    10 ms  adm-b1-link.telia.net [62.115.136.195]
  7    10 ms    10 ms    10 ms  telecomitalia-ic-327065-adm-b1.c.telia.net [62.115.9.33]
  8   251 ms   251 ms   250 ms  et2-0-5.baires5.bai.seabone.net [195.22.220.15]
  9   270 ms   270 ms   270 ms  iplan.baires5.bai.seabone.net [185.70.203.51]
 10   254 ms   254 ms   255 ms  190.210.118.157
 11   251 ms   253 ms   251 ms  customer-static-210-110-149.iplannetworks.net [190.210.110.149]
 12   242 ms   242 ms   242 ms  smtp8.allytech.com [200.68.105.8]

[on4bam]

Wat heeft een mail blacklist te maken met of jij wel of niet een website kan bezoeken

Dat was als reactie of ik soms niet geblokkeerd stond (meer dan blacklists kan ik niet zien, ik kan niet aan hun htaccess file,hé).

Tracert:
2 10 ms 9 ms 10 ms bras02.bxl.be.edpnet.net [213.219.132.26]
3 11 ms 13 ms 10 ms 212.71.11.205.static.edpnet.net [212.71.11.205]
4 14 ms 11 ms 10 ms brx-b2-link.telia.net [62.115.46.29]
5 14 ms 15 ms 15 ms adm-bb3-link.telia.net [62.115.118.114]
6 15 ms 15 ms 13 ms adm-b1-link.telia.net [62.115.136.195]
7 15 ms 15 ms 14 ms telecomitalia-ic-327065-adm-b1.c.telia.net [62.115.9.33]
8 265 ms 260 ms 260 ms et2-0-5.baires5.bai.seabone.net [195.22.220.15]
9 282 ms 284 ms 284 ms iplan.baires5.bai.seabone.net [185.70.203.51]
10 266 ms 263 ms 271 ms 190.210.118.157
11 251 ms 252 ms 252 ms customer-static-210-110-149.iplannetworks.net [190.210.110.149]
12 250 ms 250 ms 249 ms smtp8.allytech.com [200.68.105.8]

Trace complete.

Dat is dus geen probleem.

[ubremoved_539]

Dat was als reactie of ik soms niet geblokkeerd stond (meer dan blacklists kan ik niet zien, ik kan niet aan hun htaccess file,hé).

SMTP blacklists hebben totaal niets te maken met HTTP servers... ik zie het verband niet (net zoals dat er niet was met je reverse DNS).

Trace complete. Dat is dus geen probleem.

Inderdaad, dit is dus geen routing probleem.

Wat krijg je als je een telnet naar de host op poort 80 doet ?

Lukt dat, doe dan eens een "GET /" en tweemaal enter.

[on4bam]

Wat krijg je als je een telnet naar de host op poort 80 doet ?

Could not open connection..... enz.. Connect failed.

[ubremoved_539]

Bizar... zeker omdat datakiller de website via EDPnet wel kan bezoeken.

Ik zou dus eens bij je thuis gaan zoeken wat je allemaal doet in je firewall/router/... haal het er desnoods allemaal tussenuit.

[heist_175]

Of adblocking scripts en plugins etc

[on4bam]

In FF heb ik wel een aantal plugins maar Chrome is een "blote" versie. De site werkt als ik via Jim ga op de tablet maar niet op het thuisnetwerk. Er is al lang niets veranderd aan de settings van mijn FB 7490 en een paar weken terug werkte de site wel nog, er wordt niets geblokkeerd in de FB blacklist. Alle andere sites werken behalve sites die op dezelfde server gehost zijn of op "naburige servers" (dezelfde hosting co.)

Ik snap er niets van.

[ubremoved_539]

Of adblocking scripts en plugins etc

Nee, want dan zou de TELNET wel een connectie geven.

Gewoon de bestaand router/firewall/... er tussen uit halen en testen met een andere.

Draai trouwens eens een wireshark op die "telnet www.naupatagonia.com.ar 80".

[CCatalyst]

Wat krijg je als je een telnet naar de host op poort 80 doet ?

Could not open connection..... enz.. Connect failed.

Om te zien of het probleem toch niet ergens aan DNS ligt, doe ook nog eens telnet 200.68.105.8 80

Website is wel bereikbaar met Firefox/Android via Jim mobile maar NIET als ik via VPN op mijn Fritzbox connecteer.

Probeer eens via Hotspot functie op Android en dan met je computer via die hotspot ipv via EDPnet.

Als het dan wel lukt sluit je tenminste je computer volledig uit als de oorzaak.

Blijven nog je router over en eventuele filtering in het datacenter als oorzaken. Eerste is dan meest waarschijnlijk, kan bv een bug zijn ook.

Draai trouwens eens een wireshark op die "telnet http://www.naupatagonia.com.ar 80".

^ dit is nu idd de volgende stap in het proces.

Interessant probleem wel.

[ubremoved_539]

Doe ook nog eens telnet 200.68.105.8 80

Z'n tracert resolved naar dat IP-adres... maakt dus geen verschil.

[CCatalyst]

Z'n tracert resolved naar dat IP-adres... maakt dus geen verschil.

Nee, dat kan je niet met 100% uitsluitsel afleiden uit het laatste resultaat in de traceroute.

Hoe er lokaal geresolved wordt kan je wel afleiden uit de hele eerste output van traceroute (traceroute to http://www.naupatagonia.com.ar (200.68.105.8 ), 64 hops max, 52 byte packets), maar dat heeft OP niet gepost in zijn resultaat.

[ubremoved_539]

Ik denk wel dat we daar met heel grote zekerheid vanuit kunnen gaan... z'n laatste entries van z'n trace zijn identiek aan die van mij dus daar is echt niets speciaals aan te zien.

Gebruikt de TS trouwens Windows of Linux, heeft hij geprutst aan z'n TCP/IP settings (zoals MTU), ...

[on4bam]

Gebruikt de TS trouwens Windows of Linux, heeft hij geprutst aan z'n TCP/IP settings (zoals MTU), ...

Win 7 en nee.
Laptop Win10 en nee
Tablet Android 7 en nee

Code: Selecteer alles

Tracing route to naupatagonia.com.ar [200.68.105.8]
over a maximum of 30 hops:

  1     1 ms    <1 ms     1 ms  192.168.178.1
  2     7 ms     7 ms     7 ms  bras02.bxl.be.edpnet.net [213.219.132.26]
  3     8 ms     7 ms     7 ms  212.71.11.205.static.edpnet.net [212.71.11.205]
  4    15 ms    60 ms    13 ms  brx-b2-link.telia.net [62.115.46.29]
  5    11 ms    10 ms    10 ms  adm-bb3-link.telia.net [62.115.118.114]
  6    11 ms    11 ms    11 ms  adm-b1-link.telia.net [62.115.136.195]
  7    11 ms    11 ms    11 ms  telecomitalia-ic-327065-adm-b1.c.telia.net [62.115.9.33]
  8   257 ms   269 ms   257 ms  et2-0-5.baires5.bai.seabone.net [195.22.220.15]
  9   281 ms   279 ms   279 ms  iplan.baires5.bai.seabone.net [185.70.203.51]
 10   256 ms   264 ms   261 ms  190.210.118.157
 11   249 ms   250 ms   249 ms  customer-static-210-110-149.iplannetworks.net [190.210.110.149]
 12   247 ms   246 ms   247 ms  smtp8.allytech.com [200.68.105.8]

Trace complete.

Edit:
Getest met oude Medion netbook waarop 2 weken terug Lububtu is geinstalleerd. Niets aangepast, alles default en hetzelfde probleem.

[ubremoved_539]

Wireshark dan... en een test via een andere router dan je FB.

[CCatalyst]

Wireshark zal idd misschien nog iets opleveren, maar lijkt dus een probleem met de router te zijn.

Probeer turning it off and on again, probeer firewall te clearen, als het zich nog voordoet en het is geen configuratieprobleem ga je wellicht richting factory reset moeten gaan.

Jammer dat je hier met een closed-box software zit (denk ik?) en je dus wellicht niet kunt grasduinen in de shell naar de mogelijke oorzaak.

Als het probleem zich na de factory reset nog voordoet wordt het nog interessanter

Noot dat een MTU-probleem andere symptomen zou geven, de telnet connectie zou bv nog wel slagen. Als de MTU daarvoor al te laag was zou OP naar geen enkele site nog kunnen surfen.

My guess is dat de Fritzbox de netblock filtert omdat die mss fail2ban of een of andere sanitizing rule getriggerd heeft. Desondanks laat hij blijkbaar wel nog ICMP door. Maar Ik ken het apparaat in kwestie niet, dus misschien weet iemand anders wat het zou kunnen zijn.

[on4bam]

Aangezien ik geen andere modem heb dan de FB kan ik daar niet verder.

Wireshark:

Code: Selecteer alles

105	24.142832	192.168.178.xxx	200.68.105.8	TCP	62	58477 → 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1464 SACK_PERM=1
117	27.147843	192.168.178.xxx	200.68.105.8	TCP	62	[TCP Retransmission] 58477 → 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1464 SACK_PERM=1
140	33.146044	192.168.178.xxx	200.68.105.8	TCP	62	[TCP Retransmission] 58477 → 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1464 SACK_PERM=1

Er is geen firewall (behalve NAT) op de FB, geen filters of wat dan ook.

Edit:

Reboot (geen restart) van de FB gedaan. Daarna een nieuw IP gekregen. I.p.v. 109.236.137.xxx heb ik nu 212.71.9.xxx
De site laadt nu wel in maar een telnetsessie blijft stilstaan, geen error en geen reply.... tot er "connection to host lost" verschijnt.

Waar het probleem zat... Dunno... aangezien zowel de reboot als een andere IPrange de oplossing kunnen zijn. De enige mogelijkheid zal zijn om nog eens te testen mocht ik nog eens een 109.xxx IP krijgen.

[CCatalyst]

De site laadt nu wel in maar een telnetsessie blijft stilstaan, geen error en geen reply.... tot er "connection to host lost" verschijnt.

Ik vermoed dat je er wel verbonden mee raakt via telnet? Da's dan normaal als je geen commando's stuurt. Na een tijd heb je dan gewoon timeout. Als je zou interageren zoals een browser zou doen zou je normaal wel communicatie moeten hebben over telnet.

Waar het probleem zat... Dunno... aangezien zowel de reboot als een andere IPrange de oplossing kunnen zijn.

Ik zet mijn geld in op de reboot.

Zoals zo vaak, turning it off and on again (of een equivalent) lost het op

Als het zich herhaalt in de toekomst wel meer wireshark output geven want met die 3 lijntjes zouden we het niet kunnen oplossen. Gebruik dan ook Cloudshark eventueel.

[on4bam]

Zoals zo vaak, turning it off and on again (of een equivalent) lost het op

Ik had al enkele herstarts gedaan de laatste tijd maar nu heb ik de stekker er uit getrokken. Vreemd dat het slechts 1 site (IP range) was met probs, alle andere sites werkten gewoon.

BTW, get / intypen terwijl telnet connecteerd geeft wel een reply (DOCTYPE enz, dus headers van de index pagina) daarna is het "connection lost.

[ubremoved_539]

BTW, get / intypen terwijl telnet connecteerd geeft wel een reply (DOCTYPE enz, dus headers van de index pagina) daarna is het "connection lost.

Oh, maar dan werkt het dus... het is namelijk normaal dat je verbinding verbroken wordt na het opvragen van de webpagina.

Je verbinding is dus in orde, de webserver werkt, ...

[on4bam]

Je verbinding is dus in orde, de webserver werkt, ... duidelijk dus een browser probleem !

Huh??

Welk browserprobleem?

on4bam schreef:
De site laadt nu wel in

[ubremoved_539]

Ik was te snel en had nog niet gelezen dat je je router had herstart (daaorm heb ik dat stuk in de reply ook verwijderd).

[CCatalyst]

BTW, get / intypen terwijl telnet connecteerd geeft wel een reply (DOCTYPE enz, dus headers van de index pagina) daarna is het "connection lost.

Niet mee inzitten, dit resultaat is volledig normaal en toont dat alles werkt zoals het zou moeten. Dit is omdat je geen Host header meestuurt (wat een browser wel doet) en de server bijgevolg niet weet welke site je wil bezoeken. Telnet maakt immers verbinding met een bepaald IP adres, en op de meeste IP's zijn meerdere websites geconfigureerd. Een browser stuurt daarom ook een Host header waarin de FQDN staat.

Als je die Host header niet stuurt krijg je naargelang de configuratie van de webserver meestal de "default" website te zien, en meestal is dat een al even "default" blanke pagina met niets op. Sommige webservers geven een 404.

Telnet-test komt alleen neer op nagaan of je wel een verbinding kan maken met de server, omdat dat wat problemen kan elimeren. Het is niet vereist dat je ook de juiste webpagina terugkrijgt etc.

[ubremoved_539]

Dit is omdat je geen Host header meestuurt (wat een browser wel doet) en de server bijgevolg niet weet welke site je wil bezoeken. Telnet maakt immers verbinding met een bepaald IP adres, en op de meeste IP's zijn meerdere websites geconfigureerd. Een browser stuurt daarom ook een Host header waarin de FQDN staat.

Dit (connection lost) heeft niets met de host header te maken, hij heeft trouwens een index pagina gekregen (en jij en ik kunnen niet weten of dit de juist was, laat staan dat het een shared hosting is - ook is de kans groot).

Het is niet vereist dat je ook de juiste webpagina terugkrijgt etc.

Niemand sprak hier van de juiste webpagina voor zover ik weet... TELNET is gewoon een connectie test (die mogelijke browser issues uitsluit). Trouwens je kan altijd GET / <enter>Host: www.gewenstdomain.com<enter><enter> typen en dan krijg je wel de juiste pagina bij een shared hosting.

[CCatalyst]

Welja, wat ik dus wou zeggen is dat het normaal is dat OP die specifieke reply kreeg (headers zonder body) en daarna de connectie verbroken werd.

Zoals je zegt, als OP daarentegen een geldige HTTP/1.1 request zou sturen zou hij wel de volledige indexpagina krijgen zoals ook zichtbaar is in de browser, en zou de verbinding ook niet verbroken worden gezien HTTP/1.1 meerdere requests per sessie toelaat. Meevaller dat deze specifieke site niet HTTPS-only is.

[on4bam]

Meevaller dat deze specifieke site niet HTTPS-only is.

Het is HTTP only. Net al verschillende andere sites die we bezochten. Ik heb al meermaals bedrijven laten links liggen omdat ze op niet beveiligde sites hun reservatiedetails lieten invullen. Meestal stuur ik dan nog een mailtje dat ik helaas niets wil reserveren en CC info invullen op hun site. Ze liggen daar in Zuid Amerika blijkbaar ook niet van wakker.

[CCatalyst]

Ze liggen daar in Zuid Amerika blijkbaar ook niet van wakker.

Of het is voor hen niet evident om geld te vinden om iemand te betalen om de website TLS te maken, ook al is een certificaat tegenwoordig gratis. Dat is iets waar wij in het westen soms te weinig aan denken. Voor ons is dat allemaal makkelijk haalbaar, maar dat wil daarom niet zeggen dat dat in armere landen ook zo makkelijk haalbaar is .

Daarom dat ik persoonlijk ook vrij weigerachtig sta tov de aanpak van Google om HTTP-only sites zo zwaar te gaan penaliseren. Zo'n beslissingen zijn eenvoudig om te maken in Silicon Valley, waar alles al TLS-only is. Maar denken ze wel aan de impact voor andere regio's?

Daarnaast ook opletten met TLS als criterium te zien. Je kan een perfecte TLS website hebben die langs andere kanten weer zo lek is als een zeef. Foetsie, kredietkaartgegevens.

In jouw geval is de oplossing wellicht eenvoudig: via booking.com boeken. Ja, daar houdt de gerant dan minder aan over, maar da's dan de prijs om niet zelf een TLS website te hebben.

[on4bam]

In jouw geval is de oplossing wellicht eenvoudig: via booking.com boeken. Ja, daar houdt de gerant dan minder aan over, maar da's dan de prijs om niet zelf een TLS website te hebben.

Op 1 na idd via booking maar Mastercard is ginder ook minder populair tegenover Visa en AE. Ze hebben het er ook nogal voor Paypal of cash (liefst US$ want de peso verliest snel waarde).
In elk geval, als we de keuze hebben tussen rechtstreeks of via booking reserveren doen we dat (onder dezelfde omstandigheden) liefst rechtstreeks. Ik ga er van uit dat het beter is dat de locals er aan verdienen dan een multinational. Tot nu toe is dat altijd een goede beslissing gebleken. Maar nu zijn we serieus OT aan't gaan.

[ubremoved_539]

Of het is voor hen niet evident om geld te vinden om iemand te betalen om de website TLS te maken, ook al is een certificaat tegenwoordig gratis.

Niet alle hosters laten trouwens Let's Encrypt toe...

[Geert-Jan]

In FF heb ik wel een aantal plugins maar Chrome is een "blote" versie. De site werkt als ik via Jim ga op de tablet maar niet op het thuisnetwerk. Er is al lang niets veranderd aan de settings van mijn FB 7490 en een paar weken terug werkte de site wel nog, er wordt niets geblokkeerd in de FB blacklist. Alle andere sites werken behalve sites die op dezelfde server gehost zijn of op "naburige servers" (dezelfde hosting co.)

Ik snap er niets van.

Gebruik jij repeaters om het wifi-signaal van de 7490 te boosten?
Want de 7490 heeft een bug met repeaters die ze niet opgelost krijgen, waardoor sites onbereikbaar worden danwel heel traag laden.
Dat is de reden dat ikzelf de 7490 weggedaan heb, zonder wifi-repeaters werkt die wel goed, maar was ik toen niets mee.

[on4bam]

Gebruik jij repeaters om het wifi-signaal van de 7490 te boosten?

Nee, WiFi van de FB is goed genoeg op een deel van de eerste verdieping (50% power), het andere deel heeft Wifi van een AP (10% power) op de 2e verdieping. Wifi dient enkel voor tablet e.d. de rest is wired.

[Geert-Jan]

Je vermogen is wel te laag om goede snelheden te halen.
Waarom zet je die vermogens zo laag?

Ik zet mijn vermogen altijd en overal op 100%.