Nameserver Strato Server

M

MrSpockDe

New Member
Hallo,
ich nutze ubuntu 22 auf einem Strato Dedicated Server mit plesk. Nach ein paar updates habe ich einen reboot durchgeführt und der Server war nicht mehr erreichbar. Also habe ich mich mit der Remote Console angemeldet und nachgeschaut, warum der Server nicht mehr erreichbar ist. Dabei ist mir aufgefallen, dass der Server offensichtlich keine Namen mehr auflösen kann. Nach einiger Rechersche habe ich mir mal die Datei unter /etc/netplan angeschaut, sie enthielt folgende Einträge:

Code: 
network:
  version: 2
  renderer: networkd
  ethernets:
    enp2s0:
      dhcp4: true
      dhcp6: false
      routes:
          - to: ::/0
            via: fe80::1

Ich habe dann folgende Einträge gemacht:
Code: 
network:
  version: 2
  renderer: networkd
  ethernets:
    enp2s0:
      dhcp4: no
      dhcp6: no
      addresses: [192.168.0.100/24]
      routes:
          - to: default
            via: 192.168.0.1
      nameservers:
          addresses: [1.1.1.1,8.8.8.8,8.8.4.4]

Es gab ja vorher keinen nameservers Eintrag und ich habe anstatt dhcp einmal eine feste Adresse zugewiesen und diese auch in /etc/hosts eingetragen.
Ich wusste aber nicht, über welche interne IP Adresse der Nameserver erreicht werden kann und habe unter via 192.168.0.1 eingetragen. Nach Anwendung des Konfiguration habe ich neu gestartet und erhalte ein Failure beim Hochfahren:


Code: 
...
[  OK  ] Started Kaspersky Anti-Virus service.
[  OK  ] Started Interface between …virus scanner/content filters.
[  OK  ] Started System Logging Service.
[  OK  ] Started Thermal Daemon Service.
[  OK  ] Finished GRUB failed boot detection.
[FAILED] Failed to start Wait for Network to be Configured.
See 'systemctl status systemd-networkd-wait-online.service' for details.
[  OK  ] Reached target Network is Online.
[  OK  ] Started Download data for …ailed at package install time.
[  OK  ] Started Check to see wheth…w version of Ubuntu available.
[  OK  ] Reached target Timer Units.
...

und auch pings kommen nicht an:
Code: 
/etc/netplan# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 192.168.0.100 icmp_seq=1 Destination Host Unreachable
From 192.168.0.100 icmp_seq=2 Destination Host Unreachable

wie müssen die Einträge in der Konfigurationsdatei korrekt aussehen?
 
MrSpockDe said:
wie müssen die Einträge in der Konfigurationsdatei korrekt aussehen?
Click to expand...
In Deinem Logauszug steht dieser Text:

Code: 
[FAILED] Failed to start Wait for Network to be Configured.
See 'systemctl status systemd-networkd-wait-online.service' for details.

Das empfohlene Kommando kannst Du ja schon mal ausführen und schauen, was da so steht.

Ansonsten finde ich, wenn ich nach netplan+beispiel+ubuntu per Google suche, diese hilfreiche Seite aus dem Ubuntu Users Forum:

https://wiki.ubuntuusers.de/Netplan/

Im Übrigen ist die generelle Anlaufstelle für Netplan zum einen die Manpage und zum anderen die Internetseite (https://netplan.io) für die Rerferenzdokumentation.

Weiterhin für die Netzwerkkonfiguration hilfreich ist das Kommando ip aus dem iproute2-Paket. Dabei gibt es zwei hilfreiche Befehle für die Netzwerkdiagnose:

  • ip addr show (oder abgekürzt ip a) : Anzeige der konfigurierten IP-Adressen
  • ip route show (oder abgekürzt ip r) : Anzeige der aktiven Routen
 
Last edited:
Hallo greystone,
ja habe ich natürlich geprüft
Code: 
/etc/netplan# systemctl status systemd-networkd-wait-online.service
× systemd-networkd-wait-online.service - Wait for Network to be Configured
     Loaded: loaded (/etc/systemd/system/systemd-networkd-wait-online.service; >
     Active: failed (Result: exit-code) since Sat 2023-07-01 20:12:43 CEST; 41m>
       Docs: man:systemd-networkd-wait-online.service(8)
    Process: 734 ExecStart=/lib/systemd/systemd-networkd-wait-online --timeout=>
   Main PID: 734 (code=exited, status=1/FAILURE)
        CPU: 7ms

Jul 01 20:12:33 h3008123 systemd[1]: Starting Wait for Network to be Configured>
Jul 01 20:12:43 h3008123 systemd-networkd-wait-online[734]: Timeout occurred wh>
Jul 01 20:12:43 h3008123 systemd[1]: systemd-networkd-wait-online.service: Main>
Jul 01 20:12:43 h3008123 systemd[1]: systemd-networkd-wait-online.service: Fail>
Jul 01 20:12:43 h3008123 systemd[1]: Failed to start Wait for Network to be Con>
...skipping...
× systemd-networkd-wait-online.service - Wait for Network to be Configured
     Loaded: loaded (/etc/systemd/system/systemd-networkd-wait-online.service; >
     Active: failed (Result: exit-code) since Sat 2023-07-01 20:12:43 CEST; 41m>
       Docs: man:systemd-networkd-wait-online.service(8)
    Process: 734 ExecStart=/lib/systemd/systemd-networkd-wait-online --timeout=>
   Main PID: 734 (code=exited, status=1/FAILURE)
        CPU: 7ms

Jul 01 20:12:33 h3008123 systemd[1]: Starting Wait for Network to be Configured>
Jul 01 20:12:43 h3008123 systemd-networkd-wait-online[734]: Timeout occurred wh>
Jul 01 20:12:43 h3008123 systemd[1]: systemd-networkd-wait-online.service: Main>
Jul 01 20:12:43 h3008123 systemd[1]: systemd-networkd-wait-online.service: Fail>
Jul 01 20:12:43 h3008123 systemd[1]: Failed to start Wait for Network to be Con

ip a hatte ich auch schon ausgeführt:


Code: 
ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether b6:49:a9:91:6b:9a brd ff:ff:ff:ff:ff:ff permaddr 96:a9:c1:9e:00:f0
    inet 192.168.0.100/24 brd 192.168.0.255 scope global enp2s0
       valid_lft forever preferred_lft forever
    inet6 fe80::b449:a9ff:fe91:6b9a/64 scope link
       valid_lft forever preferred_lft forever

ip r zeigt halt das an, was ich eingestellt habe
Code: 
ip r
default via 192.168.0.1 dev enp2s0 proto static
192.168.0.0/24 dev enp2s0 proto kernel scope link src 192.168.0.100
 
Den Link https://wiki.ubuntuusers.de/Netplan/ hatte ich auch schon gesehen. Ich meine aber verstanden zu haben, dass es zwischen ubuntu 20 und 22 eine Änderung bezüglich der Namensauflösung gegeben hat. Aber der Link zeigt ja auch nur ein Beispiel für den Aufbau der yaml Datei. Die form stimmt ja mit meinen Einträgen überein. Mir ist nur nicht klar, ob die IPs 1.1.1.1,8.8.8.8 und 8.8.4.4 stimmen und über welche interne IP gesucht werden soll (Gateway).
 
Ansonsten ist auf einem dedizierten Server die 192.168.0.100 mit Sicherheit nicht richtig, weil Du da zum einen eine öffentliche IPv4 brauchst und zum anderen genau die, die Dir Dein Anbieter vorkonfiguriert hat. Wie kommst Du darauf die 192.168.0.100 zu nehmen?

Mit der abgeschnittenen Ausgabe von systemctl status kann man hier leider überhaupt nichts erkennen.

D. h. also möglicherweise, dass die YAML-Konfig von netplan syntaktisch korrekt ist und du aber die schlicht die falschen IP-Adressen + Routen konfiguriert hast.
 
Hallo greystone,

naja, ich hatte das so interpretiert, dass ich entweder über dhcp eine dynamische Adresse verwenden kann oder eine andere feste lokale. Dafür sind ja 192.168.xxx.xxx die Standardadressen. In der /etc/host stand vorher für den Server die lokale Adresse 127.0.0.1 also localhost. Die habe ich zwar auch versucht, aber dabei wurden beim Booten viele Fehler erzeugt. Und die 192.168.0.100 habe ich hier her: https://www.howtoforge.com/ubuntu-22-04-minimal-server/#g0.0.7

Die externe IP, über die ich erreichbar sein möchte steht halt über Plesk in den Einträgen zu den Domänen.

Hier nochmal die nicht abgeschnitte Version:
Code: 
× systemd-networkd-wait-online.service - Wait for Network to be Configured
     Loaded: loaded (/etc/systemd/system/systemd-networkd-wait-online.service; enabled; vendor preset: disabled)
     Active: failed (Result: exit-code) since Sat 2023-07-01 20:12:43 CEST; 1h 20min ago
       Docs: man:systemd-networkd-wait-online.service(8)
    Process: 734 ExecStart=/lib/systemd/systemd-networkd-wait-online --timeout=10 (code=exited, status=1/FAILURE)
   Main PID: 734 (code=exited, status=1/FAILURE)
        CPU: 7ms

Jul 01 20:12:33 h3008123 systemd[1]: Starting Wait for Network to be Configured...
Jul 01 20:12:43 h3008123 systemd-networkd-wait-online[734]: Timeout occurred while waiting for network connectivity.
Jul 01 20:12:43 h3008123 systemd[1]: systemd-networkd-wait-online.service: Main process exited, code=exited, status=1/FAILURE
Jul 01 20:12:43 h3008123 systemd[1]: systemd-networkd-wait-online.service: Failed with result 'exit-code'.
Jul 01 20:12:43 h3008123 systemd[1]: Failed to start Wait for Network to be Configured.
 
192.168.0.0/24 gehört zu den RFC1918-Adressbereichen, die Du verwenden kannst, wenn Du isolierte eigene Netze betreibst.

Wenn Du im Internet erreichbar sein willst, brauchst Du die richtige öffentliche Adresse, die Dein Anbieter auch zu Deinem System routed. Kann sein, dass Du die Adresse herausfindest, wenn Du wieder auf DHCP umstellst und dann automatisch die richtige zugewiesen bekommst. Das würde ich Dir mal empfehlen.

Das was Du bei Plesk im DNS einstellst sind Informationen, wie Deine Domains gefunden werden. Dazu muss Dein DNS-Server im Plesk aber erst einmal im Internet erreichbar sein.
 
Last edited:
OK, habe jetzt mal die Konfig Datei auf die originalen Einträge zurück gesetzt und nur noch die Nameserver hinzugefügt. Das sieht jetzt so aus:
Code: 
network:
  version: 2
  renderer: networkd
  ethernets:
    enp2s0:
      dhcp4: true
      dhcp6: false
      routes:
          - to: ::/0
            via: fe80::1
      nameservers:
          addresses: [1.1.1.1,8.8.8.8,8.8.4.4]

Und die /etc/hosts habe ich auch zurückgesetzt auf:

Code: 
127.0.0.1    localhost
127.0.0.1    h3008123.stratoserver.net    h3008123

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

Anstelle der 127.0.0.1 habe ich aber auch mal die externe mir zugewiesene Adresse benutzt. Beides mal habe ich denselben Fehler wie oben (Timeout) und ein ping geht erst gar nich raus:

Code: 
ping 1.1.1.1
ping: connect: Das Netzwerk ist nicht erreichbar
 
ip a:
Code: 
ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether b6:49:a9:91:6b:9a brd ff:ff:ff:ff:ff:ff
    inet6 fe80::b449:a9ff:fe91:6b9a/64 scope link
       valid_lft forever preferred_lft forever

ip r ist leer

Und die gateway ip kenne ich ja nicht. Der einzige ping der etwas zurückgibt ist der localhost ping 127.0.0.1
 
Ok. Dann bekommst Du keine IP-Adresse per DHCP - wenn Deine Konfiguration richtig ist (da bin ich mir noch nicht ganz sicher).

Dann würde ich mal in Dein Strato-Kundenportal reinschauen, ob da bei Deinem Server irgendwo die zugewiesene IP-Adresse steht. Weiss gerade nicht, wie das bei Strato so aussieht.
 
Die Adresse, die meinem Server zugewiesen werden soll, kenne ich ja. Und ich habe mal dhcp ausgeschaltet und diese Adresse direkt eingetragen, hat aber auch nicht funktioniert.

Aber ich kann den Server auch nicht über ssh erreichen, sondern im Moment nur per Remote Console. Der Server startet im Prinzip keinen Service und ich kann auch nichts installieren, da er dabei immer versucht auf ftp.stratoserver.net zuzugreifen, das aber nicht auflösen kann, weil die Namensauflösung nicht funktioniert.
 
Last edited:
Deine Public IP alleine reicht nicht. Du musst auch noch das Gateway eintragen. Das könnte auch noch im Kundenportal stehen.
 
Genau deshalb habe ich ja oben den Eintrag routes für ip4 hinzugefügt und dhcp ausgeschaltet. Ich hatte ja schon darauf hingewiesen, dass ich die Gateway Adresse aber nicht kenne. Und wenn ich nachlese, wie man diese findet, komme ich indirekt wieder auf den Eintrag zurück, den ich hier reinschreibe.

Code: 
network:
  version: 2
  renderer: networkd
  ethernets:
    enp2s0:
      dhcp4: no
      dhcp6: no
      addresses: [192.168.0.100/24]
      routes:
          - to: default
            via: 192.168.0.1
      nameservers:
          addresses: [1.1.1.1,8.8.8.8,8.8.4.4]
 
MrSpockDe said:
Genau deshalb habe ich ja oben den Eintrag routes für ip4 hinzugefügt und dhcp ausgeschaltet. Ich hatte ja schon darauf hingewiesen, dass ich die Gateway Adresse aber nicht kenne. Und wenn ich nachlese, wie man diese findet, komme ich indirekt wieder auf den Eintrag zurück, den ich hier reinschreibe.

Code: 
network:
  version: 2
  renderer: networkd
  ethernets:
    enp2s0:
      dhcp4: no
      dhcp6: no
      addresses: [192.168.0.100/24]
      routes:
          - to: default
            via: 192.168.0.1
      nameservers:
          addresses: [1.1.1.1,8.8.8.8,8.8.4.4]
Click to expand...
Die Konfiguration kannst Du in die Tonne treten. Die ist falsch. Die hilft Dir nicht.

Du brauchst das Gateway zu Deiner Public-IP bei Strato. Entweder die steht auch in Deinem Kundenportal bei Strato - und davon gehe ich aus, oder Du musst Dir vom Kundensupport da helfen lassen, diese zu finden. Alternativ dazu wahrscheinlich Serverneuinstallation. Ich denke danach wird die IP-Konfiguration korrekt sein.
 
Last edited:
Hallo greystone,

habe das Strato Portal noch einmal komplett durchsucht, diese Information wird nicht zur Verfügung gestellt.

Deshalb habe ich versucht, über den Zugriff mit Hilfe der RemoteConsole Daten auf einem anderen Server zu kopieren. Geht aber nicht, weil der Server wegen falscher Netzwerkkonfiguration nicht auf das Netzwerk zugreifen kann. Also habe ich das Rettungssystem aktiviert. Mir werden dann auch die SSH Zugriffsdaten des Rettungssystem gezeigt, aber auch das ist nicht erreichbar. Ich habe die Befürchtung, dass es zumindest für die Einrichtung des Netzwerkes auf dieselbe Netzwerk Konfigurationsdatei zugreift. Habe jetzt mal Strato angeschrieben, da mir so langsam die Optionen ausgehen.
 
Das Rescuesystem sollte auf jeden Fall seine eigene Netzwerkkonfiguration mitbringen. Es wird mit Sicherheit nicht auf die Platte zugreifen und von dort die Netzwerkkonfiguration laden. Im sehr unwahrscheinlichen Fall hat das Rescuesystem keine Netzwerkkonfiguration.

Was aber dort sein könnte, wäre, dass Firewallregeln aktiv sind (iptables), die man vor einer Verbindung erst anpassen muss. Aber mit Rescue-System und Konsole solltest Du möglicherweise das Gateway herausfinden können. (ip -a; ip -r).
 
Es könnte sein, dass das System noch nicht rebootet war, das habe ich dann erzwungen.

Jetzt habe ich es auch ohne Rettungssystem geschafft. Habe bei Strato gefunden, wie man eine zweite IP einrichtet und das ganze dann benutzt für die erste IP Adresse:

Code: 
network:
  version: 2
  renderer: networkd
  ethernets:
    enp2s0:
      dhcp4: yes
      addresses: [81.xxx.xxx.xxx/32]
      dhcp6: no
      routes:
          - to: ::/0
            via: fe80::1
      nameservers:
          addresses: [1.1.1.1,8.8.8.8,8.8.4.4]

Es hat dann tatsächlich alles wieder funktioniert und ich musste keine Gateway IP angeben.

ip a zeigt jetzt:
Code: 
ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether d4:3d:7e:34:af:38 brd ff:ff:ff:ff:ff:ff
    inet 81.xxx.xxx.xxx/32 metric 100 scope global dynamic enp2s0
       valid_lft 84194sec preferred_lft 84194sec
    inet6 fe80::d63d:7eff:fe34:af38/64 scope link
       valid_lft forever preferred_lft forever

ip r
Code: 
ip r
default via 81.xxx.xxx.1 dev enp2s0 proto dhcp src 81.xxx.xxx.xxx metric 100
81.xxx.xxx.34 via .81.xxx.xxx..1 dev enp2s0 proto dhcp src 81.xxx.xxx.xxx metric 100
81.xxx.xxx.1 dev enp2s0 proto dhcp scope link src 81.xxx.xxx.xxx metric 100
81.xxx.xxx.106 via 81.xxx.xxx.1 dev enp2s0 proto dhcp src 81.xxx.xxx.xxx metric 100
85.xxx.xxx.22 via 81.xxx.xxx.1 dev enp2s0 proto dhcp src 81.xxx.xxx.xxx metric 100

D.h. dass das Gateway auch im 81.xxx.xxx.xxx

pings funktionieren jetzt zu allen ip Adressen. Und das System findet auch wieder ftp.stratoserver.net und kann damit updates machen. Der Plesk Zugang funktioniert auch wieder.

Magisch bleibt nur, wer die Einstellungen in der Netzwerk Konfigurationsdatei geändert hat.
 
Last edited:
greystone said:
DHCP scheint wohl die Vorgabekonfiguration zu sein.
Click to expand...

Es funktioniert auch statisch. Nur muß man halt die Vorgaben beachten, insbesondere das /32.

Das hängt auch damit zusammen daß die Server nicht alle einfach in einem großen Subnetz (L2 Broadcastdomain) sind, sondern aus Sicherheitsgründen isoliert und nur mit dem Gateway sprechen können. Ebenso muß die MAC und die IP stimmen.

Das machen andere (z.B. Hetzner) prinzipiell genauso, nur gibt es bei Strato nicht die Möglichkeit, andere MACs (z.B. zur Virtualisierung) freischalten zu lassen - das Routing läuft prinzipiell über das primäre Interface.

Nameserver sind übrigens 81.169.148.34, 81.169.163.106 und 85.214.7.22 (Karlsruhe und Berlin).
 
You must log in or register to reply here.
Back
Top