Fórumok
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
Hozzászólások
"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? :)
Nem teljesen értem, hogy mi a gondod a megközelítésemmel.
Távolról belépve elérem a linuxos gépet. Ezen tudok ezt-azt futtatni. Első körben megnéztem, hogy elérem-e a windows-os gépet. A válasz az volt, hogy nem.
Mit kellett volna tennem?
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.
Ne haragudj, nem értem, mire gondolsz.
192.168.2.1 a linuxos gép eth2 interfésze, nem átjáró.
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.
Itt a /etc/network/interfaces idevágó része:
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.
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.
Nincs tuzfal a Windowson, ami miatt ICMP Destination Unreachable uzenetet kuld vissza?
--
L
Fogalmam sincs, mi van azon a gépen. Nincs hozzáférésem, sose volt.
Azt ugy latom a forrasgép generálta. Ami egyébként ugy szokott: az utolsó router, ami most a host maga. Különben admin prohibited lenne inkább.
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
Persze, meg lehet oldani, csak egyrészt nem szoktak ilyet end hoston (főleg nem egy windows tűzfal). Ha rapillantasz az rfcre, akkor ott le is van irva, hogy a host unreschable az a gatewaytől jön.
másrészt fent látszik, hogy from 192.168.2.1.
Isten tudja, mit csinal a Windows tuzfala. Amugy meg:
192.168.2.1 a linuxos gép eth2 interfésze, nem átjáró
--
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.
Valoszinuleg figyelmetlen voltam, igazad van.
--
L