[Megoldva] Magyar Telekom felől elérhetetlen Megacp?

Közösségi kerekasztal

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).

  • 8521 megtekintés

( PunishR v | 2013. 04. 03., sze – 09:30 )

tcptraceroute eatweb.net 80 lefut és curl eatweb.net is DP-ből nézve.

( Chas | 2013. 04. 03., sze – 09:31 )

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.

( wpeople v | 2013. 04. 03., sze – 10:02 )

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

( hrgy84 | 2013. 04. 03., sze – 12:37 )

Erdekes, a traceroute megdoglik, ugyanakkor az eatweb.net bejon (web & app cooking since 2008), valamint a gep is pingik. 


traceroute to server5.megacp.com (5.56.32.1), 30 hops max, 60 byte packets
 1  192.168.2.1 (192.168.2.1)  1.628 ms  1.299 ms  6.339 ms
 2  rsr1-ferenc.net.telekom.hu (145.236.224.102)  25.143 ms  26.336 ms  28.151 ms
 3  fogl.er-osr-ferenc.net.telekom.hu.1.84.in-addr.arpa (84.1.85.18)  30.517 ms  32.328 ms  36.801 ms
 4  tge8-3.osr0-ferenc.net.telekom.hu (84.1.70.144)  40.331 ms  42.089 ms  42.934 ms
 5  c-tge8-4.osr0-ferenc.net.telekom.hu (81.183.2.62)  47.505 ms  47.409 ms  48.752 ms
 6  81.183.0.145 (81.183.0.145)  51.072 ms 81.183.0.147 (81.183.0.147)  16.204 ms 81.183.0.145 (81.183.0.145)  17.660 ms
 7  81.183.2.165 (81.183.2.165)  16.363 ms  17.838 ms  22.447 ms
 8  gi3-2.c6509-core-1.atw.hu (88.151.96.218)  28.775 ms  28.710 ms gi3-15.c6509-core-1.atw.hu (88.151.96.142)  28.614 ms
 9  po13-403.c3750g-access-3.atw.hu (88.151.96.226)  30.838 ms  32.437 ms po23-404.c3750g-access-3.atw.hu (88.151.96.228)  34.619 ms
10  * * *

-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

( webmotion v | 2013. 04. 04., cs – 21:30 )

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: 


# traceroute -f 4 -m 9 server5.megacp.com
traceroute to server5.megacp.com (5.56.32.1), 9 hops max, 60 byte packets
 4  81.183.0.141 (81.183.0.141)  0.676 ms 81.183.0.143 (81.183.0.143)  0.834 ms 81.183.0.147 (81.183.0.147)  0.847 ms
 5  81.183.2.165 (81.183.2.165)  1.213 ms  1.210 ms  1.176 ms
 6  gi3-15.c6509-core-1.atw.hu (88.151.96.142)  2.195 ms  2.183 ms gi3-14.c6509-core-2.atw.hu (88.151.96.216)  0.930 ms
 7  po23-404.c3750g-access-3.atw.hu (88.151.96.228)  3.698 ms po13-403.c3750g-access-3.atw.hu (88.151.96.226)  3.629 ms  4.069 ms
 8  * * *
 9  * * *
#

# traceroute -f 4 -m 9 -I server5.megacp.com
traceroute to server5.megacp.com (5.56.32.1), 9 hops max, 60 byte packets
 4  81.183.0.159 (81.183.0.159)  0.665 ms  0.686 ms  0.686 ms
 5  81.183.2.165 (81.183.2.165)  1.360 ms * *
 6  gi3-2.c6509-core-1.atw.hu (88.151.96.218)  1.473 ms  1.476 ms  1.706 ms
 7  po13-403.c3750g-access-3.atw.hu (88.151.96.226)  1.388 ms  1.664 ms  1.829 ms
 8  server5.megacp.com (5.56.32.1)  1.316 ms  1.452 ms  1.474 ms
#


# traceroute -f 4 -m 9 -T -p 80 server5.megacp.com
traceroute to server5.megacp.com (5.56.32.1), 9 hops max, 60 byte packets
 4  81.183.0.157 (81.183.0.157)  1.061 ms 81.183.0.161 (81.183.0.161)  1.077 ms 81.183.0.141 (81.183.0.141)  1.087 ms
 5  * * *
 6  gi3-14.c6509-core-2.atw.hu (88.151.96.216)  1.093 ms gi3-2.c6509-core-1.atw.hu (88.151.96.218)  3.600 ms gi3-14.c6509-core-2.atw.hu (88.151.96.216)  1.216 ms
 7  po13-403.c3750g-access-3.atw.hu (88.151.96.226)  77.354 ms  78.101 ms  77.620 ms
 8  server5.megacp.com (5.56.32.1)  1.644 ms  1.236 ms  1.828 ms
#

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ő: 

# ping -c 1 server5.megacp.com
PING server5.megacp.com (5.56.32.1) 56(84) bytes of data.
64 bytes from server5.megacp.com (5.56.32.1): icmp_req=1 ttl=56 time=1.07 ms

--- server5.megacp.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.071/1.071/1.071/0.000 ms

#

Összefoglalva: járj utána a jelenségnek részletesebben.

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.

"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:


-P proto
             Send packets of specified IP protocol. The currently supported protocols are: UDP , TCP , GRE
             and ICMP Other protocols may also be specified (either by name or by number), though traceroute
             does not implement any special knowledge of their packet formats. This option is useful for
             determining which router along a path may be blocking packets based on IP protocol number. But
             see BUGS below.


BUGS
     When using protocols other than UDP, functionality is reduced.  In particular, the last packet will
     often appear to be lost, because even though it reaches the destination host, there's no way to know
     that because no ICMP message is sent back.  In the TCP case, traceroute should listen for a RST from
     the destination host (or an intermediate router that's filtering packets), but this is not implemented
     yet.

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

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

( webmotion v | 2013. 04. 08., h – 12:28 )

Mindenkinek köszönöm a hozzászólásokat, a probléma megoldódott (részletek a nyitóban).
__
http://fodi.be