Debian Stretch auf OVH

[ThomasTailor93]

Hallo,

ich habe aktuell ein kleines Problem mit meinem OVH System.

Als allererstes möchte ich mich für die Formatierung entschuldigen. Falls es sowas ähnliches als Funktion gibt, kann ich das gerne im Nachhinein noch ändern.

Ich baue mir eine VM auf Basis von KVM mit den virtio Treibern (einfach, damit es ein bisschen mehr Performance gibt) mit 2 Cores und 4GB RAM. Als System nutze ich Debian Stretch amd64.

Ich habe über das Kundenportal von OVH eine IP 178.33.xxx.xxx erstellt mit der MAC 02:00:00:xx:xx:xx.

Ich habe als erstes das System neu aufgesetzt. Netzwerk wird dabei unkonfiguriert gelassen, weil das ja schließlich am Ende manuell gemacht werden muss.

Da eth0 in Stretch nicht mehr verfügbar ist, hole ich mir über

$ ip a

erstmal den Namen der Schnittstelle. Das wäre in diesem Fall ens18.

Nun konfiguriere ich das Interface wie folgt:

$ nano /etc/network/interfaces

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo ens18
iface lo inet loopback

iface ens18 inet static
address 178.33.xxx.xxx
netmask 255.255.255.255
broadcast 178.33.xxx.xxx
post-up route add xxx.xxx.xxx.254 dev ens18
post-up route add default gw xxx.xxx.xxx.254
pre-down route del default gw xxx.xxx.xxx.254
pre-down route del xxx.xxx.xxx.254 dev ens18
dns-nameservers 213.186.33.99
dns-search ovh.net

sowie

$ nano /etc/resolv.conf

nameserver 213.186.33.99

Auf Debian 8 müsste nun, nach einem Reboot (natürlich in dem Fall mit eth0 anstatt ens18) eine Verbindung zum Netzwerk aufgebaut werden. Interessanterweise ist dies aber NICHT! möglich.

Sobald ich

$ ping google.com

eingebe, wird mir die Meldung

$ ping: google.com Temporärer Fehler bei der Namensauflösung

ausgeben.

Hat jemand von Euch evtl. eine Lösung? Ich bedanke mich im Voraus!

Viele Grüße
ThomasTailor93

 

[ThomasTailor93]

Kurzes Update:

der Support ist mit mir diverse Optionen durchgegangen. Leider hat keine dieser funktioniert.

Auch die Idee, dass die IP eventuell nicht erreichbar ist, wurde auch eingeworfen. Aber die IP ist über die o. g. Routine auf Debian 8 erreichbar.

VG

 

[dcsapak]

kannst du mal den inhalt von

/etc/hosts
/etc/nsswitch.conf

und die ausgabe von

host google.com
dig google.com

posten?

 

[ThomasTailor93]

Spoiler: /etc/hosts

127.0.0.1 localhost
127.0.0.1 mtb-testserver

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

Spoiler: /etc/nsswitch.conf

passwd: compat
group: compat
shadow: compat
gshadow: files

hosts: files dns
networks: files

protocols: db files
services: db files
ethers: db files
rpc: db files

netgroup: nis

Die beiden Befehle können nicht ausgeführt werden, da weder host noch dig zur Verfügung stehen. Das Paket, dnsutils, kann auch nicht installiert werden, da es anscheinend nicht vorhanden ist in der netinstall.

 

[dcsapak]

nur mal zur klärung:
ist das jetzt eine debian 8 oder debian 9 vm? (in den posts wird von debian 8 geredet, im titel steht aber stretch?)
sind hosts im internet via ip erreichbar? (also funktioniert nur dns nicht?) wenn ja, ist eine firewall aktiv?
ist die mac adresse die im ovh panel eingerichtet ist auch der vm gegeben worden?

der wiki artikel
https://pve.proxmox.com/wiki/OVH
ist bekannt?

 

[ThomasTailor93]

Hallo,

danke für die Rückmeldung. Sorry, ich habe das wohl etwas unschlüssig geschrieben.

Ich habe bereits acht VMs mit Debian 8 auf meiner OVH Kiste laufen. Zum Test wollte ich Debian 9 mit der gleichen Vorgehensweise wie bei Debian 8 installieren. Aber die VM bekommt keine Verbindung ins Netz, deshalb der Thread.

Hoffe jetzt kommt Licht in das Dunkle meiner Gedankengänge

Zu Deinen Fragen: ja, der Eintrag im Wiki ist bekannt. Genau so habe ich das auch eingerichtet. An der Firewall liegt es nicht, da ich, wie beschrieben, über die gleiche Ip eine anderes Betriebssystem installiert habe und das sofort ging. Demnach stimmt die MAC auch überein.

Der Support von OVH gab mir den Hinweis, dass es in Stretch aktuell Probleme mit post-up Regeln gibt, die in Verbindung mit IPv6 stehen. Anscheinend, so sagte er, passiert das nun mit IPv4.

Ist Dir da irgendwas in diese Richtung bekannt? Aus dem Bug Tracker von Debian werde ich auch nicht schlau.

Danke Dir für deine Hilfe!

Viele Grüße

 

[dcsapak]

versuch mal statt dem 'route' tool das tool 'ip' zu verwenden

also statt

post-up route add xxx.xxx.xxx.254 dev ens18
post-up route add default gw xxx.xxx.xxx.254

das hier:

post-up ip route add xxx.xxx.xxx.254 dev ens18
post-up ip route add default via xxx.xxx.xxx.254

edit:

natürlich das gleiche machen für die post-down sachen
für die genaue syntax : man ip

 

[ThomasTailor93]

Danke für die Rückmeldung.

Sowas ähnliches hatte der Support schon wie folgt vorgeschlagen:

Um dies zu beheben, können Sie in der /etc/rc.local NUR die post-up regeln reinsetzen.

Beispiel:
/sbin/ip route add IP.IHRES.SERVERS.254 dev eth0
/sbin/ip route add default gw IP.IHRES.SERVERS.254

Leider funktioniert die von Dir vorgeschlagene Lösung auch nicht.

EDIT:

Ok, ich hatte übersehen, dass anstatt "gw" "via" benutzt wird. Jetzt geht es doch.

Danke für die Hilfe !

Viele Grüße