mikor mondja, hogy destination host unreachable?

Hálózatok általános

Van két gép, tőlem messze. Az egyiken Linux fut, a másikon windows.
A két gép között ethernet kábel, switch, ethernet kábel az út (azt hiszem)
A Linuxos gépről nem tudom elérni a windows-os gépet, úgy tippelem, valami hálózati probléma lehet.

A kérdésem az, hogy pontosan mikor adja a linux az alábbi hibaüzeneteket: 


uwall:~# ping 192.168.2.109
PING 192.168.2.109 (192.168.2.109): 56 data bytes
64 bytes from 192.168.2.1: Destination Host Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst Data
 4  5  00 5400 ab06   0 0040  40  01 3fae 192.168.2.1  192.168.2.109
64 bytes from 192.168.2.1: Destination Host Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst Data
 4  5  00 5400 9907   0 0040  40  01 51ad 192.168.2.1  192.168.2.109
64 bytes from 192.168.2.1: Destination Host Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst Data
 4  5  00 5400 0608   0 0040  40  01 e4ac 192.168.2.1  192.168.2.109
^C--- 192.168.2.109 ping statistics ---
4 packets transmitted, 0 packets received, 100% packet loss
uwall:~# telnet 192.168.2.109 http
Trying 192.168.2.109...
telnet: Unable to connect to remote host: No route to host

Főleg a no route to host üzenet zavar, mert a routing táblában szerepel ez a subnet: 


uwall:~# ip route show
default via 192.168.1.21 dev eth0
10.8.0.0/24 via 10.8.0.2 dev tun0
10.8.0.2 dev tun0  proto kernel  scope link  src 10.8.0.1
10.8.2.0/24 via 10.8.0.2 dev tun0
10.8.3.0/24 via 10.8.0.2 dev tun0
10.8.5.0/24 via 10.8.0.2 dev tun0
192.168.0.0/24 dev eth1  proto kernel  scope link  src 192.168.0.22
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.9
192.168.2.0/24 dev eth2  proto kernel  scope link  src 192.168.2.1
192.168.5.0/24 dev eth3  proto kernel  scope link  src 192.168.5.1
  • 4225 megtekintés

( haspokember | 2017. 05. 25., cs – 12:49 )

"A két gép között ethernet kábel, switch, ethernet kábel az út (azt hiszem)"

Valamikor 20 evvel ezelott dolgoztam egy kis cegnel lotifuti mindeneskent. Az egyik kliens egy teniszklub volt, ahol az egyik epuletben levo nyomtatot szerettek volna elerni a masik epuletbol. Persze nem latta a nyomtatot a gep (raadasul ha jol emlekszem, ez meg talan Novell IPX-es halozat volt?), sehogy se birtam rajonni, mi baja.

Aztan megjott a szenior halozatos, kivezetett a keriteshez, rohogott egyet, majd ramutatott az oszlopra, ahol a kabelt vezettek... szepen feltekerve, a vege pedig a levegoben logott. Neha ennyire egyszeru a megoldas :)

Annyi a különbség, hogy ez a két gép hónapok (évek?) óta működött, szóval nem új telepítés.

A linuxos mii-tool szerint az eth2-nél link OK.
A helyszínen van egy srác, aki szerint az ethernet kábel a windows-os gépbe be van dugva.

Azt nem tudom, hogy a windows-os gépből induló kábel másik vége vajon a switch-be be van-e dugva, de korábban be volt.

Az azt hiszem arra vonatkozik, hogy nem tudom pontosan, hogy a switch-et használják ennek a két gépnek az összekötéséhez is, vagy esetleg ezek között egy dedikált cross ethernet kábel van, vagy valami másik hálózati eszköz, pl. egy egyszerű hub.

A lényeg az, hogy a két gép egy épületben van, és nem bonyolult közöttük a topológia.

Azt nem tudom, és arra utalt a kérdésem igazán, hogy vajon lehet-e tudni, milyen esetekben adja a linux az idézett hibaüzeneteket, és milyen esetekben mondana valami mást.
Hátha ki lehet zárni az üzenetek alapján pár hibalehetőséget.

"nem bonyolult közöttük a topológia" vs "Azt nem tudom, hogy a windows-os gépből induló kábel másik vége vajon a switch-be be van-e dugva" & "nem tudom pontosan, hogy a switch-et használják ennek a két gépnek az összekötéséhez is..."

Foglaljuk ossze: halvany lila gozod sincs, mi van bedugva es hova. Amig ezt nem tudod, hogyan akarsz barmilyen felsobb retegben hibat keresni?

Szerintem a takaritono volt a bunos, porszivozas kozben kihuzta az egyik kabelt. Vagy egy rendszergazda kollega "tette rendbe" a kabeleket, esetleg az egyik juzer huzta ki a kabelt a szekrenyben, hogy a sajat laptopjat feldugja a netre. (Ez mind konkretan megtortent, velem (is).)

"arra utalt a kérdésem igazán, hogy vajon lehet-e tudni, milyen esetekben adja a linux az idézett hibaüzeneteket" - erre valaszoltam viragnyelven. Nem beszelsz pipacsul? :)

( Chas | 2017. 05. 25., cs – 13:53 )

Szia!
Mivel a kapcsolatnál átjárónak a 192.168.2.1 van megadva, a gép amit pingelsz a 192.168.2.109 így az én feltételezésem az, hogy van a rendszerben egy router is. Ha nincs, akkor ne GW-t adj meg, csak az interface számát. Ebben az esetben tudni fogja, hogy a tartomány melyik kártyán érhető el, és nem keres átjárót. Így keresi az átjárót, viszont az nincs, így azt mondja, hogy nincs útvonal.
Szerk:
Amúgy valószínűleg ugyanebből az okból kifolyólag a windows sem fog rálátni a linuxra, mivel a linux ha válaszolni akar, akkor is az átjárónak akarja küldeni a csomagot.

Mivel a kapcsolatnál átjárónak a 192.168.2.1 van megadva, a gép amit pingelsz a 192.168.2.109 így az én feltételezésem az, hogy van a rendszerben egy router is

Ne haragudj, nem értem, mire gondolsz.

192.168.2.1 a linuxos gép eth2 interfésze, nem átjáró.

Ha nincs, akkor ne GW-t adj meg, csak az interface számát. Ebben az esetben tudni fogja, hogy a tartomány melyik kártyán érhető el, és nem keres átjárót.

A 192.168.2-es subnetet az eth2-n keresztül éri el. A routing táblához igazából nem adtam meg semmit, azt a kernel vagy a network alrendszerbe tartozó programok generálták. Mintenesetre szerintem az eredmény az, hogy egy interfész száma van megadva, nem átjáró. Szóval tudnia kéne, hogy melyik kártyán érhető el. 


192.168.2.0/24 dev eth2  proto kernel  scope link  src 192.168.2.1

Itt a /etc/network/interfaces idevágó része: 


auto eth2
iface eth2 inet static
        address 192.168.2.1
        netmask 255.255.255.0

A no route to host félrevezető, nem azt jelenti, hogy nincs route bejegyzés, hanem hogy a konkrét hostot nem érte el, a telnet hülye. A ping meg is mondja, hogy destination host unreachable, jó eséllyel valami lentebbi layerben van gebasz (vagy valami tűzfal). Elsőre nézz egy arp -ot, hogy egyáltalán megvan-e a maccíme (nyilván, nézheted tcpdumppal is, hogy az arp who-hasre válaszol-e valaki, és ha igen ki), ha nem akkor valami kábelswitch probléma lesz, ha megvan, akkor nagyobb eséllyel vagy a .109en levő ip konfiguráció, vagy a tűzfal lesz a ludas.

Igen, gyanítottam, hogy ez lehet. Csak abban reménykedtem, hogy nem kell mindent átnézni, kábelt, switch-et, hálókártyákat, Windows beállításokat, zavaró tényezőket.

De úgy látom, nem sikerült érdemben csökkenteni a hibalehetőségek számát.

Nincs meg a MAC address. 


uwall:~# arp
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.2.109                    (incomplete)                              eth2

Aha, ez tipikusan olyasmi, ami már layer2-n nem oké. Ha tűzfal para lenne, akkor mac még lenne. Első körben én megnézném, hogy az a windows bármi mást elér-e egyébként, megy-e rajta a hálózat. Ha nem, akkor nyilván ott javítunk. Ha igen, akkor az ip konfigurációjánál azért azt megnézném, hogy stimmel el a beállítás (nincs-e véletlen mondjuk egy rossz mask rajta, ami miatt nem érzi magát felkenve arra, hogy válaszoljon az arpra). Ha ez is pipa, akkor nincs más hátra, mint valami undormány switching problémát keresni.

És ilyen debugnál imho a mindkétoldali tcpdump bámulás a legjobb módszer a hiba elhatárolásához.

( lberes (nem ellenőrzött) | 2017. 05. 25., cs – 15:41 )

Nincs tuzfal a Windowson, ami miatt ICMP Destination Unreachable uzenetet kuld vissza?

--
L

Aszondja:

64 bytes from 192.168.0.131: icmp_seq=15 ttl=64 time=0.111 ms
From 192.168.0.131 icmp_seq=16 Destination Host Unreachable
From 192.168.0.131 icmp_seq=17 Destination Host Unreachable

Mindossze ennyit csinaltam:

# iptables -A INPUT -p icmp --icmp-type echo-request -j REJECT --reject-with icmp-host-unreachable

--
L

küzdhetsz még :)

"isten tudja, mit csinal a Windows tuzfala."

Valóban isten tudja, de olyat, ami nem felel meg az RFCnek, alapból ritkán :) Úgyhogy maradjunk annál, hogy Occam borotvája alapján nem ezt kezdjük túrni.

"192.168.2.1 a linuxos gép eth2 interfésze, nem átjáró"
Bónusz kérdés következik: a 192.168.2.1/24es gépről a 192.168.2.109 felé szerinted ki az átjáró? Elárulom, a host saját maga, mivel connected network, ezért ő maga fogja generálni a dest host unreachable üzenetet.

Szóval szerintem engedd ezt el. Tudjuk, hogy nincs ott a mac cím az arp táblában, ami azt jelenti, hogy a windows tűzfal nem csinált semmit, mivel nem tudtak layer3-on beszélni egymással, tudjuk, hogy ennek megfelelően a dest host unreachablet a host maga generálta, mivel oda van írva, és tudjuk, hogy a hostról dest-host-unreachablet küldeni nem rfc kompatibilis. Ezek után kaparj még nyugodtan, hogy biztos a windows tűzfal, okosnak fogsz tűnni :) De inkább ne vidd be a kérdezőt az erdőbe.