Dotaz: Server není z některých PC dosažitelný

[Zorkenlide]

Dobrý den,

snažím se vyřešit problém se serverem. Na stroji běží debian squeeze. Někteří uživatelé se nemohou na server připojit (zobrazit stránku, dokonce ani pingnout).

Z ankety jsem zjistil, že všichni tito uživatelé používají Windows XP (Některým se však jde připojit z s XPčky).

Zde jsou dva MTR logy ze serveru a na server.

Windows XP to server: http://pastebin.ca/2149604 Server to Windows XP: http://pastebin.ca/2149605

Byl bych vděčný za každou pomoc, kterou byste byli ochotní poskytnout. Nemám sebemenší tušení, kde může být chyba.

Děkuji, Martin

---

---

Odpovědi

[Filip Jirsák]

Ten server je někde v internetu, nebo je server i klienti v nějaké společné např. firemní síti? DNS název se překládá správně?

[Zorkenlide]

V internetu. DNS se u těch, kterým to nejde, nepřekládá - nejde ani ping na IP.

[Filip Jirsák]

DNS se u těch, kterým to nejde, nepřekládá - nejde ani ping na IP.

Tj. nefunguje tam ani překlad DNS názvu, ani nejde pingnout přímo na IP adresu? Je nějaká souvislost mezi tím serverem a DNS serverem – třeba že by pro danou doménu byl jen jeden DNS server a byl umístěn ve stejné síti nebo dokonce na stejné IP adrese, na jaké je server? Nemůže být problém u klientů, že by je blokoval jejich firewall?

[trash]

Odpovim za kolegu : Preklad DNS jsme nezkouseli protoze zadavame rovnou IP. Preklad funguje podle me bez problemu ale nezakouseli jsme. Vysledek by podle me byl ze to sice prelozi, ale pozadavek nedojde k serveru. Firewall a ostatni veci co by to kazily jsou samozrejme vypnuty.

[Filip Jirsák]

Chtělo by to použít traceroute a zjistit, kde se pakety ztrácí.

[Zorkenlide]

To už jsme použili, odkazy:

Windows XP to server: http://pastebin.ca/2149604 Server to Windows XP: http://pastebin.ca/2149605

[Filip Jirsák]

http://pastebin.ca/2149604 podle mne není výstup z traceroute, aspoň to tak nedokážu interpretovat. Každopádně se zdá, že cesta ze serveru ke klientovi je průchozí.

[Zorkenlide]

Cesta k problémovému klientovi:

 1  static.193.2.9.5.clients.your-server.de (5.9.2.193)  1.287 ms  1.276 ms  1.310 ms
 2  hos-tr1.juniper1.rz16.hetzner.de (213.239.222.65)  0.180 ms  0.189 ms hos-tr2.juniper1.rz16.hetzner.de (213.239.222.97)  0.184 ms
 3  hos-bb1.juniper4.ffm.hetzner.de (213.239.240.230)  4.837 ms  4.814 ms  4.818 ms
 4  tengigabitethernet9-4.ar3.fra3.gblx.net (207.138.95.9)  19.414 ms  19.524 ms  19.385 ms
 5  po2-20G.ar4.FRA3.gblx.net (67.16.133.34)  19.517 ms  19.677 ms  19.616 ms
 6  de-fra01a-ri2-xe-4-3-0.aorta.net (213.46.179.117)  5.050 ms  5.148 ms  5.141 ms
 7  84.116.133.105 (84.116.133.105)  6.158 ms de-fra03a-rd1-xe-1-1-0.aorta.net (213.46.179.45)  6.173 ms 84.116.133.105 (84.116.133.105)  6.171 ms
 8  cz-prg01a-ra4-xe-4-3-0.aorta.net (213.46.160.66)  28.766 ms  13.324 ms 84.116.135.6 (84.116.135.6)  74.946 ms
 9  ip-81-27-202-52.net.upcbroadband.cz (81.27.202.52)  13.943 ms  13.979 ms ip-81-27-202-53.net.upcbroadband.cz (81.27.202.53)  13.946 ms
10  ip-81-27-204-125.net.upcbroadband.cz (81.27.204.125)  14.151 ms  14.007 ms  14.035 ms
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

[trash]

tracert z problemoveho XP zde : http://fisa11.rajce.idnes.cz/Plocha#trping1.jpg

[Filip Jirsák]

To vypadá na nějaký problém u toho klienta… Někam jinam (třeba Seznam.cz) pingnout může?

[trash]

Urcite, vsechno ostatni bezi normalne :)

[Filip Jirsák]

Opravdu tam nemá on nebo jeho ISP firewall?

[trash]

Ne , zkouseli jsem pod ruznymi ISP z cele republiky - testovali to primo klienti co maji XP - nekterym to jde nejakym ne (ten antivir je u nich mozny, protoze jim do PC nevidim). Ale ohledne antiviru testoval jsem to primo ja se svymi XP a vsechno co by to mohlo blokovat jsem mel vypnuto a stejne to neslo.

[Filip Jirsák]

ping a traceroute na jiné servery funguje? Pokud na traceroute neodpoví ani první hop, jako ve výpisu výše, tipoval bych, že spíš ne. A pak to musí být něco v počítači klienta nebo u jeho ISP. Nespoléhal bych na to, že jiné weby jim normálně fungují -- abyste se nepokoušel problémy s vaším serverem odhalit pomocí pingu, který (třeba z jiného důvodu) také nefunguje.

[lertimir]

To je určitě problém u toho klienta. Jednak jaký má výpis traceroute na třeba seznam nebo jiný dostupný server (odpovídá první router?) a jaký je výpis netstat -r který dá routovací tabulku. Třeba tam má nějaký špatný záznam.

[DK]

u stejneho ISP nejsou?

[Zorkenlide]

To nevíme, ale doposud neměli s připojením na naše ostatní servery (debian lenny) problém.

[DK]

takze z naprosto stejne site se to pripoji debian->debian, ale ne windows->debian ?

[Zorkenlide]

Servery nejsou pod stejnou sítí, jsou na sobě nezávislé.

[DK]

ano, to uz jsem z toho traceroute pochopil, ale kdyz v siti, ze ktere ten pristup nefunguje, zapojite masinu s debianem, pujde to, nebo ne? (jinak on traceroute se serveru na klienta je celkem nanic, pokud je za natem, udelejte to naopak - "tracert ip_serveru" ve windows)

[Zorkenlide]

Zapojení nové mašiny v této síti bohužel nemůžeme vyzkoušet.

[mozog]

Co rika tcpdump na serveru? Prichazi tam pakety od uzivatelu s WXP?

[Zorkenlide]

Teď jsem to zkusil, pakety od problémových uživatelů nepřijdou ani do tcpdumpu.

[Honza]

A neopakuje se nahodou u UPC zase nejaky problem s peeringem? To uz tu jednou bylo ...

[Zorkenlide]

Nevím jestli to byl dlouhodobý problém, ale tohle trvá již 5 dní.

[Lazar]

Zkusil bych z problémového klienta příkaz tracert s povoleným větším počtem hopů TTL(-h xx) a bez zpětného DNS resolvingu (-d). Standardně to snad tracert zkouší s max. 30 hopy, pro zjištění zacyklení na cestě, či špatného routingu by to chtělo použít prokazatelně dostatečně vysoký TTL. http://support.microsoft.com/kb/314868

[Petr Šobáň]

Ještě můžete skusit použít malé MTU - Párkrát když blb internet (ISP) tak nechtěly prolézt velké pakety, malé prošly. (Problém byl tehdy u ISP velké pakety zahodil a neposlal správu že třeba posílat menší - chyba na HW u ISP)

[lertimir]

ping posílá 32 bytové pakety (tam už jít dolů nejde, overhead hlaviček je skoro 100% dat)

[Zorkenlide]

Začínám být zoufalý. Pronajmuli jsme si server u hetzner.de s debianem squeeze a tento problém trvá od té doby, co nám tuto instalaci propůjčili (než jsme do ní vůbec začli cokoliv instalovat). Pokud jim napíšu na podporu, získávám odpovědi jako:

we can reach your server without problems and we do not have experienced about this problems from other customers?

či "problém musí být u klienta". Není však přece možné, abych spustil server, na který se 10% mých klientů nedostane.

Čím dál více se snažíme tento problém řešit, zdá se mi to jako jejich chyba.

[Petr Šobáň]

Jejich chyba to být nemusí - může být někde na trase...

[lertimir]

Jak jsem psal už výše. Vypadá to na problém u klienta. Já se na váš server také dotrasuji bez problémů. Co dává na klientu netstat -r? Tipuji, že by mohl mít špatnou položku v routovací tabulce. Jak funguje na klientu tracert www.seznam.cz nebo kamkoliv jinam. Odpovídají první routery? Cesta by měly být stejná jako na váš server dokud se klient přes ISP nedostane na backbone. Má klient (jeho ISP) síťové oddělení? S těmi by se dalo bavit o směrování.

[Zorkenlide]

Microsoft Windows XP [Verze 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\A>netstat -r

Směrovací tabulka =========================================================================== Seznam rozhraní 0x1 ........................... MS TCP Loopback interface 0x2 ...7a 79 05 72 d4 3d ...... Hamachi Network Interface - Sunbelt Software Fir ewall NDIS IM Filter Miniport 0x3 ...f4 ec 38 80 70 1d ...... TP-LINK Gigabit PCI Network Adapter - Packet Scheduler Miniport 0x4 ...00 0e a6 32 dd 54 ...... Realtek RTL8139 Family PCI Fast Ethernet NIC - P acket Scheduler Miniport 0x10006 ...00 02 72 d1 ae c8 ...... Bluetooth PAN Network Adapter - Packet Sched uler Miniport =========================================================================== =========================================================================== Aktivní směrování: Cíl v síti Síťová maska Brána Rozhraní Metrika 0.0.0.0 0.0.0.0 192.168.2.1 192.168.2.2 20 5.0.0.0 255.0.0.0 5.114.212.61 5.114.212.61 20 5.114.212.61 255.255.255.255 127.0.0.1 127.0.0.1 20 5.255.255.255 255.255.255.255 5.114.212.61 5.114.212.61 20 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 192.168.2.0 255.255.255.0 192.168.2.2 192.168.2.2 20 192.168.2.2 255.255.255.255 127.0.0.1 127.0.0.1 20 192.168.2.255 255.255.255.255 192.168.2.2 192.168.2.2 20 224.0.0.0 240.0.0.0 5.114.212.61 5.114.212.61 20 224.0.0.0 240.0.0.0 192.168.2.2 192.168.2.2 20 255.255.255.255 255.255.255.255 5.114.212.61 10006 1 255.255.255.255 255.255.255.255 5.114.212.61 4 1 255.255.255.255 255.255.255.255 5.114.212.61 5.114.212.61 1 255.255.255.255 255.255.255.255 192.168.2.2 192.168.2.2 1 Výchozí brána: 192.168.2.1 =========================================================================== Trvalé trasy: Žádné

C:\Documents and Settings\A>

[lertimir]

Takhle to přečíst nejde, použjte prostředí pre.

[Zorkenlide]

Microsoft Windows XP [Verze 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\A>netstat -r

Směrovací tabulka
===========================================================================
Seznam rozhraní
0x1 ........................... MS TCP Loopback interface
0x2 ...7a 79 05 72 d4 3d ...... Hamachi Network Interface - Sunbelt Software Fir
ewall NDIS IM Filter Miniport
0x3 ...f4 ec 38 80 70 1d ...... TP-LINK  Gigabit  PCI  Network  Adapter - Packet
Scheduler Miniport
0x4 ...00 0e a6 32 dd 54 ...... Realtek RTL8139 Family PCI Fast Ethernet NIC - P
acket Scheduler Miniport
0x10006 ...00 02 72 d1 ae c8 ...... Bluetooth PAN Network Adapter - Packet Sched
uler Miniport
===========================================================================
===========================================================================
Aktivní směrování:
       Cíl v síti     Síťová maska            Brána        Rozhraní  Metrika
          0.0.0.0          0.0.0.0      192.168.2.1     192.168.2.2       20
          5.0.0.0        255.0.0.0     5.114.212.61    5.114.212.61       20
     5.114.212.61  255.255.255.255        127.0.0.1       127.0.0.1       20
    5.255.255.255  255.255.255.255     5.114.212.61    5.114.212.61       20
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
      192.168.2.0    255.255.255.0      192.168.2.2     192.168.2.2       20
      192.168.2.2  255.255.255.255        127.0.0.1       127.0.0.1       20
    192.168.2.255  255.255.255.255      192.168.2.2     192.168.2.2       20
        224.0.0.0        240.0.0.0     5.114.212.61    5.114.212.61       20
        224.0.0.0        240.0.0.0      192.168.2.2     192.168.2.2       20
  255.255.255.255  255.255.255.255     5.114.212.61           10006       1
  255.255.255.255  255.255.255.255     5.114.212.61               4       1
  255.255.255.255  255.255.255.255     5.114.212.61    5.114.212.61       1
  255.255.255.255  255.255.255.255      192.168.2.2     192.168.2.2       1
Výchozí brána:       192.168.2.1
===========================================================================
Trvalé trasy:
  Žádné

C:\Documents and Settings\A>

[Zorkenlide]

Používá klient Hamachi? Ten si totiž pro sebe vyhrazuje 5.0.0.0/8 - a podle routovací tabulky tam evidentně nečo takového bude.

[MaxiKing]

No teď byste to měl vidět. Podle toho, co jste dal na rajče, je IP cílového serveru 5.9.2.194. Nicméně tato adresa zareaguje podle pravidla 2 ve Vaší tabulce a odejde do rozhraní 5.114.212.61 které má masku 0.255.255.255. To znamená přímý přístup do podsítě adresy A. Co to je nevím, mohu jen odhadnout že si tohle vytvořilo Hamachi. (Můžete to zjistit přes ipconfig) Takže místo normálního odroutování standardní cestou, paket vletí do virtuálního Hamachi rozhraní a tam se ztratí.

[Zorkenlide]

Nyní přišla odpověď přímo od Hetzneru, může to být i něco s UPC. Nejprve zkontroluji to hamachi u klienta.

Dear Client,

sorry for the delay.
We have checked you Logfiles and there is an asynchronous routing,
that is outside
from our network. We cant do anything you must contact the owner of
-----------------%<-----------------
10. ip-81-27-204-125.net.upcbroadban  0.0%  1347  130.9  16.0  13.9 157.7  12.9
-----------------%<-----------------

[Zorkenlide]

Velmi děkuji za odpověď, je to opravdu tím.

Problémový klient odinstaloval hamachi a restartoval PC a vše funguje jak na drátkách.

Problém je v IP adrese serveru - začíná na 5.*.*.* - 5.9.2.194. Sítě začínající pětkou jsou opravdu vyhrazené a pakety se ztrácí v těchto virtuálních hamachi sítích.

[George]

Síť 5/8 není žádná vyhrazená. Je to normální síť, kterou RIPE teď začlo přidělovat LIRům a to po skoro dvou letech debogonizace. LogMeIn by se za Hamachi a další mělo pověsit za koule do průvanu. Taky je chuťovka řešit "správce" kteří v zájmu "bezpečnosti" na firewallu dropují nepřiřazené prefixy, ale jaksi zapomínají na auktualizace.

[SPM]

Teď už je to jednodušší, IPv4 adresy jsou přiřazené všechny :)) (alespoň RIRům)

[Filip Jirsák]

Podle toho, co jste zatím napsal, je to chyba klienta – buď chybné routování, nebo restriktivní firewall. Vyzkoušejte ping/traceroute i na jiné servery, ať aspoň víte, zda jsou tyhle protokoly blokovány, nebo je můžete používat pro testování.

[Petr Šobáň]

Jenže ping může být zakázaný.....firewall, antivir, na routeru atd....

[Zorkenlide]

Nezobrazuje se jim ani http://5.9.2.194/ - It Works!

[Petr Šobáň]

Však nemusí - nemusí to projít.....

Co takhle na ten PC, NT vrazit live distribuci a skusit to - funguje to tak je to problém OS a né HW.

Potom třeba předělat - nastavit správně OS.

[trash]

Bez vysledku, pouzity prikaz tracert -h 100 -d 5.9.2.194

Výpis trasy k 5.9.2.194 s nejvýše 100 směrováními

1 * * * Vypršel časový limit žádosti. atd ....

[Peter]

nemas na klientoch eset smart security ? Obcas ke ho clovek nenastavi mu zacne riane je****t

[Zorkenlide]

Antiviry jsou určitě vypnuté, těmi to není.