Richtlijnen voor het oplossen van problemen met TCP/IP-communicatie

2025-01-15

Probeer onze virtuele agent : hiermee kunt u snel veelvoorkomende problemen met Active Directory-replicatie identificeren en oplossen.

Dit artikel is ontworpen om u te helpen bij het oplossen van problemen met TCP/IP-communicatie.

Hulpprogramma's voor probleemoplossing

De ping-opdracht is handig om de basisconnectiviteit te testen. U moet er echter niet op vertrouwen om de algehele connectiviteit te bewijzen. Telnet en PsPing zijn nuttiger om de volgende redenen:

Met deze hulpprogramma's kunt u de connectiviteit met de toepassingslaag testen met behulp van TCP of UDP (alleen PsPing) als transportprotocol.
U kunt opgeven welke poort wordt gebruikt. U kunt dus door geopende poorten op een firewall navigeren.
U kunt verbinding maken met elke 'luisterende' poort op het doelknooppunt om de toegang tot de poort van een specifieke toepassing te controleren.

Controlelijst voor probleemoplossing

Stap 1: Een netwerkdiagram vastleggen

Leg een netwerkdiagram vast met details van de apparaten in het pad naar het getroffen gebied. Let met name op de volgende apparaten:

Firewalls
IPS (inbraakbeveiligings-/preventiesystemen)
DPI (Deep Packet Inspection)
WAN-accelerators

Het diagram kan u helpen bij het visualiseren en identificeren van de oorzaak van het probleem.

Stap 2: Netwerktraceringen

Netwerktraceringen zijn handig om te kijken wat er op netwerkniveau gebeurt wanneer het probleem optreedt.

Stap 3: ping het lokale IP-adres van de computer

Probeer het lokale IP-adres van de computer te pingen.

Als het knooppunt het lokale IP-adres niet kan pingen, werkt de lokale stack niet. Let op eventuele foutberichten die worden weergegeven.

Als u een algemene fout krijgt, betekent deze fout dat er geen geldige interfaces zijn om de aanvraag te verwerken. Dit probleem kan worden veroorzaakt door een hardwareprobleem of een stackprobleem.

Controleer of u een rood 'X'-teken of een geel uitroepteken ziet op het pictogram Netwerkverbinding in het systeemvak. Een rode X geeft aan dat Windows geen netwerkverbinding detecteert. Een geel uitroepteken geeft aan dat de testcontrole van een netwerkverbindingsstatusindicator (NSCI) is mislukt.

Als u dit probleem wilt oplossen, controleert u of de netwerkadapter connectiviteit rapporteert. Zorg ervoor dat de netwerkadapter is aangesloten en dat de switchpoort waar het knooppunt is verbonden, niet de foutstatus heeft. U kunt kabels, switchpoorten en netwerkadapters wijzigen om te beperken waar dit probleem zich voordoet. Uiteindelijk ligt het probleem echter buiten het besturingssysteem. Neem contact op met de hardwareleveranciers om dit verder te onderzoeken.

Er kan ook een probleem optreden tussen het netwerkstuurprogramma en Windows. Dit probleem komt meestal door een beschadiging in de stack. Gebruik de volgende probleemoplossingsstappen:

Zorg ervoor dat de meest recente bits op het knooppunt (TCP/IP, NDIS, AFD, Winsock, etc.) zijn.
Stel IP en Winsock opnieuw in door de volgende opdrachten uit te voeren. Back-up van alle netwerkconfiguraties.
```
netsh -c interface dump > C:\netConfig.txt
netsh int ip reset
netsh winsock reset
```
Start het knooppunt opnieuw op.
Herstel de netwerkinstellingen na het opnieuw opstarten. Deze bewerking werkt alleen als de interfacenamen niet zijn gewijzigd of als het script wordt bijgewerkt om de nieuwe namen te gebruiken.
```
netsh -f C:\netConfig.txt
```
Verwijder het stuurprogramma voor de netwerkadapter of installeer het opnieuw, waar van toepassing.
Controleer op en verwijder stuurprogramma's voor filters van derden (bijvoorbeeld antivirus).
Probeer de computer in de Veilige modus met Netwerken te starten. Als de veilige modus met netwerken werkt, voert u een 'clean boot'-proces uit door alle apps en services van derden in MSConfig uit te schakelen en deze vervolgens één voor één in te schakelen totdat het probleem wordt geretourneerd. Vervolgens kunt u contact opnemen met de leverancier voor ondersteuning.
1. Als geen van deze items lukt, is het probleem waarschijnlijk een beschadiging van het register.
2. Als u een back-up van het register hebt (zoals een fysieke back-up of een systeemherstelpunt), kunt u proberen het knooppunt te herstellen naar een eerder werkende configuratie. Het vangen van de hoofdoorzaak van de beschadiging kan moeilijk en zeer tijdrovend zijn. Zelfs als de corruptie wordt gevonden, is het nog moeilijker om te weten wat het heeft veroorzaakt. Als u de beschadigde registersleutel handmatig wijzigt, wordt het knooppunt in een niet-ondersteunde status opgeslagen. Daarom raden we de klant aan het knooppunt te herstellen of opnieuw te laden om de beschadiging te corrigeren.

Als de NSCI de testcontrole mislukt (geel uitroepteken), geeft dit niet noodzakelijkerwijs een verbindingsprobleem aan. Zorg ervoor dat er normaal gesproken communicatie plaatsvindt.

Als dit het probleem is, moet het onderzoek zich specifiek richten op de reden waarom de testcontroles van de NCSI mislukken. De details hierover worden in een afzonderlijk onderwerp behandeld.
Zo niet, onderzoek dan eerst de connectiviteitsproblemen, omdat deze waarschijnlijk worden gecorrigeerd nadat de connectiviteit is hersteld.

Stap 4: Foutberichten oplossen die optreden tijdens de ping- of telnet-test

Als het knooppunt kan pingen of via Telnet verbinding kan maken met knooppunten in hetzelfde subnet of netwerksegment, zou dit bevestigen dat de externe connectiviteit werkt. Verdere tests zijn nog steeds vereist om te begrijpen of er een basisconnectiviteitsprobleem bestaat.

Als het knooppunt niet kan pingen/telnet naar knooppunten in hetzelfde subnet/netwerksegment. Let op eventuele foutberichten die worden weergegeven.

De doelhost kan niet bereikbaar zijn, betekent dat de ARP-aanvragen die door het knooppunt worden verzonden, geen antwoord krijgen.
Verzamel een tweezijdige tracering van de knooppunten waartussen u test. Zorg ervoor dat de ARP-aanvraag die wordt verzonden door het bronknooppunt het doelknooppunt bereikt en dat het doelknooppunt dienovereenkomstig antwoordt. Dit antwoord moet te zien zijn in de brontracering. Als dit proces mislukt, is het probleem waarschijnlijk een onjuiste configuratie of een ander probleem dat van invloed is op de infrastructuur.

Mogelijke oorzaken zijn:
1. Onjuiste of niet-overeenkomende VLAN's.
2. Een onjuiste configuratie van de switchpoort (trunk versus toegangspoort).
3. Overige hardwareproblemen.
De time-outfout van de aanvraag betekent dat de ARP-aanvraag een antwoord heeft ontvangen, maar de ICMP-echoaanvraag die door het knooppunt wordt verzonden, krijgt geen ICMP-echoreactie. Dit geeft alleen geen probleem aan. ICMP-verkeer kan worden geblokkeerd door het netwerk of de firewallsoftware op de knooppunten. Het kan nuttig zijn om de firewallprofielen (Windows) uit te schakelen of deze uit te schakelen via de ondersteunde methode van de firewallleverancier voor het testen van ICMP.
1. Telnet en PsPing zijn beter geschikt voor testen. Voer Telnet of PsPing uit vanaf het bronknooppunt naar het doelknooppunt op een luisterende poort (zoals 445).
2. Als stap 1 is geslaagd, werkt de externe connectiviteit. Ga door met het testen van de basisconnectiviteit.
3. Als stap 1 niet lukt (en als firewallprofielen zijn uitgeschakeld), verzamelt u een tracering met twee netsh netconnection zijden om problemen verder op te lossen.

Stap 5: Pingen of Telnet naar de standaardgateway

Wanneer het knooppunt de standaardgateway kan pingen, is externe connectiviteit (zoals off-box-connectiviteit) mogelijk vanaf het bronknooppunt. Verdere tests zijn nog steeds vereist om te begrijpen of er een basisconnectiviteitsprobleem bestaat. Als het knooppunt niet kan pingen of Telnet naar de standaardgateway, betekent dit dat de ICMP-antwoorden op de router zijn uitgeschakeld.

Stap 6: Problemen controleren die van invloed zijn op het specifieke doelknooppunt

Als het bronknooppunt kan pingen, Telnet of PsPing naar andere knooppunten in het doelsubnet, werkt de basisverbinding en routering binnen de infrastructuur. Dit resultaat wijst op een probleem dat van invloed is op het specifieke doelknooppunt.

Probeer Telnet of PsPing naar de specifieke poort waar de toepassing op luistert (bijvoorbeeld TCP-poort 445 voor SMB). Als de verbinding tot stand is gebracht, kan de basisconnectiviteit op toepassingsniveau worden bevestigd. In dit geval moet u contact opnemen met de leverancier van de toepassing om te onderzoeken waarom de toepassing geen verbinding maakt.

Notitie

De leverancier van de toepassing kan Microsoft zijn als het probleem bijvoorbeeld geen verbinding kan maken met een share. In dergelijke situaties is het handig om een scenario met twee zijden van netsh netconnection te traceren om aanvullende informatie te verzamelen en u te helpen controleren of er geen problemen zijn in de netwerkstack.
Als de verbinding met de specifieke poort niet lukt:
1. Zorg ervoor dat de poort de status 'luisteren' heeft:
  CMD: netstat -nato | findstr :<port>
  PowerShell: Get-NetTcpConnection -LocalPort <port>
2. Schakel tijdelijk alle firewallprofielen uit. (Opmerking: schakel alleen de profielen uit. Schakel de service niet uit.)
  Als dit lukt, moet de firewall opnieuw worden geconfigureerd om het toepassingsverkeer op de specifieke poort toe te staan.
3. Verwijder alle toepassingen van derden één voor één en test tussen elke verwijdering.
  Als dit lukt, neem dan contact op met de leverancier van de problematische software.
4. Probeer Veilige modus met Netwerken.
  Als dit lukt, moet u de oorzaak isoleren door een schone opstartbewerking van het knooppunt uit te voeren met behulp van MSConfig en vervolgens toepassingen en services van derden één voor één in te schakelen totdat het probleem zich opnieuw voordoet.
5. Wanneer u de verbindingspoging reproduceert, moet u een traceerscenario van netsh netconnection uitvoeren van de bron naar het betreffende doelknooppunt. Een Netwerken-SDP zou ook nuttig zijn.
Als het knooppunt niet kan pingen, Telnet of PsPing naar andere knooppunten in het doelsubnet, kan het probleem waarschijnlijk betrekking hebben op infrastructuur. Ook kan ICMP in de omgeving worden geblokkeerd. Controleer daarom de connectiviteit met behulp van Telnet of PsPing om verbinding te maken met bekende luisterpoorten. Op dit moment is een tweezijdige netwerktracering nodig om aan te geven waar het pakketverlies plaatsvindt in het netwerk. Zorg ervoor dat beide traceringen worden uitgevoerd voordat u de connectiviteitstest probeert, zodat het probleem wordt vastgelegd.

Bekende problemen en oplossingen

TCP/IP-verbinding met een host lijkt te zijn gestopt

Dit probleem treedt op omdat gegevens worden geblokkeerd in TCP- en UDP-wachtrijen of er problemen zijn met netwerk- of softwarevertraging op gebruikersniveau.

Gebruik de netstat -a opdracht om de status van alle activiteiten op TCP- en UDP-poorten op de lokale computer weer te geven om dit probleem op te lossen.
De status van een goede TCP-verbinding wordt tot stand gebracht met nul (0) bytes in de wachtrijen voor verzenden en ontvangen. Als gegevens in beide wachtrijen worden geblokkeerd of als de status onregelmatig is, heeft de verbinding waarschijnlijk een fout. Als dat niet het probleem is, ondervindt u waarschijnlijk een vertraging in het netwerk of software op gebruikersniveau.

Lange verbindingstijden bij het gebruik van Lmhosts voor naamomzetting

Dit probleem treedt op omdat het Lmhosts-bestand opeenvolgend wordt geparseerd om vermeldingen te vinden zonder de optie #PRE.

Als u dit probleem wilt oplossen, plaatst u veelgebruikte vermeldingen bovenaan het bestand en de #PRE vermeldingen onderaan. Als een vermelding wordt toegevoegd aan het einde van een groot Lmhosts-bestand, markeert u de vermelding in Lmhosts als een vooraf geladen vermelding met behulp van de optie #PRE. Voer vervolgens de opdracht nbtstat -R uit om de lokale naamcache onmiddellijk bij te werken.

Systeemfout 53 is opgetreden

Systeemfout 53 wordt geretourneerd als naamomzetting mislukt voor een bepaalde computernaam wanneer de net use opdracht wordt gebruikt.

Als de computer zich op het lokale subnet bevindt, controleert u of de naam juist is gespeld en of op de doelcomputer ook TCP/IP wordt uitgevoerd. Als de computer zich niet in het lokale subnet bevindt, controleert u of de naam en ip-adrestoewijzing beschikbaar zijn in het Lmhosts-bestand of de WINS-database. Als alle TCP/IP-elementen correct lijken te zijn geïnstalleerd, gebruikt u de ping opdracht samen met de externe computer om te controleren of de TCP/IP-software werkt.

Kan geen verbinding maken met een specifieke server

Dit probleem treedt op omdat netBIOS-naamomzetting de naam niet oplost of het verkeerde IP-adres wordt opgelost.

Als u dit probleem wilt oplossen, gebruikt u de nbtstat -n opdracht op de server om te bepalen welke namen de server heeft geregistreerd op het netwerk. De computernaam van de computer waarmee u verbinding wilt maken, moet in de weergegeven lijst staan. Als de naam niet wordt vermeld, probeert u een van de andere unieke computernamen die worden weergegeven door nbtstat. Als de naam die wordt gebruikt door een externe computer dezelfde is als de naam die wordt weergegeven door de nbtstat -n opdracht, moet u ervoor zorgen dat de externe computer een vermelding heeft voor de servernaam die zich op de WINS-server of in het lmhosts-bestand bevindt.

Kan geen standaardgateway toevoegen

Dit probleem treedt op omdat het IP-adres van de standaardgateway zich niet op dezelfde IP-netwerk-id bevindt als uw IP-adres.

Als u dit probleem wilt oplossen, moet u bepalen of de standaardgateway zich in hetzelfde logische netwerk bevindt als de netwerkadapter van de computer door het IP-adres van de standaardgateway te vergelijken met de netwerk-id's van een van de netwerkadapters van de computer.

Een computer heeft bijvoorbeeld één netwerkadapter die is geconfigureerd met het IP-adres 192.168.0.33 en een subnetmasker 255.255.0.0. Hiervoor moet de standaardgateway de vorm 192.168 hebben.<y>.<z>' omdat het netwerk-id-gedeelte van de IP-interface 192.168.0.0 is.

Gegevensverzameling

Voordat u contact op neemt met Microsoft Ondersteuning, kunt u informatie over uw probleem verzamelen.

Voorwaarden

TSS moet worden uitgevoerd door accounts met beheerdersbevoegdheden op het lokale systeem en EULA moet worden geaccepteerd (zodra eula is geaccepteerd, wordt TSS niet opnieuw gevraagd).
Het powerShell-uitvoeringsbeleid van de lokale computer RemoteSigned wordt aangeraden.

Notitie

Als het huidige PowerShell-uitvoeringsbeleid het uitvoeren van TSS niet toestaat, voert u de volgende acties uit:

Stel het RemoteSigned uitvoeringsbeleid voor het procesniveau in door de cmdlet PS C:\> Set-ExecutionPolicy -scope Process -ExecutionPolicy RemoteSigneduit te voeren.
Voer de cmdlet PS C:\> Get-ExecutionPolicy -Listuit om te controleren of de wijziging van kracht wordt.
Omdat de machtigingen op procesniveau alleen van toepassing zijn op de huidige PowerShell-sessie, gaat de toegewezen machtiging voor het procesniveau ook terug naar de eerder geconfigureerde status zodra het opgegeven PowerShell-venster waarin TSS wordt uitgevoerd is gesloten.

Belangrijke informatie verzamelen voordat u contact op neemt met Microsoft Ondersteuning

Download TSS op alle knooppunten en pak deze uit in de map C:\tss .
Open de map C:\tss vanuit een PowerShell-opdrachtprompt met verhoogde bevoegdheid.
Start de traceringen op de bron- en doelserver met behulp van de volgende cmdlet:
```
TSS.ps1 -Scenario NET_General
```
Accepteer de gebruiksrechtovereenkomst als de traceringen voor het eerst worden uitgevoerd op de bron- of doelserver.
Opname toestaan (PSR of video).
Reproduceer het probleem voordat u Y invoert.

Notitie

Als u logboeken op zowel de client als de server verzamelt, wacht u op dit bericht op beide knooppunten voordat u het probleem reproduceert.
Voer Y in om de logboekverzameling te voltooien nadat het probleem is gereproduceerd.

De traceringen worden opgeslagen in een zip-bestand in de map C:\MS_DATA , die voor analyse naar de werkruimte kunnen worden geüpload.