[Fedora]Wel IP-resolving, geen Internet/Ping.

[Verwijderd]

Hallo,

Ik heb een bak met Fedora core 7 geinstalleerd, hierbij ben ik tegen het volgende probleem aangelopen:

Ik heb in de eerste instantie geen internet, wanneer ik nslookup uitvoer krijg ik keurig een reactie van de server met het IP adress van de opgevraagde hostname. Wanneer ik ping naar dezelfde hostname krijg ik geen reactie ( alle andere windows clients die op dezelfde DNS draaien kunnen dit wel ), Ook wanneer ik ping naar het rechtstreekse IP krijg ik geen reactie. Een traceroute laat ook niks dan *** zien.

Hier wat gegevens die je mogelijk zou willen zien:

Resolv.conf:

code:

nameserver 192.168.1.100

/etc/hosts:

code:

# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1       localhost.localdomain   localhost

::1     localhost6.localdomain6 localhost6

Resultaat van NSLookup:

code:

[root@localhost ~]# nslookup google.com
Server:         192.168.1.100
Address:        192.168.1.100#53

Name:   google.com
Address: 72.14.207.99
Name:   google.com
Address: 64.233.187.99
Name:   google.com
Address: 64.233.167.99

Resultaat van Netstat -nr:

code:

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth0
0.0.0.0         192.168.1.100   0.0.0.0         UG        0 0          0 eth0

Resultaat van IFCONFIG:

code:

[root@localhost ~]# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:19:DB:CB:5F:11
          inet addr:192.168.1.10  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::219:dbff:fecb:5f11/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3806 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6863 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:386577 (377.5 KiB)  TX bytes:1046432 (1021.9 KiB)
          Interrupt:21 Base address:0xe800

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:45 errors:0 dropped:0 overruns:0 frame:0
          TX packets:45 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:4952 (4.8 KiB)  TX bytes:4952 (4.8 KiB)

Dat zou toch wel voldoende moeten zijn
Heeft iemand enig idee wat er fout kan zijn met deze configuratie?

Bij voorbaat dank!

M.v.g.
J. van Vierzen

[deadinspace]

Verwijderd schreef op zondag 16 september 2007 @ 21:15:
Resultaat van Netstat -nr:

code:

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth0
0.0.0.0         192.168.1.100   0.0.0.0         UG        0 0          0 eth0

Hmm, ik vraag me af waarom hij een route heeft voor 169.254.0.0/16. Dat is de IPv4 link-local address range, dat zijn adressen die bijvoorbeeld gebruikt worden als computers geen adres kunnen krijgen via DHCP.

De routes zien er verder goed uit, en de output van ifconfig voor 192.168.1.1/24 ziet er ook goed uit. Maar het feit dat er een route is voor 169.254.0.0/16 suggereert ook dat eth0 een IP adres in die range moet hebben. Kun je eens de output van

ip a s

geven?

Voor de duidelijkheid, als je vanaf je Fedora bak 192.168.1.100 pingt, dan krijg je geen antwoord? En als je dat vanaf een andere machine op je netwerk doet wel?

Er zijn twee dingen die me zo verder te binnen schieten:

• Is er misschien een andere computer op het netwerk met hetzelfde IP adres (192.168.0.10) ?
• Misschien zit de firewall in de weg. Heb je iets aan firewall-gerelateerde instellingen veranderd?

[DeMoN]

Krijg je met een ping geen reactie d.m.v. timeouts of krijg je meldingen dat de doelhost niet gevonden kan worden?
En in aanvulling op deadin~1 boven mij, geef voor de zekerheid eens de output van iptables -L

[Verwijderd]

ip a s:

code:

[root@localhost ~]# ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:19:db:cb:5f:11 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.10/24 brd 192.168.1.255 scope global eth0
    inet6 fe80::219:dbff:fecb:5f11/64 scope link
       valid_lft forever preferred_lft forever

iptables:

code:

[root@localhost ~]# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Dit krijg ik als ik hem zo eens een minuutje laat pingen:

code:

[root@localhost ~]# ping www.google.com
PING www.l.google.com (66.249.93.99) 56(84) bytes of data.

--- www.l.google.com ping statistics ---
120 packets transmitted, 0 received, 100% packet loss, time 118999ms

Aangezien die geen timeout geeft abort ik het commando met CTRL+C, dan geeftie pas de ping statistics.

Enig idee?

[jpm.lensen]

Ik weet niet wat het precies betekend, maar de LOWER_UP uit je ip a s output komt op mij een beetje vreemd over. Misschien kun je daar even op googlen.

En kun je de dns wel pingen?

Ook geldt dat je de traceroute soms een tijdje moet laten lopen, omdat een aantal dozen er geen reactie op geven (bijv. switches, of uit veiligheids oogpunt).

Kun je ook eens proberen het IP van google.com te pingen?

[Verwijderd]

Ip adres van google is wat ik standaard ping, die geeft een timeout na honderden ping requests verstuurd te hebben.

Uiteraard kan ik mn dns pingen, ik kan zelfs een NSLookup request opzetten =\
Verder denk ik niet dat LOWER_UP iets raars zal zijn, het lijkt mij simpelweg op een algement ongebonden referentie naar je localhost "adapter".

[deadinspace]

J4zen, ik wil je vragen de replies die je krijgt wat beter te lezen
[quote]Verwijderd schreef op maandag 17 september 2007 @ 11:25:
Uiteraard kan ik mn dns pingen, ik kan zelfs een NSLookup request opzetten =[/q]
Ik vroeg ook al of je je DNS server kon pingen, en daar gaf je geen antwoord op. En je DNS server niet kunnen pingen maar wel DNS lookups kunnen maken is natuurlijk altijd mogelijk, al is het maar door een foute firewall rule.

En heb je al gekeken of er een andere machine met hetzelfde IP adres op je netwerk is?
En heb je al gekeken naar je firewall?

Verder denk ik niet dat LOWER_UP iets raars zal zijn, het lijkt mij simpelweg op een algement ongebonden referentie naar je localhost "adapter".

Die LOWER_UP flag (ik weet trouwens ook niet wat hij betekent) staat bij eth0, niet bij lo.


Aangezien je geen IP adres in 169.254.0.0/16 hebt zou je kunnen proberen die route te verwijderen met

ip r d 169.254.0.0/16

(of met een vergelijkbaar route commando). Die route zou voorzover ik begrijp niet uit moeten maken, maar het is iig te proberen.

[Verwijderd]

lol goed,

ik ken je nu iig verzekeren dat het geen firewall rule is, mn dns goed bereikbaar is, er geen andere client met hetzelfde IP is, mn gateway te bereiken is, en tot slot.. ik zelfs bestanden kan downloaden van een lokale webservers in mijn netwerk.

Maar, geen ping naar buiten en/of internet verbinding.

[ Voor 18% gewijzigd door Verwijderd op 17-09-2007 14:18 ]