lokale IP nicht korrekt aufgelöst

Einrichten des lokalen Netzes, Verbindung zu anderen Computern und Diensten.
Antworten
MoonKid
Beiträge: 513
Registriert: 12.03.2012 22:36:43

lokale IP nicht korrekt aufgelöst

Beitrag von MoonKid » 12.07.2017 21:16:22

Schaut euch bitte mal das Bild an.
Bild

Im oberen Bereich sieht man einen Teil aus der FritzBox-Oberfläche. Die IP (*.24) von SPARKY ist hier besonders relevant.
Pinge ich SPARKY aber an, wird die IP nach *.39 aufgelöst. Im gesamten lokalen Netz existiert kein Gerät mit dieser IP. Alle Geräte haben eine feste IP (FritzBox-Einstellung: "immer die gleiche IP vergeben").

Beim Aufruf von SSH wird sparky aber scheinbar korrekt aufgelöst.

Jetzt bin ich völlig verwirrt.
1. Warum funktioniert ping nicht und ssh ja?
2. Warum ist da überhaupt eine "falsche" IP?

EDIT:
showmount sparky -e löst den Namen scheinbar auch korrekt auf. Also vielleicht ein ping-spezifisches Problem?

Benutzeravatar
Wolf2000
Beiträge: 52
Registriert: 08.07.2017 08:19:58
Lizenz eigener Beiträge: MIT Lizenz
Kontaktdaten:

Re: lokale IP nicht korrekt aufgelöst

Beitrag von Wolf2000 » 12.07.2017 21:58:38

Hast du im interface dns-nameservers eingetragen

Bei mir:
The loopback network interface
auto lo
iface lo inet loopback

# eth0 network interface
auto eth0
allow-hotplug eth0
iface eth0 inet static
address 192.168.1.5
gateway 192.168.1.1
netmask 255.255.255.0
post-up /sbin/ifconfig $IFACE mtu 1500
dns-nameservers 192.168.1.1
iface eth0 inet6 manual
pre-down ip -6 addr flush dev $IFACE

Sv3n
Beiträge: 264
Registriert: 22.07.2013 06:37:52
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: ZH

Re: lokale IP nicht korrekt aufgelöst

Beitrag von Sv3n » 12.07.2017 22:06:16

Schau doch mal nach welche IP "sparky" bekommen hat. Nicht an der FritzBox, sondern bei sparky Rechner selber.

BenutzerGa4gooPh

Re: lokale IP nicht korrekt aufgelöst

Beitrag von BenutzerGa4gooPh » 13.07.2017 15:29:59

Clever wäre gewesen, nach der "falschen" Namensaufloesung und nach Test des ssh-Zugangs mal direkt auf die IPs .39 und .24 zu pingen oder zu "telnetten". (*) :wink:
Sieht so aus, als würde sparky, derzeit mal auf .39, zwar ssh, aber kein icmp/echo/echo-reply zulassen. Gründe sind in installierten Diensten oder iptables von .39 - wer immer das auch ist - zu finden. (FW/Router scheidet aus, da gleiches Netz. Transparente FWs sind privat ungebräuchlich.) Für ssh hat ja wohl die Namensauflösung sparky -> .39 funktioniert.

Wie sparky nun zu einer ungewollten Adresse kommt, musst du schon selbst herausfinden. Z. B.
Sv3n hat geschrieben: ↑ zum Beitrag ↑
12.07.2017 22:06:16
Schau doch mal nach welche IP "sparky" bekommen hat. Nicht an der FritzBox, sondern bei sparky Rechner selber.
... evtl. IPs für Server, die erreichbar sein sollen, im Server selber einstellen. Namensauflösung kann man trotzdem (auch auf Router) machen. Dann funktioniert das LAN (ohne DNS) auch bei ausgeschaltetem/defektem Router bzw. dessen DHCP-Server und bei Wechsel der Netzwerkkarte. (MAC-Änderung und das war es für die DHCP-Reservation oder infinite Lease im Router.)
Natürlich muss man dazu den DHCP-Pool einschränken. Bis .50 in privat ueblichen /24-Netzen kann man durchaus für fixe IPs (Server und Router-IFs) freilassen.

Ist natürlich bequem, alle Adressen schön uebersichtlich zentral per DHCP und Reservations zu verwalten. Klappt auch - wenn man es richtig macht. Also mit Reservations. Unendliche Lease-Times sollte man besser nicht nutzen. Was passiert nach Stromausfall des Routers? Namensauflösung mit geänderten IPs klappt - aber nur, wenn der DNS auch DHCP-Hostnamen übernimmt. Hat m. E. MS erfunden.

Man sollte tunlichst vermeiden, 2 aktive DHCP-Server in einem LAN zu haben.

PS auch für lernwillige Mitleser:
(*) Mit telnet kann man sehr einfach einzelne Ports (und Namensauflösung) testen, auch wenn ICMP/ping/echo gesperrt: https://wiki.archlinux.de/title/Telnet

nepos
Beiträge: 5238
Registriert: 05.01.2005 10:08:12

Re: lokale IP nicht korrekt aufgelöst

Beitrag von nepos » 13.07.2017 17:08:19

Nur so am Rande, aber wenn SSH da eine andere IP als z.B. ping nimmt, dann kann das auch über eine entsprechende Einstellung in ~/.ssh/config passieren.

Antworten