Skip to content

Comment réparer l'erreur "Réinitialisation de connexion par pair"

L'erreur "Réinitialisation de la connexion par l'homologue" se produit tout au long d'une connexion réseau lorsque l'autre extrémité ou le serveur ferme la connexion sans vérifier les données déplacées. Le pair renverra certainement le paquet de données que vous avez envoyé lors de l'envoi du bit RST (réinitialisation) et mettra également fin de force à la connexion.

Ce problème survient généralement si vous êtes gêné par le pare-feu sur n'importe quel point de l'itinéraire. Cependant, cela peut aussi arriver pour diverses autres raisons. Dans ce court article, nous expliquons diverses raisons de l'erreur ainsi que la façon dont vous pouvez la résoudre dans chaque situation.

Causes de la réinitialisation de la connexion par un pair

Voici quelques-unes des raisons potentielles de l'erreur "Connection reset by peer":

  • Accès bloqué par pare-feu ou fichier hosts.
  • Votre adresse IP est interdite sur le serveur Web hôte.
  • Les paramètres du serveur ont été modifiés sans redémarrer les démons.
  • Durée de temporisation faible pour le lien.
  • Serveur occupé avec des liens optimaux.
  • Bugs dans le programme utilisé pour établir la connexion.

Comment réparer la réinitialisation de la connexion par pair

Tout d'abord, assurez-vous que votre système n'est pas aussi bien actif. Si vous utilisez beaucoup le processeur, la mémoire ou le réseau, vous rencontrerez des problèmes lors de l'établissement d'un tout nouveau lien.

Essayez également de redémarrer la session et de réessayer d'établir la connexion. Après cela, passez à la solution possible que nous avons fournie ci-dessous.

La plupart des actions que nous avons signalées sont destinées à un serveur Linux basé sur Debian Si vous avez n'importe quel type d'autre système, vous pouvez utiliser des actions comparables en recherchant sur le Web la procédure exacte. Certaines commandes varient également entre les différents systèmes Linux. Alors faites également attention à ceux-là.

Vérifier les journaux

Tout d'abord, vous devez examiner les journaux ou les messages d'erreur pour limiter la raison de l'erreur.

Si vous avez accès au serveur, vous pouvez également examiner les journaux côté serveur.

Par exemple, si vous rencontrez ce problème lors de la configuration d'une connexion ssh, vous devez vérifier le fichier / var/log/auth. journaliser les documents. Faire cela,

  1. Ouvrez la borne.
  2. Entrer tail -f /var/log/auth.log

Il révèle les informations de journalisation envoyées par le démon SSH tout au long des tentatives de vérification de votre système distant.

Vérifier la connectivité Internet ainsi que le routage

La prochaine chose que vous devez faire est de rechercher les problèmes de connectivité Internet. Vous pouvez vérifier si le serveur public ou exclusif a diminué en utilisant la recherche IP ou des sites Internet comparables.

Vous pouvez également utiliser l'utilisation traceroute ou tracert pour tracer le chemin entre les deux points de terminaison et vérifier quel accès au point réinitialise votre connexion. La syntaxe est :

  • Sous Linux : traceroute [domain/IP]
  • Sous Windows : tracert [domain/IP]

Si le serveur Web public ou les points d'accès sont en panne, vous devez attendre qu'ils soient à nouveau opérationnels. En cas de problème avec le serveur privé, vous pouvez contacter l'administrateur système ou le réactiver si vous y avez accès.

Vérifier l'interdiction IP

L'une des principales raisons de ce problème lors de la connexion à des serveurs Web publics est que votre adresse IP est mise sur liste noire par les principaux fournisseurs de services de sécurité. La majorité des serveurs Web publics interdisent les adresses IP tout en se conformant à la source de données de ces serveurs Web.

Pour vérifier si votre adresse IP est sur liste noire,

  1. Ouvrez le Page du super outil de la boîte à outils MX
  2. Définissez la case de chute jaune sur Blacklist Check.
  3. Entrez votre adresse IP dans la boîte de message et cliquez sur Vérification de la liste noire. Si vous ne connaissez pas votre adresse IP, recherchez "Quelle est mon IP" sur Google.

Si votre adresse IP est sur liste noire sur plusieurs réseaux de sécurité, ou sur des réseaux essentiels comme BARRACUDA, BLOCKLIST.DE, Nordspam BL, etc., de nombreux serveurs Web ou filtres de protection vous proscriront certainement également.

La seule chose que vous pouvez faire est de discuter avec votre FAI et de le faire parler à l'administrateur du serveur Web pour supprimer l'interdiction.

Vous pouvez également essayer de transformer votre adresse IP à l'aide d'un VPN pour contourner ce problème.

Vérifiez le pare-feu ainsi que les filtres de sécurité réseau

L'erreur "Réinitialisation de la connexion par l'homologue" se produit principalement lorsque les pare-feu bloquent l'accès au serveur.

Si vous avez accès au serveur exclusif auquel vous essayez de vous connecter, vous pouvez vérifier si le logiciel pare-feu bloque réellement l'accès à votre adresse IP. Pour le faire sous Linux,

  1. Ouvrir la borne
  2. Entrer sudo iptables -L – line-number
  3. Vérifiez les efforts de vérification de votre adresse IP et examinez également si la cible approuve ou refuse la connexion.

Vous pouvez également vérifier les autres filtres de sûreté et de sécurité proposé sur le serveur. Les actions peuvent varier selon les programmes particuliers, alors consultez le site principal ou les documents pour les techniques.

Ensuite, vous devez liste blanche votre adresse IP sur les applications d'évitement de violation telles que Fail2ban, DenyHosts, etc., pour faire des exceptions aux règles du pare-feu. Les étapes requises pour le faire sur Fail2ban sont les suivantes :

  1. Ouvrez le terminal et entrez dans sudo nano /etc/fail2ban/jail.conf
  2. Supprimez le symbole # devant ignoreip = et ajoutez également les adresses IP que vous désirez sur la ligne.
  3. Pour les circonstances, la ligne peut être ignoreip = 10.10.10.8
  4. Sauvegardez et partez également.

Avertissement: Des pratiques telles que la désactivation du pare-feu ou l'exemption pour toutes les adresses IP sur le pare-feu ne sont pas recommandées. Des programmes pare-feu ainsi que des filtres de sécurité existent pour sécuriser votre système. Ainsi, au lieu de compromettre la sûreté et la sécurité, il est préférable de rechercher une solution de contournement.

Redémarrer les services et aussi les démons

Si vous rencontrez ce problème sur un réseau personnel, il est possible que l'administrateur du serveur ait modifié les directives de connexion sans réactiver les solutions démon. Cela provoque le blocage des démons de solution car ils sont toujours destinés à satisfaire les configurations précédentes.

  1. Contactez le gestionnaire du serveur Web et demandez également à redémarrer la solution ainsi que les démons dans telle situation.
  2. Si vous avez accès au serveur Web, vous pouvez le faire vous-même. Initialement, vérifier que les services ainsi que les démons fonctionnent utilisant systemctl commande.
  3. Redémarrez les démons appropriés. La commande dont vous avez besoin pour cette procédure dans un système basé sur Debian est
    sudo systemctl restart “daemon name”

Par exemple, si vous configurez un lien FTP en utilisant le partage samba, vous devez utiliser la commande sudo systemctl restart smbd Étant donné que le service SSH est facilement disponible sur presque toutes les distributions de Linux, vous n'avez pas besoin de configurer un type de package de solution pour celui-ci. Ainsi, pour la connexion SSH, la commande est sudo systemctl restart ssh

Et si vous utilisez divers autres services de stockage pour établir le lien, vous devez également redémarrer leurs démons.

Modifier le fichier d'hôtes

Les données des hôtes vous permettent d'autoriser ou de refuser l'accès à des adresses IP ou des noms d'hôtes particuliers. Si vous avez accès au serveur Web, vous devez en outre vérifier ces documents et vous assurer également que votre adresse IP peut établir un lien avec le serveur.

Pour ce faire pour un système Debian,

  1. Ouvrez le terminal et entrez sudo nano /etc/hosts.deny
  2. Recherchez votre adresse IP régionale ou votre nom d'hôte sur les documents.
  3. S'il est là, commentez-le en saisissant # avant la ligne. Vous pouvez également vous débarrasser complètement de la ligne.

Vous pouvez également ajoutez votre adresse IP sur le hosts.allow soumettre pour exiger le lien. La procédure est similaire à ce qui précède.

  1. Ouvrez le terminal et entrez dans sudo nano /etc/hosts.allow
  2. Entrez votre adresse IP en utilisant la structure de phrase est daemon_list : client_list [: command]
  3. Sauvegarde et départ.

Le démon pour FTP est généralement vsftpd ainsi que pour ssh, scp, et aussi sftp est sshd. Donc, pour activer la connexion ssh avec l'adresse du quartier, 10.10.10.8vous devez ajouter sshd : 10.10.10.8 , LOCAL

Il est en outre possible de modifier le fichier hosts sur un serveur Web basé sur Windows. Vous pouvez vous référer à notre article sur la modification des hôtes soumis sur Windows pour en savoir plus sur le processus nécessaire.

Augmenter le délai d'attente ou envoyer des paquets Keepalive

De nombreux périphériques réseau interrompent les connexions TCP et FTP inactives après une certaine période d'inactivité.

Il existe 2 façons d'arrêter ce problème :

  • Augmentez la durée du délai d'attente.
  • Envoyez des informations régulières sur les battements de cœur.

Le premier choix n'est pas une bonne option. Maintenir le délai d'attente longtemps peut influencer les liens du serveur vers divers autres réseaux car ils doivent attendre plus longtemps avant d'essayer d'établir un lien. Vous devez également augmenter le délai d'attente aux deux extrémités, ce qui n'est pas toujours possible.

Donc, la meilleure solution est de envoyer régulièrement des paquets heartbeat ou keepalive Cela empêche la connexion d'être inactive et maintient la session active pendant une période plus longue.

Certaines connexions permettent d'envoyer des packages keepalive, mais vous devez autoriser ce processus pour les autres. Voici comment vous pouvez activer la procédure d'envoi de tels colis :

Sous Linux

  1. Ouvrez le terminal et entrez sudo nano /etc/sysctl.conf
  2. Ajoutez les lignes conformes tout en modifiant les valeurs (en secondes) selon vos préférences :
    • net.ipv4.tcp_keepalive_time = 300
    • net.ipv4.tcp_keepalive_probes = 9
    • net.ipv4.tcp_keepalive_intvl = 10
  3. Économisez ainsi que congé.
  4. Entrez la commande sysctl – load=/etc/sysctl.conf

Les lignes over définissent que le système attend 300 secondes avant d'envoyer le premier paquet keepalive. Ensuite, il continue d'envoyer le paquet toutes les 10 secondes. S'il n'obtient pas ACK (reconnaissance) pendant 9 fois successives, la connexion est interrompue.

L'augmentation de la période Keepalive pour les liens SSH peut mettre en danger la sécurité car elle reste ouverte plus longtemps. Ce lien est censé être vraiment protégé, il n'est donc pas conseillé de faire des ajustements aux configurations keepalive pour ssh.

Sous Windows

  1. Ouvrez Run et entrez regedit
  2. Aller vers ComputerHKEY_LOCAL_MACHINESystemCurrentControlSetServicesTcpipParameters
  3. Clic-droit Paramètres
  4. Ajoutez l'accès DWORD conforme avec les valeurs respectives (en millisecondes) à votre guise :
    • KeepAliveTime-- 300000 (en décimal)
    • KeepAliveInterval-- 1000
  5. Pour inclure un accès, faites un clic droit sur Paramètre, sélectionnez Nouveau > > Valeur DWORD (32 bits) et entrez le nom.
  6. Ensuite, double-cliquez sur l'accès pour transformer ses données de valeur.

Noter: Vous devez également rendre possible les paquets TCP keepalive dans votre client TCP/FTP.

Vérifier le fichier sshd_config

Les documents sshd_config configurent toutes les configurations utilisées par une connexion SSH (Secure Shell). Donc, de préférence, vous devez vérifier ces documents sur le serveur Web et vous assurer que tout va bien.

  1. Ouvrez les données en utilisant la commande sudo nano /etc/ssh/sshd_config
  2. Regardez les alternatives que nous avons fournies ci-dessous et modifiez-les si nécessaire. Vous pouvez également transformer divers autres choix en fonction de votre lien. Nous vous conseillons de consulter la documentation de sshd_config pour en savoir plus.
  3. Après avoir modifié ces valeurs, enregistrez et quittez également.
  4. Redémarrez sshd à l'aide de la commande sudo systemctl restart ssh

Certains des choix sont :

MaxStartups

La valeur MaxStartups calcule le nombre optimal de connexions non authentifiées possibles au démon SSH avant que les connexions ne commencent à tomber.

Il a la disposition MaxStartups 10:30:100où,

  • 10 : Nombre de liens non authentifiés au début de la panne
  • 30 : Probabilité de chute après avoir atteint le nombre maximum de personnes non authentifiées
  • 100 : nombre maximum de liens possibles avant de supprimer chacun d'eux

Si votre client distant a besoin de faire encore plus de connexions simultanément, vous devez modifier ces valeurs.

Sous-système sftp

Sur un lien FTP sûr et sécurisé utilisant le plan openssh, la valeur par défaut de sftp du sous-système est définie sur /usr/lib/openssh/sftp-server Cependant, occasionnellement, le binaire openssh est facilement disponible sur /usr/lib/ssh/sftp-server Au lieu. Vous pouvez donc modifier cette valeur et vérifier si elle fonctionne. Si ce n'est pas le cas, remplacez-le par le chemin précédent.

ClientAlive

ClientAlive est une configuration keepalive plus sûre. Vous pouvez modifier les valeurs ClientAliveInterval et ClientAliveCountMax dans sshd_config pour permettre cette configuration.

ClientAliveInterval détermine la période d'absence d'exercice après laquelle sshd envoie un message crypté au client. Et ClientAliveCountMax établit un nombre limite de fois où sshd envoie ce message avant de descendre le lien s'il n'obtient aucun type de réaction.

Vérifier la prise en charge de SSL

Si le serveur hôte a activé SSL (Secure Sockets Layer) mais que vous n'avez pas autorisé cette solution de votre côté, vous ne pouvez pas établir de connexion.

Donc, vous devez vérifier la prise en charge de SSL sur votre TCP ou tout autre type de client réseau et l'activer également. S'il ne prend pas en charge SSL, vous devez faire appel à un autre client.

Vous devez également vérifier vos certifications et vous assurer que vous n'avez pas d'astuces ou de certifications difformes.

Modifier la limite de connexion ouverte

L'établissement d'une connexion réseau produit également une prise, qui est la fenêtre d'accueil logique que le client utilise pour communiquer avec le serveur. Néanmoins, un serveur a une limite sur le nombre de points de vente qu'il peut ouvrir en même temps.

Si le serveur a actuellement atteint cette restriction, tout type de nouveau lien incite le serveur Web à supprimer les anciennes connexions inactives. Vous pouvez revitaliser ou réactiver la session pour restaurer la session. Néanmoins, vous pouvez également augmenter la limitation côté serveur pour favoriser des connexions encore plus ouvertes.

Si vous souhaitez modifier la restriction pour la session en cours uniquement, vous pouvez utiliser la commande ulimit -n 65535tout en remplaçant le numéro en fonction de vos besoins.

Pour le modifier complètement,

  1. Ouvrez le terminal et allez également dans sudo nano /etc/security/limits.conf
  2. Ajoutez les lignes de respect tout en modifiant la valeur de la limite si vous le souhaitez :
    • * soft nofile 65535
    • * hard nofile 65535
  3. Enregistrer ainsi que quitter. Après cela, redémarrez les démons ainsi que la session.

Pour les systèmes Debian et Ubuntu, vous devez également activer les limites client PAM. Faire cela,

  1. Entrez sudo nano /etc/pam.d/common-session
  2. Ajouter required pam_limits.so
  3. Ajouter cette commande sur /etc/pam.d/common-session-noninteractive aussi.
  4. Si vous utilisez un lien SSH, incluez la ligne pour /etc/pam.d/sshd

Déboguez vos scripts et aussi les configurations

De nombreux clients ont rencontré ce problème lors du développement de leurs propres applications de connexion. Dans une telle situation, tout parasite dans les scripts ou la configuration qui ferme inutilement le lien ou n'adapte pas le lien avec la procédure déclenchera certainement cette erreur.

Nous vous conseillons donc de parcourir méticuleusement le programme. Certains protocoles ont quitter ou fermer des commandes qui oblige le serveur hôte à fermer le lien.

Vous devez en plus fermer toutes les procédures enfant dérivées avant de quitter pour empêcher les processus zombies. Les raffinements de zombies restent dans la table de procédure même après avoir terminé l'enfant. S'il y a beaucoup de procédures zombies, la table des procédures est complète. De cette manière, le système cesse de fonctionner pour produire de nouvelles procédures, interférant avec la connexion.

Si vous avez des problèmes pour déboguer votre programme, nous vous suggérons d'obtenir de l'aide de forums de discussion technologiques tels que stackoverflow tout en fournissant le code de ressource.

Articles Similaires