Debian 9.3 host niet bereikbaar na reset van de router

[Bl4ckviper]

Het is mijn nu al enkele keren opgevallen dat na het resetten van de router mijn nuc die debian 9.3 draait niet meer bereikbaar is. Na een herstart doet hij het weer prima.

Het IP adres wordt via dhcp uitgereikt en heb in mijn router geconfigureerd.

De lease time in /etc/dhcp/dhclient.conf staat op 3600 echter ook na 60 minuten wachten is de host nog steeds niet bereikbaar.

Iemand enig idee waar dit aan kan liggen en wat ik er aan kan doen?

[killercow]

werkt het wel als je het ip zelf in de arp tables van je client pusht met het mac address van de debian host?

[Hero of Time]

Moet die reboot van je NUC of kan je ook met NetworkManager opnieuw een IP adres ophalen. Of in geval je geen GUI hebt, via ifdown en ifup? Of systemctl restart networking.
Zie je verder nog iets in de logs (/var/log/syslog, dmesg, journalctl)? Het had wel geholpen als je die informatie al in je TS kon zetten bij het maken van dit topic.

[Bl4ckviper]

Hero of Time schreef op woensdag 17 oktober 2018 @ 20:36:
Moet die reboot van je NUC of kan je ook met NetworkManager opnieuw een IP adres ophalen. Of in geval je geen GUI hebt, via ifdown en ifup? Of systemctl restart networking.
Zie je verder nog iets in de logs (/var/log/syslog, dmesg, journalctl)? Het had wel geholpen als je die informatie al in je TS kon zetten bij het maken van dit topic.

Ik kan via ssh niet meer connecten na een reboot. Zal eens kijken of er iets in die log te vinden is. ken alleen de dmesg daar zag ik zo snel niets zal ook die andere even bekijken.

killercow schreef op woensdag 17 oktober 2018 @ 17:05:
werkt het wel als je het ip zelf in de arp tables van je client pusht met het mac address van de debian host?

Bedoel je hier mee het mac address toevoegen in de router?

[Hero of Time]

Bl4ckviper schreef op donderdag 18 oktober 2018 @ 21:47:
[...]

Ik kan via ssh niet meer connecten na een reboot. Zal eens kijken of er iets in die log te vinden is. ken alleen de dmesg daar zag ik zo snel niets zal ook die andere even bekijken.

Kijk dan ook eens wat er gebeurt als je de netwerkkabel eruit haalt en weer erin doet ipv de router rebooten. Heb je een vast IP aan de PC gegeven via DHCP reservering? Wat als je die ook vast instelt in Debian.

[Bl4ckviper]

@Hero of Time

De kabel in en uit blijft hij werken. Heb geprobeerd een static IP te doen via: https://medium.com/@cpt_m...an-9-stretch-acb4e5cb7dc1

Echter heb ik geen eth0 interface kwam in achter maar een eno1 (on board) en de zelfde werkwijze maar dan met eno1 levert geen succes op.

[Hero of Time]

De kabel heb je ook langer dan een paar seconden eruit gehad? Want dat is effectief wat er ook gebeurt als je je router/modem herstart.

Nog wijzer geworden van de logs?

[Bl4ckviper]

@Hero of Time
Heb de kabel er een kwartiertje uit gehad. Daarna werkte het wel erg vreemd.

Nee weinig in de logs geen error ofzo.

[Hero of Time]

Ook niet als je journalctl -f gebruikt en dan je modem reboot, terwijl er in een andere terminal wordt bijgehouden wat je IP is en/of de router pingt? Ben echt benieuwt wat er nou op het systeem gebeurt tijdens het verdwijnen van de dhcp server en link.

[Cyphax]

Zou dit niet aan de router kunnen liggen? Of is dat uitgesloten?

[Turdie]

Misschien een andere DNS servers gebruiken in je /etc/resolv.conf , misschien een DNS probleem?
Bijvoorbeeld die van OpenDNS.
Dus dan krijg je dit in je /etc/resolv.conf

Bash:

nameserver 208.67.222.222
nameserver 208.67.220.220

En dan even de networking daemon herstarten

Bash:

systemctl restart networking

[Voor 59% gewijzigd door Turdie op 20-10-2018 21:14]

[Bl4ckviper]

@Hero of Time
Dat ding staat in de meterkast dus moet hem even tevoorschijn toveren en dan aan een monitor hangen om de voorgestelde acties te doen.

@shadowman12
In de de resolv.conf staat
nameserver 213.75.63.75
nameserver 213.75.63.76
~
Plus mijn eigen router ip als nameserver. Hoort dat?

@Cyphax
Als het een router probleem zou moeten zijn moeten er dan niet meerdere devices onbereikbaar zijn?

[Hero of Time]

Ah, ik dacht dat het apparaat wat toegankelijker was. En via ssh uitvoeren heeft niet zo heel veel zin natuurlijk als de verbinding er uit klapt.
Voor wat betreft waarom je NUC als enige er last van heeft durf ik geen antwoord op te geven. Alleen dat ik iets vergelijkbaars wel eens meemaak in m'n eigen netwerk. Dan kan ik met m'n HTPC niet bij m'n Pi (die als DNS dienst doet ivm pi-hole) en een enkele keer ook niet bij m'n modem. Terwijl m'n telefoon wel gewoon verbinding heeft. Ene keer lost het op als ik het modem reboot, de andere keer als ik op m'n HTPC de netwerkkaart even down breng en weer up. Terwijl ik vaste IP adressen gebruik.

@shadowman12, sinds wanneer is het nodig om je netwerk te herstarten na het aanpassen van resolv.conf? Dat heb ik nog nooit hoeven doen en is ook niet nodig. Er is namelijk geen centraal netwerk daemon actief. Het enige wat je doet met je commando is het up brengen van je netwerkkaart(en).

[Cidolfas]

Is de NUC direct verbonden met de router of zit er nog iets tussen? Een switch bijvoorbeeld?

[Turdie]

Hero of Time schreef op zaterdag 20 oktober 2018 @ 22:33:


@shadowman12, sinds wanneer is het nodig om je netwerk te herstarten na het aanpassen van resolv.conf? Dat heb ik nog nooit hoeven doen en is ook niet nodig. Er is namelijk geen centraal netwerk daemon actief. Het enige wat je doet met je commando is het up brengen van je netwerkkaart(en).

Ik doe het eigenlijk altijd standaard, dacht het nodig was. Weer wat geleerd dat het niet nodig is blijkbaar.

Bl4ckviper schreef op zaterdag 20 oktober 2018 @ 21:57:


@shadowman12
In de de resolv.conf staat
nameserver 213.75.63.75
nameserver 213.75.63.76
~
Plus mijn eigen router ip als nameserver. Hoort dat?

@Cyphax
Als het een router probleem zou moeten zijn moeten er dan niet meerdere devices onbereikbaar zijn?

Ik zou je eigen router ip er even uitlaten, wellicht veroorzaakt die problemen.

[Voor 49% gewijzigd door Turdie op 21-10-2018 14:20]

[Bl4ckviper]

@shadowman12
Zal de router uit de config halen.

@Cidolfas
Er zit nog een ubiquiti switch tussen.

[Hero of Time]

shadowman12 schreef op zondag 21 oktober 2018 @ 13:35:
[...]

Ik doe het eigenlijk altijd standaard, dacht het nodig was. Weer wat geleerd dat het niet nodig is blijkbaar.

Doe maar eens een nslookup (of liever dig, dan zie je welke server er gebruikt wordt), verander je resolv.conf en doe dezelfde lookup nog eens. Dan zie je dat het adres van de server is verandert.

[...]

Ik zou je eigen router ip er even uitlaten, wellicht veroorzaakt die problemen.

Lijkt mij sterk. De kans dat het een issue zou zijn is vele malen kleiner dan dat DNS een issue is. Want ik ga er even vanuit dat de TS via het IP adres van de NUC een SSH sessie start. Een systeem dat om onverklaarbare redenen van het netwerk valt is zelden een probleem veroorzaakt door een DNS configuratie op dat systeem zelf.

@Bl4ckviper, die Ubiquity switch is als het goed is managed. Je zou daar dus iets van informatie uit kunnen halen wat er met de poort gebeurt waar dat systeem aan hangt. Hangen er andere systemen nog aan eigenlijk? Indien ja, hebben die ook issues? Zo niet, haal die switch er eens tussenuit als het kan.

[Bl4ckviper]

Hero of Time schreef op zondag 21 oktober 2018 @ 20:58:
[...]

Doe maar eens een nslookup (of liever dig, dan zie je welke server er gebruikt wordt), verander je resolv.conf en doe dezelfde lookup nog eens. Dan zie je dat het adres van de server is verandert.


[...]

Lijkt mij sterk. De kans dat het een issue zou zijn is vele malen kleiner dan dat DNS een issue is. Want ik ga er even vanuit dat de TS via het IP adres van de NUC een SSH sessie start. Een systeem dat om onverklaarbare redenen van het netwerk valt is zelden een probleem veroorzaakt door een DNS configuratie op dat systeem zelf.

@Bl4ckviper, die Ubiquity switch is als het goed is managed. Je zou daar dus iets van informatie uit kunnen halen wat er met de poort gebeurt waar dat systeem aan hangt. Hangen er andere systemen nog aan eigenlijk? Indien ja, hebben die ook issues? Zo niet, haal die switch er eens tussenuit als het kan.

Dat kan ik wel proberen de switch hangt in de zelfde meterkast. Zit nu in een hotel.

Ik connect meestal via de hostname overigens.

[Hero of Time]

Bl4ckviper schreef op zondag 21 oktober 2018 @ 21:12:
[...]

Dat kan ik wel proberen de switch hangt in de zelfde meterkast. Zit nu in een hotel.

Ik connect meestal via de hostname overigens.

Meestal, maar niet altijd dus? Dat is wel even een ding namelijk, want als het telkens faalt als je op hostnaam werkt, is de DNS cache van je router leeg na reboot en kent het je NUC niet totdat het adres via DHCP wordt vernieuwd. Of maak je gebruik van een externe DNS service waar je NUC ook in staat vermeld?

[Bl4ckviper]

Hero of Time schreef op zondag 21 oktober 2018 @ 21:25:
[...]

Meestal, maar niet altijd dus? Dat is wel even een ding namelijk, want als het telkens faalt als je op hostnaam werkt, is de DNS cache van je router leeg na reboot en kent het je NUC niet totdat het adres via DHCP wordt vernieuwd. Of maak je gebruik van een externe DNS service waar je NUC ook in staat vermeld?

Ja eigenlijk altijd. Grafana dashboard en als die dan niet werkt ssh ook via de hostname.

Ik gebruik niets externs mbt dns. Zou dat het kunnen zijn?

[Hero of Time]

Bl4ckviper schreef op zondag 21 oktober 2018 @ 21:35:
[...]

Ja eigenlijk altijd. Grafana dashboard en als die dan niet werkt ssh ook via de hostname.

Ik gebruik niets externs mbt dns. Zou dat het kunnen zijn?

Als je de router/modem gebruikt als DNS wel. Als je NUC toch altijd aan staat, maak er dan DNS van en geef 't een vast IP adres (te configureren door /etc/network/interfaces aan te passen). Stel vervolgens in je DHCP in dat je NUC de DNS server is.

[Bl4ckviper]

Hero of Time schreef op zondag 21 oktober 2018 @ 21:40:
[...]

Als je de router/modem gebruikt als DNS wel. Als je NUC toch altijd aan staat, maak er dan DNS van en geef 't een vast IP adres (te configureren door /etc/network/interfaces aan te passen). Stel vervolgens in je DHCP in dat je NUC de DNS server is.

Dank voor de tip!

Ik zal morgenavond even in de instellingen van mijn router checken mbt de DNS.

[Bl4ckviper]

Nou nu was het weer het geval. Echter via IP adres kan ik alles gewoon bereiken na het uitvoeren van sudo systemd-resolve --flush-caches was de machine ook weer via de hostname bereikbaar.

[Turdie]

Bl4ckviper schreef op dinsdag 23 oktober 2018 @ 20:19:
Nou nu was het weer het geval. Echter via IP adres kan ik alles gewoon bereiken na het uitvoeren van sudo systemd-resolve --flush-caches was de machine ook weer via de hostname bereikbaar.

Dan is het toch een DNS issue denk ik. De DNS servers die je gebruik in je resolv.conf zijn die van KPN?Zelf gebruik ik graag ook die van Level 3(4.2.2.2). Level 3 is ook een betrouwbare peering provider, dus beter dan van de meeste ISP's. De DNS servers van Ziggo bijvoorbeeld zijn echt drama die gebruik ik echt nooit meer.

Je kunt de lokale dns cache ook disablen:
https://ohthehugemanatee....-war-on-systemd-resolved/

Maar dan moest iets als network manager installeren om je resolved.conf te managen zoals staat beschreven.

[Voor 149% gewijzigd door Turdie op 23-10-2018 22:35]

[Turdie]

Sorry per ongeluk dubbelpost

[Voor 91% gewijzigd door Turdie op 23-10-2018 22:27]

[Hero of Time]

Wat valt er aan resolv.conf te managen als je toch altijd vaste DNS servers gebruikt of DHCP krijgt? Tenzij je constant van netwerk verandert of continu andere DNS servers moet hebben (om wat voor reden dan ook) is een manager wel handig, maar in het eerste geval heb je vast en zeker ook te maken met een DHCP server die je netjes DNS servers geeft. En dhclient zet die voor je in resolv.conf. NM en soortgelijke gebruik je alleen als je andere DNS servers wilt gebruiken dan je van DHCP krijgt. Niet echt iets als je baas bent over je eigen netwerk thuis.

[Bl4ckviper]

Ik dacht ook dat die twee DNS servers (die van mijn router afkomen via DHCP vermoed ik, want ik heb niets geconfigureerd) alleen waren om domein namen om te zetten naar ip maar niet voor binnen je eigen netwerk.

Wat kan veroorzaken dat de hostname niet beschikbaar is intern?

[Turdie]

Bl4ckviper schreef op woensdag 24 oktober 2018 @ 09:29:
Ik dacht ook dat die twee DNS servers (die van mijn router afkomen via DHCP vermoed ik, want ik heb niets geconfigureerd) alleen waren om domein namen om te zetten naar ip maar niet voor binnen je eigen netwerk.

Wat kan veroorzaken dat de hostname niet beschikbaar is intern?

Dan zul je in de logging moet zoeken met bijvoorbeeld journalctl

[Hero of Time]

Ook interne namen worden via DNS opgevraagd. Tenzij je Windows hebt, die gaat via NETBIOS zoeken, simpelweg omdat het toch al constant z'n naam over het netwerk schreeuwt.

Wat is je client op je netwerk en welke DNS gebruikt die?

[magistus]

Wellicht compleet uit de richting, maar voor de zekerheid deze fijne 'feature' nog disablen: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761658

Daarnaast, kan er misschien iets verkeerd staan in je /etc/hosts?
Ter referentie, bij mij staat er iets als:

127.0.0.1	localhost
127.0.1.1	hostname.localdomain.bla	hostname
...

Dat hoeft overigens niet standaard te zijn (ik freubel wel eens) en wellicht gebruik je een andere dhcp client.
En als ik het goed begreep, heb je zelf de dns niet opgevoerd maar wordt deze gezet middels dhcp. In mijn /etc/dhcp/dhcpclient.conf staat hiervoor:

...
send host-name = gethostname();

Dus als dit niet goed gaat, om wat voor reden dan ook, dan wordt er dus ook nooit een hostname gezet. Ik zou dan ook vermoeden als gethostname afhankelijk is van een onbereikbare externe DNS-server of foute lokale cache, je dus ook geen hostname middels dhcp kunt zenden.

[Voor 2% gewijzigd door magistus op 29-10-2018 21:17. Reden: Ugh....syntax]

[Bl4ckviper]

@Hero of Time

Wat bedoel je met de vraag: Wat is je client op je netwerk en welke DNS gebruikt die?

Want ik vraag de website op de hostename op via Android telefoon, Windows machine, SSH en mac.

@magistus
Ik zal dat vanavond even checken.

[Hero of Time]

Bl4ckviper schreef op dinsdag 30 oktober 2018 @ 14:54:
@Hero of Time

Wat bedoel je met de vraag: Wat is je client op je netwerk en welke DNS gebruikt die?

Want ik vraag de website op de hostename op via Android telefoon, Windows machine, SSH en mac.

Precies wat je nu aangeeft: welke apparaten gebruik je om naar deze machine te gaan. En welke DNS is daarop ingesteld. Is dat OpenDNS, je modem/router, iets anders? Als het niet je modem/router is, hoe kan het dan je interne adressen resolven?

[Bl4ckviper]

Hero of Time schreef op dinsdag 30 oktober 2018 @ 15:26:
[...]

Precies wat je nu aangeeft: welke apparaten gebruik je om naar deze machine te gaan. En welke DNS is daarop ingesteld. Is dat OpenDNS, je modem/router, iets anders? Als het niet je modem/router is, hoe kan het dan je interne adressen resolven?

Niets bijzonders voor ingesteld. Dus vermoed de instellingen van de router. Alle IP's worden uitgedeeld middels DHCP

[Hero of Time]

Hmm, met Bl4ckviper in "Debian 9.3 host niet bereikbaar na reset van de router" geef je aan dat de OpenDNS servers worden gebruikt, plus je router. Staat die dan bovenaan, of onderaan?

[Bl4ckviper]

@Hero of Time
In mijn router staat:

code:

DNS Server 1: IP router
DNS Server 2: From ISP 213.75.63.75
DNS Server 3: From ISP 213.75.63.76

Deze instellingen zijn door Telfort zelf gedaan denk ik want ik heb ze niet gedaan.
Op bijvoorbeeld mijn laptop staat er:

code:

DNS Servers . . . . . . . . . . . : router ip
                                     213.75.63.75
                                     213.75.63.76

Op mijn NUC staat er in de resolve.conf:

code:

search home
nameserver <ip router>
nameserver 213.75.63.75
nameserver 213.75.63.76

@magistus
in de hots staat:

code:

127.0.0.1       localhost
127.0.1.1       <gekozen hostname>

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

en in /etc/dhcp/dhcpclient.conf

code:

send host-name = gethostname();

Plus een hoop andere tekst.

[Voor 4% gewijzigd door Bl4ckviper op 31-10-2018 21:27]

[Hero of Time]

Ok, je gebruikt je modem dus primair voor DNS. Al je apparaten (iig de Nuc) melden zich soort-van aan op het modem met hun naam zodat andere clients hun kan vinden. Wat die systemd-resolved--flush-caches precies doet weet ik niet. Maar blijkbaar meldt het zich opnieuw aan bij je modem ofzo. Ik ben eigenlijk meer benieuwd naar of je via IP adres nog je Nuc kan benaderen nadat je modem een herstart heeft gehad en de hostname resolving niet meer werkt.

[Bl4ckviper]

Hero of Time schreef op woensdag 31 oktober 2018 @ 21:52:
Ok, je gebruikt je modem dus primair voor DNS. Al je apparaten (iig de Nuc) melden zich soort-van aan op het modem met hun naam zodat andere clients hun kan vinden. Wat die systemd-resolved--flush-caches precies doet weet ik niet. Maar blijkbaar meldt het zich opnieuw aan bij je modem ofzo. Ik ben eigenlijk meer benieuwd naar of je via IP adres nog je Nuc kan benaderen nadat je modem een herstart heeft gehad en de hostname resolving niet meer werkt.

ja dat kon dus nog. Het IP adres van de nuc is dan nog bereikbaar

[Hero of Time]

Dan is de reden duidelijk: als het modem herstart is z'n DNS cache leeg (zoals bij veel apparaten en besturingssystemen) en clients dienen zich opnieuw kenbaar te maken. Dat zou voor je Nuc automatisch moeten gebeuren als het z'n IP vernieuwd via DHCP, of als je het op een andere manier forceert.

[Bl4ckviper]

Ik zou dus gewoon systemd-resolved--flush-caches kunnen laten uitvoeren meerdere keren per dag om het te tackelen dan?

Ik vind het wel vreemd dat allerlei andere zaken wel benaderbaar blijven maar deze niet. Is dit iets van mijn router en de debian client?

[NimRod1337]

Je hebt op de NUC zelf iets met DHCP ingesteld itt out of the box (waar DHCP al werkt)? Wat is die setting? Je connect op IP? Wat heeft DNS hier dan mee te maken?

[Hann1BaL]

Je zou nog even een een IP adres kunnen toewijzen aan het MAC van de NUC op je router. Dan vergeet je router het device niet. Dit is uiteraard op zich niet nodig als je een statisch IP adres hebt ingevuld, maar het heeft bij mij vergelijkbare problemen opgelost in het verleden door een DHCP reservering te maken.