VPS inaccessible et les services ne répondent plus
BMPCreated with Sketch.BMPZIPCreated with Sketch.ZIPXLSCreated with Sketch.XLSTXTCreated with Sketch.TXTPPTCreated with Sketch.PPTPNGCreated with Sketch.PNGPDFCreated with Sketch.PDFJPGCreated with Sketch.JPGGIFCreated with Sketch.GIFDOCCreated with Sketch.DOC Error Created with Sketch.
question

VPS inaccessible et les services ne répondent plus

K
Par
KevinC27
Créé le 2023-03-24 08:13:57 (edited on 2024-09-04 12:16:25) dans Serveurs Privés Virtuels (VPS)

Bonjour,
J'ai un VPS (1vCore, 2Go de mémoire, 40Go de stockage) qui tourne sous Debian 11.

Depuis quelques semaines, tous les jours, à heures différentes, le VPS devient inaccessible (connexion SSH impossible), et les services le sont aussi (notamment les services web, les sites sont HS).
Je dois systématiquement redémarrer le VPS pour relancer tout ça. Je ne sais pas si avec le KVM le serveur est accessible, je n'ai pas essayé.

J'ai mis en place un monitoring en place sur un site, et voici ce qu'il retourne (je ne sais pas si ça peut aider mais bon):

Tracing route to 51.68.70.221
hop no - node ip - ms
1 → 69.162.77.249(2 ms)
2 → 63.143.63.1(160 ms)
3 → 51.68.70.221(15000 ms) Request timed out
4 → 51.68.70.221(15000 ms) Request timed out
5 → 184.105.11.129(1 ms)
6 → 206.223.118.119(3 ms)
7 → 51.68.70.221(15000 ms) Request timed out

Voici un listing des services :

UNIT LOAD ACTIVE SUB DESCRIPTION
apache2.service loaded active running The Apache HTTP Server
chrony.service loaded active running chrony, an NTP client/server
cron.service loaded active running Regular background program processing daemon
dbus.service loaded active running D-Bus System Message Bus
fail2ban.service loaded active running Fail2Ban Service
getty@tty1.service loaded active running Getty on tty1
mariadb.service loaded active running MariaDB 10.5.18 database server
packagekit.service loaded active running PackageKit Daemon
php8.2-fpm.service loaded active running The PHP 8.2 FastCGI Process Manager
polkit.service loaded active running Authorization Manager
qemu-guest-agent.service loaded active running QEMU Guest Agent
rsyslog.service loaded active running System Logging Service
serial-getty@ttyS0.service loaded active running Serial Getty on ttyS0
snapd.service loaded active running Snap Daemon
ssh.service loaded active running OpenBSD Secure Shell server
supervisor.service loaded active running Supervisor process control system for UNIX
systemd-journald.service loaded active running Journal Service
systemd-logind.service loaded active running User Login Management
systemd-udevd.service loaded active running Rule-based Manager for Device Events and Files
unattended-upgrades.service loaded active running Unattended Upgrades Shutdown
user@1001.service loaded active running User Manager for UID 1001

Ces incidents ont commencé le 13/03/2023, et se produisent 1 fois par jour depuis, à une heure différente à chaque fois.
Le 13/03/2023, et même avant, aucun changement sur la structure n'a été fait.

Je ne sais pas trop d'où cela vient, j'aimerai avoir vos avis. D'où est-ce que le problème pourrait venir ? Quelles actions puis-je mettre en place pour connaître l'origine de ce problème ?

Merci par avance aux personnes qui prendront part à ce sujet.

Kévin.
Avis positifs (0)
784 Vues
3 réponses ( Latest reply on 2023-03-24 09:52:47 Par
Sich
)


Je ne sais pas trop d'où cela vient


Bonjour,

Il y a eu plusieurs discussions ici sur un problème lié à DHCP après 24 heures, la solution a été de mettre une IP fixe qui correspond au bail DHCP que vous recevez.

Il faudrait un peu chercher dans les conversations précédentes.

Ou bien alors c'est un problème d'épuisement des ressources mémoire de votre VPS, qui s'écroule car on ne met habituellement pas de swap sur un VPS.
Utile (0)


Il y a eu plusieurs discussions ici sur un problème lié à DHCP après 24 heures, la solution a été de mettre une IP fixe qui correspond au bail DHCP que vous recevez.


Oui avec DHCP et surtout les paramétrages FW qui doivent permettre le renouvellement DHCP.

Ma Proc Debian pour l'IP Fixe

==Récupérer les infos==

ip route

->

default via 94.23.6.254 dev eno1 onlink 
94.23.6.0/24 dev eno1 proto kernel scope link src 94.23.6.55


On en déduit que

* Nom de la carte : eno1
* adresse IP : 94.23.6.55
* gateway : 94.23.6.254
* masque : 255.255.255.0

==suppression cloud-init==

apt remove cloud-init
rm -f /etc/network/interfaces.d/50-cloud-init


==Fichier de configuration ip principale==

nano /etc/network/interfaces.d/50-debian

->

auto lo
iface lo inet loopback

auto eno1
allow-hotplug eno1
iface eno1 inet static
    address 94.23.6.55
    netmask 255.255.255.0
    gateway 94.23.6.254
    dns-nameserver 1.1.1.1
    dns-nameserver 8.8.8.8


==Ajouter des IP failover==

nano /etc/network/interfaces.d/99-failover

->

auto eno1:1
iface eno1:1 inet static
    address 87.98.189.55
    netmask 255.255.255.255
    broadcast 87.98.189.55

auto eno1:2
iface eno1:2 inet static
    address 178.32.156.55
    netmask 255.255.255.255
    broadcast 178.32.156.55


On redémarre

reboot



= Optionnellement, désactiver IPV6=

Vérifier que IPV6 est activé
 ip a | grep inet6


Création du fichier de config
 echo "net.ipv6.conf.all.disable_ipv6 = 1" > /etc/sysctl.d/70-disable-ipv6.conf


Prise en compte live
 sysctl -p -f /etc/sysctl.d/70-disable-ipv6.conf


Vérification
 ip a | grep inet6



> Ou bien alors c'est un problème d'épuisement des ressources mémoire de votre VPS, qui s'écroule car on ne met habituellement pas de swap sur un VPS

C'est certainement le plus probable si l'heure du HS est toujours différente.
Regardez les log auth et apache pour le savoir, mettez en place un outil de monitoring pour voir les ressources qui manques avant le downtime .
Avez vous des produits sécu installés ? (Fail2ban, Crowdsec etc...)
Utile (0)

Le DHCP est probablement le motif le + pertinent.
Sinon voir si il y a un backup automatique, ça peut planter une machine si ça prends trop de temps, et c'es tjrs dans la même tranche horaire (voir panel pour ça).
Utile (0)

Sujets apparentés

Rejoindre la discussion