Hoe los je de foutmelding “Verbinding verbroken door tegenpartij” effectief op?

De foutmelding “Connection reset by peer” is een van die vervelende netwerkproblemen die optreden wanneer de server onverwacht de verbinding verbreekt voordat uw systeem de communicatie heeft kunnen voltooien. Meestal komt dit doordat een firewall, beveiligingsinstelling of time-out de verbinding blokkeert, maar soms is de oorzaak minder voor de hand liggend, zoals verkeerde serverconfiguraties of problemen met de netwerkroutering. In feite wil de server gewoon niet meer meewerken en het kan lastig zijn om de oorzaak te achterhalen. Als u SSH, FTP of een aangepaste applicatie probeert in te stellen en plotseling loopt alles vast met deze foutmelding, zijn dit enkele zaken om te controleren. Het oplossen van dit probleem is niet altijd eenvoudig, vooral als u geen toegang hebt tot de serverlogboeken, maar deze stappen zouden u dichter bij de oorzaak moeten brengen of het probleem zelfs kunnen oplossen.

Hoe los je een verbroken verbinding door de tegenpartij op?

Controleer de logbestanden en foutmeldingen.

Dit is een soort detectivewerk: bekijk de logbestanden voor aanwijzingen. Als het bijvoorbeeld een probleem met de SSH-verbinding is, wilt u het authenticatielogboek bekijken om te zien wat er achter de schermen gebeurt. Open op een Linux-server de terminal en typ:

tail -f /var/log/auth.log

Dit toont realtime gebeurtenissen wanneer u probeert verbinding te maken. Als u met andere services werkt, controleer dan hun logbestanden, meestal in /var/log/ of via journalctl als u systemd gebruikt. In sommige configuraties kan het inschakelen van de gedetailleerde foutopsporingsmodus voor uw service of daemon meer inzicht geven — net zoals het inschakelen van de uitgebreide modus op SSH met ssh -vvv.

Het is een beetje vreemd, maar die logbestanden geven vaak aan of de server je IP-adres blokkeert, een limiet bereikt of een interne fout tegenkomt. Bij sommige configuraties moet je mogelijk extra logboekregistratie inschakelen of debug-vlaggen in de configuratiebestanden instellen om betere informatie te krijgen.

Test de internetverbinding en routering.

Controleer vervolgens of uw verbinding met de serverroute daadwerkelijk werkt. Gebruik hiervoor de opdracht traceroute [domain/IP]op Linux of tracert [domain/IP]Windows. Het is alsof u een kaart tekent van de route die uw datapakketten afleggen. Als een van die hops wegvalt of problemen vertoont, kan dat de oorzaak van het probleem zijn.

Soms kan de server of een gateway eerder in de keten uitvallen of overbelast raken. Als je na een paar hops consistent time-outs ziet, heb je daar vaak geen controle meer over. Als het je eigen server is, kan het herstarten van netwerkservices of zelfs de hele server vastgelopen situaties verhelpen. Op Linux kun je bijvoorbeeld netwerkgerelateerde services zoals sudo systemctl restart networkingof opnieuw starten sudo systemctl restart NetworkManager.

Controleer of uw IP-adres geblokkeerd of op een zwarte lijst staat.

Hier is een beetje een listige truc: je IP-adres is mogelijk geblokkeerd of op een zwarte lijst geplaatst. Openbare servers blokkeren snel IP-adressen die ze verdacht vinden, en dit veroorzaakt de resetfouten. Om te controleren of je IP-adres op een zwarte lijst staat, kun je sites zoals MX Toolbox Blacklist Check gebruiken. Voer je IP-adres in (zoek op “Wat is mijn IP-adres” als je het niet zeker weet) en als het wordt gemarkeerd, is dat waarschijnlijk de boosdoener.

In dat geval kunt u het beste contact opnemen met uw internetprovider of een VPN gebruiken om uw IP-adres te wijzigen. De enige manier om een ​​blacklist op te heffen is namelijk via de serverbeheerder, en dat proces kan tijdrovend zijn. Houd er rekening mee dat het wijzigen van IP-adressen niet altijd een permanente oplossing is, vooral niet als uw netwerk opnieuw op de blacklist terechtkomt.

Controleer de firewall en beveiligingsfilters.

Dit is vaak waar het misgaat. Firewalls aan de lokale of serverzijde kunnen verbindingen blokkeren of verbreken als ze het verkeer verdacht vinden. Als je de server beheert, controleer dan je iptables-regels (op Linux):

sudo iptables -L --line-numbers

Controleer of er regels zijn die uw IP-adres of de verbindingspoort blokkeren. Controleer ook of uw IP-adres niet in de blokkeerlijsten van beveiligingsapps zoals Fail2ban of DenyHosts staat. Voor Fail2ban kunt u de configuratiebestanden /etc/fail2ban/jail.confen de ignoreipbetreffende regel controleren.

Schakel firewalls nooit volledig uit; dat is vragen om problemen. Voeg in plaats daarvan je IP-adres toe aan de whitelist of pas de regels zorgvuldig aan. Windows en Linux hebben immers verschillende manieren om firewallregels te beheren, en de syntax kan variëren.

Op Linux ufwbieden naast iptables ook tools zoals een gebruiksvriendelijkere interface:

sudo ufw allow from [your-ip] to any port [port]

Controleer op Windows de regels van uw Windows Defender-firewall in het Configuratiescherm of via PowerShell-opdrachten.

Netwerkservices en daemons opnieuw opstarten

Als de configuratie van uw server recent is gewijzigd, maar niemand de services opnieuw heeft opgestart, kan dit aanhoudende problemen veroorzaken. Het herstarten van daemons zoals SSH, FTP of aangepaste services kan vastgelopen situaties verhelpen. Voer bijvoorbeeld op een Debian- of Ubuntu-server het volgende commando uit:

sudo systemctl restart ssh

Voor FTP of Samba vervang je dit sshdoor smbdde juiste service. Let wel: in sommige configuraties moet je overleggen met de serverbeheerder om te voorkomen dat actieve sessies worden verstoord.

Bewerk het hosts-bestand voor toegangscontrole.

Hosts-bestanden kunnen worden gebruikt om specifieke IP-adressen toe te staan ​​of te blokkeren. Als u een IP-blokkering vermoedt, controleer dan /etc/hosts.deny en /etc/hosts.allow. Als uw IP-adres bijvoorbeeld in /etc/hosts.deny voorkomt /etc/hosts.deny, zet het dan in commentaar of verwijder de regel:

# your IP in hosts.deny

Voeg het vervolgens als /etc/hosts.allowvolgt toe:

sshd : 10.10.10.8

Dit kan een betrouwbare manier zijn om de toegang te herstellen als de serverblokkades te streng zijn.

Verhoog de TCP-time-outperiodes en verstuur keepalive-pakketten.

Dit is een soort laatste redmiddel, maar voor verbindingen die tijdens inactiviteit worden verbroken, kan het aanpassen van de keepalive-instellingen helpen. Op Linux kunt u /etc/sysctl.confdeze regels bewerken, toevoegen of wijzigen:

net.ipv4.tcp_keepalive_time = 300 net.ipv4.tcp_keepalive_probes = 9 net.ipv4.tcp_keepalive_intvl = 10

Herlaad vervolgens met sysctl --load=/etc/sysctl.conf. Dit zorgt ervoor dat uw systeem regelmatig heartbeat-pakketten verzendt, zodat de server de verbinding actief houdt en u meer stabiliteit krijgt. Voor Windows kunt u vergelijkbare instellingen aanpassen via het register — navigeer naar HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parametersen pas KeepAliveTimeen aan KeepAliveInterval.

Controleer de SSH-configuratie voor de server.

Als SSH problemen geeft, controleer dan het /etc/ssh/sshd_configbestand. Instellingen zoals MaxStartups en ClientAliveInterval kunnen verbindingen verbreken als ze te restrictief zijn ingesteld. Het verhogen van deze waarde maakt bijvoorbeeld MaxStartupsmeer gelijktijdige niet-geauthenticeerde verbindingen mogelijk, en het inschakelen ClientAliveIntervalvan een geschikte waarde ClientAliveCountMaxvoorkomt dat de sessie vanzelf verloopt.

Vergeet niet SSH opnieuw op te starten na het bewerken:

sudo systemctl restart ssh

Zorg voor SSL-ondersteuning en open verbindingslimieten.

Soms gebruikt de server SSL om verbindingen te beveiligen. Als uw client SSL niet ondersteunt of niet correct configureert, kan dit tot verbindingsproblemen leiden. Zorg ervoor dat uw client SSL ondersteunt indien nodig en dat uw certificaten geldig en correct geïnstalleerd zijn.

Bovendien hebben servers een maximaal aantal sockets (vergelijkbaar met open verbindingen).Als die limiet bereikt is, kunnen nieuwe verbindingen worden geweigerd of verbroken. Om deze limiet te testen of tijdelijk te verhogen, voert u het volgende commando uit:

ulimit -n 65535

Voor een permanente wijziging kunt u het bestand aanpassen /etc/security/limits.confdoor regels toe te voegen die vergelijkbaar zijn met:

* soft nofile 65535 * hard nofile 65535

En bevestig dat PAM zo is ingesteld dat deze limieten worden gerespecteerd door de volgende aanpassing /etc/pam.d/common-sessiontoe te voegen required pam_limits.so:.

Foutopsporing van aangepaste scripts en protocolcompatibiliteit

Als je je eigen verbindingsscripts of -applicaties hebt ontwikkeld, zorg er dan voor dat ze voldoen aan de protocolstandaarden. Fouten zoals het vergeten om socketverbindingen te sluiten, onjuiste afhandeling van TLS of het verzenden van onverwachte afsluitopdrachten kunnen ertoe leiden dat servers verbindingen verbreken. Controleer ook op zombieprocessen of onderliggende processen die niet correct zijn afgesloten; deze kunnen de procestabellen vullen en allerlei vreemde fouten veroorzaken.

Gebruik debugtools of logbestanden om te achterhalen wat je scripts doen. Het is een gok, maar soms helpt het om je verbindingspogingen anders in te richten of vertragingen in te bouwen. Als je hier niet uitkomt, kunnen ontwikkelaarsforums zoals Stack Overflow verrassend nuttig zijn – je hoeft alleen maar voldoende details en configuraties te delen.