Server scheint zu schlafen

[scientific]

Hi Leute!

Ich habe bei Hetzner ein paar Server im Betrieb. Und irgendwie seltsame Phänomene...
Alle Server laufen mit Debian stretch und sind V-Server in der "Cloud".

Ein Server ist ein VPN-Server, und alle sind mittels openVPN zu einem Netz zusammengeschlossen.

Jetzt habe ich auf einem Server das Phänomen, dass er zeitweise nicht erreichbar ist. Kein Ping, keine ssh, kein Web kommt zu dem Server durch. nmap zeigt, auch nix an.

Code: Alles auswählen

nmap cloud.bei.hetzner

Starting Nmap 7.60 ( https://nmap.org ) at 2018-10-26 03:04 CEST
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.17 seconds

Gehe ich über die Webconsole auf den Rechner, so ist dieser ganz normal up. ip addr gibt mir die korrekten IP-Adressen (inklusive der VPN-Adresse) aus, ip route zeigt, dass die Routen korrekt sind. Und systemctl status openvpn-client@server.service zeigt, dass auch der openvpn-Client ordnungsgemäß läuft.

Aber surfe ich die Website an, die dieser Server serviert, kommt im Browser ein Timeout. Versuche ich eine ssh-Verbindung -> Timeout. Telnet auf port 119, wo der Newsserver lauscht -> timeout.

Und auf einmal, nach zwei, drei Minuten der Verbindungsversuche - ohne Neustart irgend eines Services, erreiche ich plötzlich wieder alle Services wie gewohnt.

Dann bin ich länger (für 2, 3 Stunden) ohne Zugriff auf den Server und versuche es erneut, das selbe Spiel von vorne. Der Server ist über das Netzwerk verschwunden, aber von der Remote-Console aus erreichbar. Alle Dienste laufen, IP-Adressen, Routen passen... und nach ein wenig Aktivität am Server sind auch die Dienste von außen wieder erreichbar...

Das ganze passiert aber nur mit einem Server. Alle anderen funktionieren ordnungsgemäß.

Und bevor ich mich an den Support wende, möchte ich gerne ein wenig Erkundungen einholen, was das für ein Problem sein könnte... Hab ich meinen Server fehlkonfiguriert? Oder liegt es eventuell am Rechenzentrum? Werden die IP-Pakete vom Host auf dem der V-Server läuft, nicht richtig weitergeleitet? Schläft ein Switch bei Hetzner?

Ich habe dieses Spiel heute sicher 4 Mal gespielt.

lg scientific

[scientific]

Ach ja...

Wenn der Server schläft, kommt obiges Ergebnis von nmap.

Wenn ich dann wie vorgeschlagen die Option nmap -nP verwende, zeigt sich das:

Code: Alles auswählen

~: $ sudo nmap -Pn cloud.schuerz.at

Starting Nmap 7.60 ( https://nmap.org ) at 2018-10-26 03:05 CEST
Nmap scan report for cloud.schuerz.at (10.0.100.5)
Host is up (0.023s latency).
rDNS record for 10.0.100.5: cloud.vpn
Not shown: 990 filtered ports
PORT      STATE  SERVICE
4/tcp     closed unknown
42/tcp    closed nameserver
1007/tcp  closed unknown
1060/tcp  closed polestar
1062/tcp  closed veracity
1091/tcp  closed ff-sm
1114/tcp  closed mini-sql
2009/tcp  closed news
8873/tcp  closed dxspider
27000/tcp closed flexlm0

Nmap done: 1 IP address (1 host up) scanned in 191.72 seconds

Wenn der Server wieder aufgewacht ist, dann sehe ich dieses Ergebnis:

Code: Alles auswählen

~: $ sudo nmap -Pn cloud.bei.hetzner
Starting Nmap 7.60 ( https://nmap.org ) at 2018-10-26 03:22 CEST
Nmap scan report for cloud.schuerz.at (10.0.100.5)
Host is up (0.026s latency).
rDNS record for 10.0.100.5: cloud.vpn
Not shown: 996 closed ports
PORT    STATE SERVICE
22/tcp  open  ssh
80/tcp  open  http
111/tcp open  rpcbind
443/tcp open  https

Nmap done: 1 IP address (1 host up) scanned in 1.64 seconds

welches dann auch die korrekten Ports zeigt.

Schaut fast so aus, als ob die Namensauflösung auf einen anderen Server zeigt... aber das tut sie nicht. dig cloud.bei.hetzner gibt mir die korrekte IP-Adresse des VPN aus. Auch die public-IP passt.
Dann vermute ich, dass ich einen Konflikt bei der zugewiesenen IP-Adresse habe. Dass da ein zweiter Rechner mit der selben public IP herumgeistert...

[scientific]

Hab noch etwas weiter nachgebohrt. Offenbar ist der Server nur über VPN nicht erreichbar. Da ich daheim meinem Router auch eine Route ins VPN gegeben habe, kann ich vom LAN aus auch die Server des VPN erreichen. Das hab ich bei meiner Analyse gestern nicht bedacht.

Das heißt, wenn ich den Laptop über mein Smartphone ins Netz lasse, so kann ich den Cloud-Server sehr wohl erreichen. Auch per ssh.

Starte ich den openvpn-client auf dem Cloud-Server neu, so ist der auch wieder über VPN erreichbar...

Ich versteh nicht, wieso openvpn nur auf diesem einen Server immer ausfällt. Scheint mit den TLS-soft resets zu tun zu haben. Ich habe auch im Log fast alle Stunden so ein Soft-Reset... Eigentlich müsste es ja wirklich jede Stunde sein

Code: Alles auswählen

~/nc: (cloud-sc) $ sudo journalctl -b|grep "soft reset"
Oct 23 01:05:49 cloud openvpn[20827]: TLS: soft reset sec=0 bytes=199237336/-1 pkts=459936/0
Oct 23 02:05:49 cloud openvpn[20827]: TLS: soft reset sec=0 bytes=3839179447/-1 pkts=4310666/0
Oct 23 04:05:49 cloud openvpn[20827]: TLS: soft reset sec=0 bytes=3361724031/-1 pkts=3647518/0
Oct 23 09:06:30 cloud openvpn[16871]: TLS: soft reset sec=0 bytes=1982496/-1 pkts=6427/0
Oct 23 10:06:30 cloud openvpn[16871]: TLS: soft reset sec=0 bytes=1715565/-1 pkts=7064/0
Oct 23 11:06:30 cloud openvpn[16871]: TLS: soft reset sec=0 bytes=2826587/-1 pkts=11019/0
Oct 23 12:06:30 cloud openvpn[16871]: TLS: soft reset sec=0 bytes=2802603/-1 pkts=10678/0
Oct 23 14:06:30 cloud openvpn[16871]: TLS: soft reset sec=0 bytes=2040307/-1 pkts=8150/0
Oct 23 16:06:30 cloud openvpn[16871]: TLS: soft reset sec=0 bytes=2896981/-1 pkts=11243/0
Oct 23 17:06:30 cloud openvpn[16871]: TLS: soft reset sec=0 bytes=2425143/-1 pkts=9385/0
Oct 23 18:06:30 cloud openvpn[16871]: TLS: soft reset sec=0 bytes=2732033/-1 pkts=6944/0
Oct 23 19:06:33 cloud openvpn[16871]: TLS: soft reset sec=-1 bytes=3603756/-1 pkts=11653/0
Oct 23 20:06:36 cloud openvpn[16871]: TLS: soft reset sec=-1 bytes=180/-1 pkts=3/0
Oct 23 21:06:37 cloud openvpn[16871]: TLS: soft reset sec=0 bytes=180/-1 pkts=3/0
Oct 23 23:06:44 cloud openvpn[16871]: TLS: soft reset sec=0 bytes=112/-1 pkts=2/0
Oct 24 00:06:44 cloud openvpn[16871]: TLS: soft reset sec=0 bytes=180/-1 pkts=3/0
Oct 24 03:06:52 cloud openvpn[16871]: TLS: soft reset sec=0 bytes=112/-1 pkts=2/0
Oct 24 05:07:00 cloud openvpn[16871]: TLS: soft reset sec=0 bytes=25542230/-1 pkts=87575/0
Oct 24 08:07:08 cloud openvpn[16871]: TLS: soft reset sec=0 bytes=2861316/-1 pkts=9136/0
Oct 25 03:07:28 cloud openvpn[16871]: TLS: soft reset sec=0 bytes=112/-1 pkts=2/0
Oct 25 04:07:30 cloud openvpn[16871]: TLS: soft reset sec=0 bytes=213093/-1 pkts=778/0
Oct 25 07:07:37 cloud openvpn[16871]: TLS: soft reset sec=0 bytes=112/-1 pkts=2/0
Oct 25 08:07:37 cloud openvpn[16871]: TLS: soft reset sec=0 bytes=1840/-1 pkts=26/0
Oct 25 10:07:45 cloud openvpn[16871]: TLS: soft reset sec=0 bytes=256/-1 pkts=4/0
Oct 25 11:07:47 cloud openvpn[16871]: TLS: soft reset sec=0 bytes=3727802/-1 pkts=7046/0
Oct 25 18:08:00 cloud openvpn[16871]: TLS: soft reset sec=0 bytes=112252/-1 pkts=440/0
Oct 25 22:08:09 cloud openvpn[16871]: TLS: soft reset sec=-1 bytes=2311777/-1 pkts=5453/0
Oct 25 23:08:10 cloud openvpn[16871]: TLS: soft reset sec=-1 bytes=112/-1 pkts=2/0
Oct 26 05:08:22 cloud openvpn[16871]: TLS: soft reset sec=0 bytes=180/-1 pkts=3/0
Oct 26 07:08:30 cloud openvpn[16871]: TLS: soft reset sec=0 bytes=112/-1 pkts=2/0
Oct 26 09:08:35 cloud openvpn[16871]: TLS: soft reset sec=0 bytes=3845/-1 pkts=40/0
Oct 26 10:13:17 cloud openvpn[2032]: TLS: soft reset sec=0 bytes=2771120/-1 pkts=10145/0
Oct 26 12:13:22 cloud openvpn[2032]: TLS: soft reset sec=0 bytes=109135/-1 pkts=403/0
Oct 26 13:13:22 cloud openvpn[2032]: TLS: soft reset sec=0 bytes=119217/-1 pkts=442/0
Oct 26 15:35:07 cloud openvpn[7950]: TLS: soft reset sec=0 bytes=1132481/-1 pkts=4810/0
Oct 26 16:35:07 cloud openvpn[7950]: TLS: soft reset sec=0 bytes=1041803/-1 pkts=4654/0
Oct 26 17:35:07 cloud openvpn[7950]: TLS: soft reset sec=0 bytes=1487912/-1 pkts=6349/0
Oct 26 19:35:07 cloud openvpn[7950]: TLS: soft reset sec=0 bytes=1141559/-1 pkts=4879/0

Für heute würde es gut passen, dass immer bei den ausgefallenen Soft-Resets der Server danach dann nicht mehr erreichbar war... Muss ich näher beobachten.
Ich frage mich aber, warum das so ist? Warum sind nicht wirklich alle Stunden diese Soft-Resets, und warum ist nach einem ausgefallenen der Server von außen nicht mehr übers VPN erreichbar?

lg scientific

[scientific]

Andererseits... Jetzt hab ich live mitgeschaut:

Code: Alles auswählen

Oct 26 20:35:07 cloud openvpn[7950]: VERIFY OK: depth=1, C=AT, ST=NOE, L=Tulln an der Donau, O=Xunde Energie, OU=IT, CN=Xunde Energie CA, name=Xunde Energie OpenVPN-Server, emailAddress=jakob@schuerz.at
Oct 26 20:35:07 cloud openvpn[7950]: Validating certificate key usage
Oct 26 20:35:07 cloud openvpn[7950]: ++ Certificate has key usage  00a0, expects 00a0
Oct 26 20:35:07 cloud openvpn[7950]: VERIFY KU OK
Oct 26 20:35:07 cloud openvpn[7950]: Validating certificate extended key usage
Oct 26 20:35:07 cloud openvpn[7950]: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Oct 26 20:35:07 cloud openvpn[7950]: VERIFY EKU OK
Oct 26 20:35:07 cloud openvpn[7950]: VERIFY OK: depth=0, C=XX, ST=XXX, L=XXXXX, O=XXXX, OU=IT, CN=server, name=XXXXX OpenVPN-Server, emailAddress=XX@XXXXXX
Oct 26 20:35:07 cloud openvpn[7950]: WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1569', remote='link-mtu 1570'
Oct 26 20:35:07 cloud openvpn[7950]: WARNING: 'comp-lzo' is present in remote config but missing in local config, remote='comp-lzo'
Oct 26 20:35:07 cloud openvpn[7950]: Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key
Oct 26 20:35:07 cloud openvpn[7950]: Data Channel Decrypt: Cipher 'AES-256-GCM' initialized with 256 bit key
Oct 26 20:35:07 cloud openvpn[7950]: Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA

Kein Soft-Reset... und der Server ist trotzdem noch erreichbar...

[scientific]

Hab mal die penvpn-clientconfig auf dem betreffenden Server erneuert.

Jetzt hat er die Verbindung bis jetzt nicht mehr verloren...