Sådan løser du effektivt fejlen “Forbindelse nulstillet af peer”

Fejlen “Forbindelse nulstillet af peer” er en af ​​de irriterende netværksfejl, der opstår, når serveren uventet lukker forbindelsen, før dit system kan afslutte kommunikationen. Normalt skyldes det, at en firewall, sikkerhedsindstilling eller timeout blokerer din forbindelse, men nogle gange er det mere obskure ting som serverfejlkonfigurationer eller problemer med netværksrouting. Grundlæggende set vil serveren bare ikke længere spille, og det kan være lidt besværligt at finde ud af hvorfor. Hvis du prøver at konfigurere SSH, FTP eller en brugerdefineret app, og pludselig forsvinder alt med denne fejl, er her nogle ting, du skal kontrollere. Det er ikke altid ligetil at rette dette, især hvis du ikke har adgang til serverloggene, men disse trin burde bringe dig tættere på årsagen eller endda løse den.

Sådan rettes nulstilling af forbindelse via peer

Tjek logfiler og fejlmeddelelser

Dette er en slags detektivtrin – kig på loggene for spor. Hvis det for eksempel er et SSH-forbindelsesproblem, vil du gerne følge godkendelsesloggen, så du kan se, hvad der sker bag kulisserne. På en Linux-server skal du åbne terminalen og skrive:

tail -f /var/log/auth.log

Dette vil vise poster i realtid, når du forsøger at oprette forbindelse. Hvis du har med andre tjenester at gøre, skal du tjekke deres logfiler, normalt i /var/log/ eller via journalctl, hvis du bruger systemd. På nogle opsætninger kan aktivering af detaljeret fejlfindingstilstand for din tjeneste eller dæmon give mere indsigt – f.eks.aktivering af verbose-tilstand på SSH med ssh -vvv.

Det er lidt mærkeligt, men disse logfiler viser dig ofte, om serveren blokerer din IP-adresse, rammer en grænse eller støder på en intern fejl. På nogle opsætninger skal du muligvis aktivere ekstra logføring eller indstille fejlfindingsflag i konfigurationsfilerne for at få bedre information.

Test internetforbindelse og routing

Dernæst skal du kontrollere, om din forbindelse til serverruten rent faktisk fungerer. Brug den traceroute [domain/IP]på Linux eller tracert [domain/IP]Windows. Det er ligesom at tegne et kort over den rejse, dine pakker tager. Hvis et af disse hop falder ud eller viser tegn på problemer, kan det være dit problem.

Nogle gange kan serveren eller en gateway tidligere i kæden være nede eller overbelastet. Hvis du ser konstante timeouts et par gange, er det ofte uden for dine hænder. Hvis det er din private server, kan genstart af netværkstjenester eller endda hele serveren afhjælpe fastlåste tilstande. For eksempel kan du på Linux genstarte netværksrelaterede tjenester som f.eks.sudo systemctl restart networkingeller sudo systemctl restart NetworkManager.

Tjek om din IP-adresse er forbudt eller sortlistet

Her er lidt lusket – din IP-adresse er muligvis udelukket eller blacklistet. Offentlige servere er hurtige til at udelukke IP-adresser, som de synes er mistænkelige, og dette får nulstillingsfejl til at dukke op. For at se, om din IP-adresse er på en blackliste, kan du bruge sider som MX Toolbox Blacklist Check. Indtast din IP-adresse (søg efter “Hvad er min IP”, hvis du er usikker), og hvis den er markeret, er det din synder.

I så fald skal du tale med din internetudbyder eller bruge en VPN til at skifte IP-adresser, da den eneste måde at løse en sortliste på er via serveradministratoren, og den proces kan tage tid. Husk blot: at ændre IP-adresser er ikke altid en permanent løsning, især hvis dit netværk bliver markeret igen.

Undersøg firewall og sikkerhedsfiltre

Det er ofte her, tingene bliver rodede. Firewalls på din lokale eller serverside kan blokere eller nulstille forbindelser, hvis de mener, at trafikken er mistænkelig. Hvis du administrerer serveren, skal du tjekke dine iptables-regler (på Linux):

sudo iptables -L --line-numbers

Kig efter regler, der muligvis afviser din IP-adresse eller forbindelsesporten. På samme måde, hvis du kører sikkerhedsapps som Fail2ban eller DenyHosts, skal du kontrollere, at din IP-adresse ikke er på deres blokeringslister. For Fail2ban skal du tjekke konfigurationsfilerne på /etc/fail2ban/jail.confog ignoreiplinjen.

Deaktiver aldrig bare firewalls helt; det er at bede om problemer. Sæt i stedet din IP-adresse på hvidlisten eller juster reglerne forsigtigt. Windows og Linux har selvfølgelig forskellige måder at administrere firewallregler på, og syntaksen kan variere.

På Linux, udover iptables, ufwtilbyder værktøjer som f.eks.en mere brugervenlig brugerflade:

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

Og i Windows skal du kontrollere dine Windows Defender Firewall-regler i Kontrolpanel eller via PowerShell-kommandoer.

Genstart netværkstjenester og dæmoner

Hvis din servers konfiguration for nylig er ændret, men ingen har genstartet tjenesterne, kan det forårsage vedvarende problemer. Genstart af dæmoner som SSH, FTP eller brugerdefinerede tjenester kan afhjælpe fastlåste tilstande. For eksempel, på en Debian- eller Ubuntu-server, kør:

sudo systemctl restart ssh

På samme måde, for FTP eller Samba, skal du erstatte sshmed smbdeller den tjeneste, du har at gøre med. Bare en advarsel – på nogle opsætninger skal du koordinere med serveradministratoren for at undgå at forstyrre aktive sessioner.

Rediger værtsfil til adgangskontrol

Hosts-filer kan bruges til at tillade eller afvise specifikke IP-adresser. Hvis du har mistanke om en IP-blokering, skal du kontrollere /etc/hosts.deny og /etc/hosts.allow. Hvis din IP-adresse f.eks.vises i /etc/hosts.deny, skal du kommentere den ud eller fjerne linjen:

# your IP in hosts.deny

Og tilføj det så /etc/hosts.allowsådan her:

sshd : 10.10.10.8

Dette kan være en sikker måde at genetablere adgang på, hvis serverblokkene er for aggressive.

Forøg TCP-timeoutperioder og send Keepalive-pakker

Dette er nærmest en sidste udvej, men for forbindelser, der mistes i inaktive perioder, hjælper det at justere keepalive-indstillingerne. På Linux kan du redigere /etc/sysctl.confog tilføje eller ændre disse linjer:

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

Genindlæs derefter med sysctl --load=/etc/sysctl.conf. Dette sikrer, at dit system sender regelmæssige hjerteslagspakker, så serveren holder forbindelsen aktiv og giver dig mere stabilitet. For Windows kan du justere lignende indstillinger via registreringsdatabasen – naviger til HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parametersog juster KeepAliveTimeog KeepAliveInterval.

Gennemgå SSH-konfigurationen for serveren

Hvis SSH giver dig problemer, så tjek /etc/ssh/sshd_configfilen. Indstillinger som MaxStartups og ClientAliveInterval kan forårsage fald, hvis de er indstillet for restriktivt. For eksempel MaxStartupstillader en forøgelse flere samtidige, ikke-godkendte forbindelser, og aktivering ClientAliveIntervalmed en passende ClientAliveCountMaxforhindrer sessionen i at timeout naturligt.

Glem ikke at genstarte SSH efter redigering:

sudo systemctl restart ssh

Sørg for SSL-understøttelse og grænser for åbne forbindelser

Nogle gange bruger serveren SSL til at sikre forbindelser, og hvis din klient ikke understøtter eller konfigurerer SSL korrekt, kan det forårsage nulstillinger. Sørg for, at din klient understøtter SSL, hvis det er nødvendigt, og at dine certifikater er gyldige og korrekt installeret.

Derudover har servere et maksimalt antal sockets (som åbne forbindelser).Hvis denne grænse nås, kan nye forbindelser afvises eller nulstilles. For at teste eller midlertidigt øge denne grænse skal du køre:

ulimit -n 65535

For en permanent ændring, modificer /etc/security/limits.conf, og tilføj linjer svarende til:

* soft nofile 65535 * hard nofile 65535

Og bekræft at PAM er konfigureret til at respektere disse begrænsninger ved at redigere /etc/pam.d/common-sessionfor at inkludere required pam_limits.so.

Fejlfinding af brugerdefinerede scripts og protokolkompatibilitet

Hvis du har bygget dine egne forbindelsesscripts eller apps, skal du sørge for, at de følger protokolstandarder. Fejl som at glemme at lukke socket-forbindelser, forkert håndtering af TLS eller afsendelse af uventede quit-kommandoer kan få servere til at nulstille forbindelser. Tjek også for zombieprocesser eller underprocesser, der ikke er afsluttet korrekt – de kan fylde procestabeller og forårsage alle mulige mærkelige fejl.

Brug fejlfindingsværktøjer eller logfiler til at spore, hvad dine scripts laver. Optaget i blinde, men nogle gange hjælper det blot at omstrukturere dine forbindelsesforsøg eller tilføje forsinkelser. Når du støder hovedet på dette, kan udviklerfora som Stack Overflow være overraskende nyttige – du skal bare dele nok detaljer og konfigurationer.