[gelöst] Server remote nicht mehr erreichbar - Was tun?

[sunghost]

Hallo,
ich habe einen neuen Server mit Debian Jessie und Proxmox 4.2 installiert. Per SSH bin ich verbunden, nach einem Neustart komme ich per SSH auf den Server alle Services laufen. Nach ca. 1h ist der Server nicht mehr erreichbar. In den Logs, per Remotehand, ist alles i.O. Meine Frage ist nun was kann ich noch machen, um den Fehler einzugrenzen bzw. zu finden. Meine Idee war die Netzwerkeinstellung beim boot zu loggen, bzw. wo könnte ich sehen, was da los ist. Wie geschrieben, kernel.log, syslog, messages etc. kontrolliert, sieht gut aus.

Idee? thx

[outis]

Irgendwelche Stromspareinstellungen, die z.B. das Netzwerkinterface schlafen legen?

[sunghost]

HI Jochen,

kenne ich so von den zahlreichen netinstall Versionen von Debian eigentlich nicht, aber wo kann ich das genau nachprüfen?. Ich bin inzwischen einen Schritt weiter. Wenn ich den Server aus der Remotekonsole per RAC neustarte, dann komme ich per SSH nicht rauf, per angeschlossenen KVM/Terminal komme ich rauf, starte neu und siehe da, er ist auch per SSH erreichbar. Das ist reproduzierbar, erklärt jedoch nicht, warum er nach ca. 1h offline ging. Ich prüfe noch... Hinweise erwünscht

[heisenberg]

Has Du 'ne Konsole, mit der Du bei getrenntem Netz noch draufschauen kannst? Manche Serveranbieter bieten so etwas an. Bei virtuellen Servern geht so etwas per Software. Bei dedizierten kann man vielleicht eine Konsole buchen.

[sunghost]

Hi,
ob ich die zztl. buchen kann, müsste ich prüfen. In diesem Fall wurde als Service eine KVM Netzwerkkonsole angeschlossen und ich konnte komplett vom Boot draufschauen. Daher konnte ich auch sehen, dass der Boot über die Weboberfläche des Provider, zwar bis zur Anmeldung durchlief, aber dennoch keine SSH-Verbindung möglich war. Über die Konsole konnte ich mich dann anmelden und den Server neustarten. Danach funktionierte dann auch die Anmeldung mittels SSH.

Meine Vermutung ist eine Netzwerkseitige / Router / DHCP. D.h. wenn ich den Server aus der Konsole neustarte, dann wird die Kommunikation mit dem Router/Switch korrekt aufgebaut, sodass dieser weiß, dass der Server neugestartet wurde. Wenn es über die Weboberfläche erfolgt, dann erfolgt keine so "saubere" Rückmeldung vom Server, sodass der Router denkt, dass die IP noch vergeben ist und entsprechend aus Sicherheitsgründen, diese nicht neu vergibt <- aber das ist nur eine Vermutung und ich stecke in diesem Bereich nicht tief drinn.

Komischerweise läuft der Server nun seit ca. 12:30 Uhr ?! Ein ungutes Gefühl bleibt...

[heisenberg]

Ideal wäre es auf den Server zu schauen, wenn gerade keine Verbindung möglich ist und sich anzuschauen, was da gerade kaputt ist. IP weg vom Interface? Firewallregeln? Dmesg? ....

[sunghost]

Hi,
habe ich im kurzen Zeitfenster das ich hatte gemacht. Netzkonf. = ok, keine Firwall aktiv, Log sah normal aus <- ich konnte aber nur oberflächlich drauf schauen, da aber alles clean install ist, ist es überschaubar. Dmesg ohne Fehler, steht zwar erst eth0 disconnected, aber wenig später ist eth0 connected und im forward modus.. also recht normal

[rendegast]

Tauschen systemd-init <-> sysv-init ?

[sunghost]

Warum sollte ich das machen? Kannst du das näher erklären? Ich weiß bei Debian hat man dies im letzten Release geändert....
PS: Server läuft noch ?!

[rendegast]

Warum sollte ich das machen?

Um es gemacht zu haben.
Da hier ja scheinbar keinerlei Hinweise verfügbar sind, ist es sowieso ein try-and-error.

[heisenberg]

Tauschen systemd-init <-> sysv-init ?

Ich zweifle den Ratschlag aber auch mal etwas an. Das kann man natürlich machen. Aber mit der gleichen Begründung kann ich auch empfehlen: Installiere mal FreeBSD oder Windows.

----

Ich sehe gerade, dass ist wohl Deine Netzwerkkonfiguration:

https://serversupportforum.de/forum/ded ... ation.html

[sunghost]

Hi,
neue Info. Nachdem ich die ganze Zeit, per SSH verbunden war, hatte ich mich ausgeloggt und bums, der Server ist wieder nicht erreichbar. So nun die Frage ob sich irgendwas in Jessie zuletzt geändert hat, dass das "normal" sein könnte - Idee?

[outis]

Wie versuchst du den Server zu erreichen?

Per ssh ip oder ssh hostname?

[sunghost]

Hi,
per IP. Bin bei Hetzner. Hier hatte einer das selbe Problem: http://serverfault.com/questions/728560 ... sful-tries In meinem ist auch eine Intel Nic verbaut...

[outis]

Dann schau doch mal mit ethtool nach, wie die NIC konfiguriert ist.

[sunghost]

Hi,
kann ich machen, muss nur einen neuen Service für den Anschluss der remote Konsole beauftragen. Aber mal im Vorfeld - was könnte dort falsch konfiguriert sein, dass so etwas passiert? Das hört sich doch eher nach einem Problem mit dem sshd oder so an, oder?

[outis]

Nun, zumindest im Intranet zickt der sshd bei mir nicht unter Jessie. Und ich möchte erwarten, dass irgendetwas in den logs auftaucht, wenn der spinnt.

[sunghost]

Hi,
bei mir auch nicht, aber ich habe meist auch Updates von Vorversionen durchgeführt und keine Neuinstallationen. Andererseits denke ich, dass wenn es ein Problem ist, auch andere dies bemerkt hätten. Eigenartig ... Ach ethtool <> logs . Ich möchte unnötige Aufträge an den Service dort vermeiden..., daher die Vorüberlegungen...

[outis]

Dann richte doch deinen Router/Client als loghost für den server ein. Dann siehst du erstens, was der so treibt. Und wenn du dann noch den server duaerhaft einen ping zu deinem Router schicken lässt oder einfacher umgekehrt, sollte die Verbindung offen bleiben. Wenn du dich dann immer per ssh verbinden kannst, weißt du spätestens, dass nicht der sshd das Problem ist.

[sunghost]

Kurze Info,
es funkt. nicht nur SSH sondern scheinbar kein Remote-Dienst. Ebenso komme ich auch nicht zz. mittels SSH vom Server nach außen ... IPTables steht, Default, auf ACCEPT und keine zztl .Regeln sind aktiv.

[rendegast]

Code: Alles auswählen

ifconfig 
ifconfig -a
route -n
brctl show
netstat -tulpen

?

Netzwerkkonfiguration per network-manager o.ä, systemd oder network/interfaces?

[sunghost]

Hi,
aktuell komme ich auf den Server, von dort mit Verzögerung in die VM, aber nicht direkt in die VM und nicht aus der VM ins WAN, aber von der VM auf den Host <- alles SSH <- ich vermute stark dass es ein Routing Thema ist ... Evtl. falscher Eintrag in der KVM Prox Konf auf dem Host ?!

Host - ifconfig -a

eth0 Link encap:Ethernet HWaddr 90:1b:0e:96:23:81
inet addr:140.201.128.137 Bcast:140.201.128.191 Mask:255.255.255.255
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1803 errors:0 dropped:0 overruns:0 frame:0
TX packets:1805 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:655616 (640.2 KiB) TX bytes:849196 (829.2 KiB)
Interrupt:16 Memory:f7000000-f7020000

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:65536 Metric:1
RX packets:1514 errors:0 dropped:0 overruns:0 frame:0
TX packets:1514 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:431266 (421.1 KiB) TX bytes:431266 (421.1 KiB)

tap100i0 Link encap:Ethernet HWaddr 12:e3:ae:ef:86:49
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:117 errors:0 dropped:0 overruns:0 frame:0
TX packets:23 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:10237 (9.9 KiB) TX bytes:3929 (3.8 KiB)

vmbr0 Link encap:Ethernet HWaddr 12:e3:ae:ef:86:49
inet addr:140.201.128.137 Bcast:140.201.128.137 Mask:255.255.255.255
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:117 errors:0 dropped:0 overruns:0 frame:0
TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:8599 (8.3 KiB) TX bytes:4183 (4.0 KiB)

VM - ifconfig -a

eth0 Link encap:Ethernet Hardware Adresse 00:50:56:00:22:79
inet Adresse:140.201.128.178 Bcast:140.201.128.178 Maske:255.255.255.255
UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1
RX packets:63 errors:8 dropped:0 overruns:0 frame:8
TX packets:294 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX bytes:9516 (9.2 KiB) TX bytes:26142 (25.5 KiB)

lo Link encap:Lokale Schleife
inet Adresse:127.0.0.1 Maske:255.0.0.0
inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine
UP LOOPBACK RUNNING MTU:65536 Metrik:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

Host - route -n

ernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 140.201.128.129 0.0.0.0 UG 0 0 0 eth0
140.201.128.128 140.201.128.129 255.255.255.192 UG 0 0 0 eth0
140.201.128.129 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
140.201.128.178 0.0.0.0 255.255.255.255 UH 0 0 0 vmbr0

Host - netstat -tulpen

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 0 11075 1707/master
tcp 0 0 0.0.0.0:5900 0.0.0.0:* LISTEN 0 18871 1963/nc6
tcp 0 0 0.0.0.0:58351 0.0.0.0:* LISTEN 103 18012 1373/rpc.statd
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 0 15945 1287/rpcbind
tcp 0 0 127.0.0.1:85 0.0.0.0:* LISTEN 0 17039 1732/pvedaemon
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 0 18257 1464/sshd
tcp6 0 0 :::3128 :::* LISTEN 33 19480 1752/spiceproxy
tcp6 0 0 ::1:25 :::* LISTEN 0 11076 1707/master
tcp6 0 0 :::37726 :::* LISTEN 103 18016 1373/rpc.statd
tcp6 0 0 :::8006 :::* LISTEN 33 17053 1743/pveproxy
tcp6 0 0 :::5900 :::* LISTEN 0 18870 1963/nc6
tcp6 0 0 :::111 :::* LISTEN 0 15948 1287/rpcbind
tcp6 0 0 :::22 :::* LISTEN 0 18259 1464/sshd
udp 0 0 0.0.0.0:111 0.0.0.0:* 0 15941 1287/rpcbind
udp 0 0 140.201.128.137:123 0.0.0.0:* 0 13254 1576/ntpd
udp 0 0 127.0.0.1:123 0.0.0.0:* 0 13253 1576/ntpd
udp 0 0 0.0.0.0:123 0.0.0.0:* 0 14975 1576/ntpd
udp 0 0 0.0.0.0:606 0.0.0.0:* 0 15944 1287/rpcbind
udp 0 0 127.0.0.1:701 0.0.0.0:* 0 10930 1373/rpc.statd
udp 0 0 0.0.0.0:43494 0.0.0.0:* 105 15931 788/systemd-timesyn
udp 0 0 0.0.0.0:44575 0.0.0.0:* 103 18010 1373/rpc.statd
udp6 0 0 :::111 :::* 0 15946 1287/rpcbind
udp6 0 0 fe80::10e3:aeff:fee:123 :::* 109 21625 1576/ntpd
udp6 0 0 fe80::98e2:cfff:fe5:123 :::* 0 13258 1576/ntpd
udp6 0 0 fe80::921b:eff:fe96:123 :::* 0 13257 1576/ntpd
udp6 0 0 2a01:4f8:172:2bc8:::123 :::* 0 13256 1576/ntpd
udp6 0 0 ::1:123 :::* 0 13255 1576/ntpd
udp6 0 0 :::123 :::* 0 14976 1576/ntpd
udp6 0 0 :::606 :::* 0 15947 1287/rpcbind
udp6 0 0 :::57354 :::* 103 18014 1373/rpc.statd

VM - route -n
[/quote]
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 140.201.128.137 0.0.0.0 UG 0 0 0 eth0
140.201.128.137 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
[/quote]
VM - netstat -tulpen

Aktive Internetverbindungen (Nur Server)
Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 0 12125 713/exim4
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 0 10383 388/rpcbind
tcp 0 0 0.0.0.0:58453 0.0.0.0:* LISTEN 106 10521 401/rpc.statd
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 0 11792 417/sshd
tcp6 0 0 ::1:25 :::* LISTEN 0 12126 713/exim4
tcp6 0 0 :::52027 :::* LISTEN 106 10527 401/rpc.statd
tcp6 0 0 :::111 :::* LISTEN 0 10386 388/rpcbind
tcp6 0 0 :::22 :::* LISTEN 0 11794 417/sshd
udp 0 0 0.0.0.0:972 0.0.0.0:* 0 10382 388/rpcbind
udp 0 0 127.0.0.1:1002 0.0.0.0:* 0 10515 401/rpc.statd
udp 0 0 0.0.0.0:111 0.0.0.0:* 0 10373 388/rpcbind
udp 0 0 0.0.0.0:49508 0.0.0.0:* 106 10518 401/rpc.statd
udp6 0 0 :::972 :::* 0 10385 388/rpcbind
udp6 0 0 :::58676 :::* 106 10524 401/rpc.statd
udp6 0 0 :::111 :::* 0 10384 388/rpcbind

Konf auf beiden mittels /interfaces

[sunghost]

Hi,
sorry die "1" nachgetragen. Ja ist die des Host.
Es scheint ein Routingthema auf dem Host zu sein. Vom Provider her ist alles i.O., laut deren Aussage. Hier noch die Netzwerkkonf laut interface des Host:

auto lo
iface lo inet loopback
iface lo inet6 loopback

# device: eth0
auto eth0
iface eth0 inet static
address 140.201.128.137
netmask 255.255.255.192
gateway 140.201.128.129
pointopoint 140.201.128.129
# default route to access subnet
up route add -net 140.201.128.128 netmask 255.255.255.192 gw 140.201.128.129 eth0

iface eth0 inet6 static
address xxx::2
netmask 64
gateway fe80::1
up sysctl -p

auto vmbr0
iface vmbr0 inet static
address 140.201.128.137
netmask 255.255.255.255
bridge_ports none
bridge_stp off
bridge_fd 0
up ip route add 140.201.128.178/32 dev vmbr0

iface vmbr0 inet6 static
address xxx::2
netmask 64

Ist das mit der Route oben bei eth0 so ok?

[rendegast]

VM - ifconfig -a
eth0 Link encap:Ethernet Hardware Adresse 00:50:56:00:22:79
inet Adresse:40.201.128.178 Bcast:140.201.128.178 Maske:255.255.255.255


VM - route -n
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 140.201.128.137 0.0.0.0 UG 0 0 0 eth0
140.201.128.137 0.0.0.0 255.255.255.255 UH 0 0 0 eth0

(bei "inet Adresse:40...." fehlte wohl eine "1")
Adresse und Route sind so normal? (...137 ist die Adresse des Host)
Maske 255 bei der Adresse ist normal?
Broadcast <-> Adresse/Maske ?
Scheint mir nicht passend, bei virtuellen Netzen habe ich aber auch nicht viel Wissen.
Und könnte ein Provider-Ding sein, habe auch noch nie einen www-Server gehabt.



Dito Host

Host - ifconfig -a
eth0 Link encap:Ethernet HWaddr 90:1b:0e:96:23:81
inet addr:140.201.128.137 Bcast:140.201.128.191 Mask:255.255.255.255
...
vmbr0 Link encap:Ethernet HWaddr 12:e3:ae:ef:86:49
inet addr:140.201.128.137 Bcast:140.201.128.137 Mask:255.255.255.255

<->

Host - route -n
0.0.0.0 140.201.128.129 0.0.0.0 UG 0 0 0 eth0
140.201.128.128 140.201.128.129 255.255.255.192 UG 0 0 0 eth0
140.201.128.129 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
140.201.128.178 0.0.0.0 255.255.255.255 UH 0 0 0 vmbr0

wieder Broadcast <-> Adresse/Maske,
Broadcast würde passen zu Adresse/255.255.255.192.
Beim routing blicke ich nicht durch.




EDIT, ah, zwischenzeitlicher Beitrag.
Das Adresse/255.255.255.255 beim Host kommt durch die Einstellung der vmbr0.

Code: Alles auswählen

pointopoint 140.201.128.129
# default route to access subnet
up route add -net 140.201.128.128 netmask 255.255.255.192 gw 140.201.128.129 eth0

da klinke ich mich besser aus.

[sunghost]

Hallo,
das Problem ist gelöst. Wie so immer eine kleine Sache mit großer Auswirkung. Ich habe irendwann in diesem Konfigurationsnirvana eine MAC für die 2. IP angefordert und erhalten. Da diese aber wohl nur für die Konfiguration der Bridge benötigt wird und fest im Switch verankert wird, konnte die Konfiguration als Routed nicht funktionieren. Nachdem ich gestern die MAC entfernen lies, läuft das / die System -e stabil und so wie es sein soll. An dieser Stelle möchte ich mich bei allen die hier geholfen und versucht das Problem zu lösen haben, bedanken - Danke