Sziasztok!
T-Home kábelnetről és T-Mobile mobilnetről (mindkettő Békéscsaba) jelenleg nem tudom elérni a server5.megacp.com szervert, amin több domainem is lakik (pl. eatweb.net). Pingre nem válaszol, a traceroute pedig mindkét esetben a po13-403.c3750g-access-3.atw.hu szervernél taknyol el. Ugyanakkor többek között ez a szolgáltatás remekül látja, ez úgyszintén. Volt már korábban is jelzés 1-2 látogatótól, hogy nem tudták T-Home felőle elérni az oldalt, és akkor is valami atw.hu végződésű szervernél halt meg a traceroute, de nekem akkor sikerült a T-Home és T-Mobile szolgáltatásaimon keresztül elérni, illetve a turpisság elmúlt, miután az ügyfél kiiktatott egy routert és a PC-jét közvetlenül a kábelmodemre csatlakoztatta. A routert visszatéve a probléma ismét előjött, tehát nem csak egybeesés volt valami tök más problémával.
Tippek esetleg? Nálatok elérhető a server5.megacp.com? Ötletem sincs, merre induljak a probléma lokalizálásában...
UPDATE 2013-04-03 09:39: T-Mobile felől már jó. T-Home továbbra is fos.
UPDATE 2013-04-03 10:32: T-Mobile felől is újra halott. Remek.
UPDATE 2013-04-04 22:09: Stra által említett traceroute-ok kimenete itt. Egyébként Mac OS 10.6.8 alatt születtek a logok. A T-s router egy Cisco EPC3925 (ez egyben "modem" és router is egyben, sajnos ezért nem tudom kipróbálni az ügyfélnél bevált módszert), és a probléma egyik percről a másikra jelentkezett eredetileg, épp a szerveren dolgoztam (web/80 és FTP/21) mikor egyszer csak timeoutolt minden és azóta sem tudok visszakapcsolódni hozzá. A routeren az "SPI firewall protection" alapból "low" értéken volt, ezt próbáltam "off"-on is (látszólag nincs különbség, egyik módban sem változik a szűrt portok/szolgáltatások üres listája). A céges (Invitel bérelt) netkapcsolatunkról (igaz, ez egy másik PC) vígan elérhető a server5.megacp.com (ping, web, ftp, bármi).
UPDATE: A probléma megoldódott, az otthoni IP címem fail2ban miatt (hogy ez hogy jött össze nem egyértelmű, de biztos hogy nálam volt a gáz) tiltva lett, a Megacp azóta feloldotta a tiltást (ticket ment nekik).
Hozzászólások
tcptraceroute eatweb.net 80 lefut és curl eatweb.net is DP-ből nézve.
Szia!
T hostingból ellenőriztem egyet.
Ami kiderült: traceroute (Modern traceroute for Linux, version 2.0.18, Oct 18 2011) az ominózus atw-s ágon meghal.
mtr (mtr 0.80) tökéletesen belát a címig. (direkt az eatwebet néztem)
firefox gyönyörűen behozza az oldalt (igaz az elején elég sokáig keresgélt, de az valszeg az én resolvereim miatt volt.
Köszönöm a válaszokat!
ha még érdekes, akkor T-Com bérelt vonalról:
2. vl3374.ar4-belvaros.net.telekom.hu 0.0% 1.6 3.2 1.5 22.1 5.5
3. tge0-1-0-0.er1-huszti.net.telekom.hu 0.0% 5.8 5.8 5.6 6.0 0.1
4. c-tge0-1-0-0.er1-huszti.net.telekom.hu 0.0% 6.1 6.5 6.1 12.0 1.6
5. 81.183.0.163 0.0% 5.5 6.0 5.4 12.9 2.1
6. 81.183.2.165 0.0% 2.2 2.2 2.1 2.6 0.1
7. gi3-15.c6509-core-1.atw.hu 0.0% 3.5 3.7 3.3 6.8 0.9
8. po13-403.c3750g-access-3.atw.hu 0.0% 9.8 8.1 6.9 9.8 0.7
9. server5.megacp.com 0.0% 2.2 2.2 2.0 2.4 0.1
valamint egy T-Home optinet-ről:
3. 84.2.x.x 0.0% 5 4.8 5.0 4.8 5.3 0.2
4. tge0-2-0-4.er0-dataplex.net.tele 0.0% 5 5.0 4.6 3.7 5.5 0.8
5. tge0-2-0-7.core0-ip2.net.telekom 0.0% 5 10.2 10.2 9.3 11.5 0.8
6. tge4-2.osr1-istvan.net.telekom.h 0.0% 5 5.4 5.3 5.0 5.6 0.3
7. c-tge7-1.osr1-istvan.net.telekom 0.0% 5 7.5 10.2 7.5 13.6 2.8
8. 81.183.0.143 0.0% 5 8.7 17.6 7.8 52.8 19.7
9. 81.183.2.165 0.0% 5 3.9 4.6 3.5 5.5 0.8
10. gi3-14.c6509-core-2.atw.hu 0.0% 4 7.7 8.6 7.7 9.3 0.7
11. po23-404.c3750g-access-3.atw.hu 0.0% 4 6.9 7.2 6.9 7.6 0.4
12. server5.megacp.com 0.0% 4 9.1 9.4 9.1 9.7 0.2
Igen, aktuális még, egy perce megint lerohadt a T-Mobile felől is.
__
http://fodi.be
Erdekes, a traceroute megdoglik, ugyanakkor az eatweb.net bejon (web & app cooking since 2008), valamint a gep is pingik.
--
Az imént néztem, még mindig rossz. Traceroute ugyanott meghal. Ilyenkor van még valami cache törlés féle (DNS flush megvolt), amit megcsinláhat az ember? Vagy írni kéne valakinek? Ha igen kinek? Telekom? Megacp? Wtf? :)
__
http://fodi.be
"Traceroute ugyanott meghal."
Biztos jól értelmezed a jelenséget, és jó következtetést vonsz le? A linuxos-unixos traceroute alapesetben UDP-t küld növekvő portszámokra, a windowsos pedig ICMP Echo Requestet. Általában tűzfalazási okokra visszavezethetően az UDP-t csendben eldobják, az ICMP-re viszont válaszolnak. De lehet traceroute-ot indítani TCP-n is, az pedig állandó célportra indul. Ha megnézed a fentebbi hozzászólásokat, nem tudatosan, de erre próbálnak rávezetni. PunishR mondja, hogy a TCP-s traceroute a 80-as portra eljut a célig. Chas írja, hogy az mtr, ami ICMP-t használ, eljut a célig. Ugyanígy wpeople is sikeres mtr kimetet másolt be. És hrgy84 pedig mutatja, hogy az UDP-t szűrik.
Dataplexből:
Láthatod, hogy a web által használt TCP porton, valamint ICMP-n szépen megy.
De kipróbáltam böngészőből is. Magyar Telekom ADSL-ről (a 195.228.218.0-195.228.218.255 tartományból kaptam IP-t; 195.228.0.0/16) probléma nélkül bejön az oldal. T-Mobile mobilnetről (a 194.176.226.0-194.176.227.255 tartományból kaptam; 194.176.224.0/19) is tökéletes.
"miután az ügyfél kiiktatott egy routert és a PC-jét közvetlenül a kábelmodemre csatlakoztatta. A routert visszatéve a probléma ismét előjött, tehát nem csak egybeesés volt valami tök más problémával."
Ha a traceroute-nál jött elő, akkor a routeren rossz tűzfalazás vagy állapotkövetés. Ha a weboldalnál, akkor a routeren rossz MSS igazítás. De ezt láthatod, hogy ez azon a végponton helyi probléma, és nem a szerevered környékén vagy a szolgáltatón múlott, hiszen a router kiiktatásával helyreállt a rendes kommunikáció.
Ha valóban problémát észlelsz, akkor nézz rendes traceroute-ot ICMP-n és TCP-n is, ha megy, de a weboldal mégsem jön be, akkor pedig legjobb barát a tcpdump vagy a WireShark, hogy lásd, mi is akad el.
"Ugyanakkor többek között ez a szolgáltatás remekül látja"
Ezt nem sikerült linkelned.
"ez úgyszintén."
Ez TCP/80-ra generál forgalmat, méghozzá a http://eatweb.net/ URL-re küld HEAD-et.
" Ilyenkor van még valami cache törlés féle (DNS flush megvolt)"
Hogy mi?! IP-re cache? A DNS szintén irreleváns a ping és a traceroute sikerességének szempontjából - a cél host nevének feloldását kivéve.
"Vagy írni kéne valakinek? Ha igen kinek? Telekom? Megacp?"
Ez természetesen attól függ, hogy mit derítesz ki, hogy kb. hol lehet a hiba. A levélhez pedig mellékeld a hibára rámutató releváns hálózati kimeneteket, célszerűen egy másik szolgáltatótól is megpróbálva, természetesen ugyanolyan paraméterekkel. Mint említettem, az UDP-s traceroute önmagában ehhez kevés.
Most kanyarodjunk vissza a nyitó hozzászóláshoz.
"a traceroute pedig mindkét esetben a po13-403.c3750g-access-3.atw.hu szervernél taknyol el."
Ezt megbeszéltük, hogy nem feltétlen baj.
"Pingre nem válaszol"
Ez viszont érdekes lehet, mert látszólag pingelhető:
#
Összefoglalva: járj utána a jelenségnek részletesebben.
Köszönöm a választ és a javaslatokat. A topikban javítottam az "ez a szolgáltatás" linket, a többinek utánanézek és írni fogom. Még egyszer köszi!
__
http://fodi.be
Itt pedig lehet pingelni, ez ugye egyértelműen ICMP, lehet mtr-t futtatni, ez szintén ICMP-s. Ezek vannak alapesetben kiválasztva, tehát ha a traceroute-ot nem pipáltad be, akkor mindegyikre sikeres kimenetet kaptál. Továbbá lehet traceroute-olni (UDP), ez pedig innen is ugyanazt az eredményt adja, mint amit a saját hozzáféréseidről, illetve bárhonnan tapasztalsz. Az UDP-t szűrik, és nem válaszolnak rá, így az UDP alapú traceroute timeoutos lesz.
Az eredeti posztot frissítettem további részletekkel és az Általad említett TCP/ICMP traceroute-ok kimenetével.
__
http://fodi.be
"FodiMac:~ fodi$ traceroute -f 4 -m 9 -p 80 server5.megacp.com"
Mivel kihagytad a -T ill. annak megfelelő opciót, így ez is UDP-n ment.
Tehát az első emiatt biztos sikertelen, a másodiknak illene mennie az utolsó pinggel együtt, a harmadik UDP-s, ezért várható volt a timeout.
man traceroute:
Tedd bele a -P opciót TCP-vel (és úgy tűnik, OS X alatt a BUG alatt írtak alapján a szép TCP-s traceroute-hoz kellene egy tcpdump is).
Ha a TCP-s traceroute problémás lenne, együtt nézz meg egy telnetet a 80-as portra.
Nézzük meg a rendes TCP-s eredményt is. Ha nem megy, azaz annál is timeoutot kapsz, akkor a próbáld megkeresni a MegaCP-t, elképzelhető, hogy pl. támadás miatt kitiltottak egy-két IP tartományt, amibe éppen beleesel. Ezt támasztaná alá az ICMP-s timeout is.
FodiMac:~ fodi$ traceroute -f 4 -m 9 -p 80 -P TCP server5.megacp.com
traceroute to server5.megacp.com (5.56.32.1), 9 hops max, 64 byte packets
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
FodiMac:~ fodi$ telnet server5.megacp.com
Trying 5.56.32.1...
telnet: connect to address 5.56.32.1: Operation timed out
telnet: Unable to connect to remote host
Ebből email lesz. Újfent köszönöm a felhomályosítást! :)
__
http://fodi.be
Az miért gond ha nem tudsz telnetelni? A telnet ilyenkor alap porton próbálkozik. Ha esetleg a 80-as portot nézted volna, az más lenne :)
Jogos, elfelejtettem. Próbáltam
telnet server5.megacp.com 80-nal is, ugyanez az eredmény.__
http://fodi.be
Szintén Bcs, szintén T, szintén Cisco3925 modem. Véletlenszerűen néztem ma rá párszor. Eddig mindig ment.
Köszönöm. Felmerült bennem az is, hogy a modemünkkel lesz valami gebasz. Lehet, hogy teljesen unrelated, de csinált mostanában más típusú hülyeséget is (port forward szabályokkal kapcsolatban tapasztaltam anomáliákat). Csapatok egy hard resetet még ma és megnézem fennáll-e a probléma azután is.
UPDATE: factory reset kész, nincs változás.
__
http://fodi.be
Valami T-mobilos kapcsolatról is írtál. Annak túl sok köze nincs ehhez a modemhez ha jól gondolom. Telefonon szoktad tesztelni, vagy továbbosztod a gépre a netet?
Így igaz, volt T-Mobile felől sem lehett kapcsolódni rá, de az azóta ez a probléma megszűnt. Egyébként telefonról megosztva (wifi tethering) próbálkoztam vele anno, mikor nem volt elérhető onnan sem (helyesebben néha elérhető volt, néha nem).
__
http://fodi.be
(dupla)
Mindenkinek köszönöm a hozzászólásokat, a probléma megoldódott (részletek a nyitóban).
__
http://fodi.be