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

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 basisverbinding te testen. U moet er echter niet op vertrouwen om de algehele connectiviteit te bewijzen. Telnet en PsPing zijn om de volgende redenen nuttiger:

• Deze hulpprogramma's kunnen de connectiviteit met de toepassingslaag testen met behulp van TCP of UDP (alleen PsPing) als het transportprotocol.
• U kunt opgeven welke poort wordt gebruikt. Daarom kunt u navigeren door open poorten op een firewall.
• U kunt verbinding maken met een '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 die zich in het pad naar het getroffen gebied bevinden. Let met name op de volgende apparaten:

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

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

Stap 2: Netwerktraceringen

Netwerktraceringen zijn handig om te zien wat er op netwerkniveau gebeurt wanneer het probleem zich voordoet.

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. Noteer eventuele foutberichten die worden weergegeven.

Als u een algemene fout ontvangt, 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 netwerkverbindingsstatusindicator (NSCI) geen testcontrole heeft uitgevoerd.

Controleer of de netwerkadapter connectiviteit rapporteert om dit probleem op te lossen. Zorg ervoor dat de netwerkadapter is aangesloten en dat de switchpoort waarop het knooppunt is aangesloten geen foutstatus heeft. U kunt kabels, switchpoorten en netwerkadapters wijzigen om te bepalen 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 wordt meestal veroorzaakt door een beschadiging in de stack. Gebruik de volgende stappen voor probleemoplossing:

1. Zorg ervoor dat de meest recente bits op het knooppunt (TCP/IP, NDIS, AFD, Winsock, enzovoort) zijn.

2. Stel IP en Winsock opnieuw in door de volgende opdrachten uit te voeren. Maak een back-up van alle netwerkconfiguraties.

   netsh -c interface dump > C:\netConfig.txt
   netsh int ip reset
   netsh winsock reset
   

3. Start het knooppunt opnieuw op.

4. Herstel de netwerkinstellingen na het opnieuw opstarten. Deze bewerking werkt alleen als de interfacenamen niet zijn gewijzigd of als het script is bijgewerkt om de nieuwe namen te gebruiken.

   netsh -f C:\netConfig.txt
   

5. Verwijder of installeer het stuurprogramma van de netwerkadapter, indien van toepassing.

6. Controleer op filterstuurprogramma's van derden en verwijder deze (bijvoorbeeld antivirus).

7. Start de computer in de veilige modus met netwerken. Als veilige modus met netwerken werkt, voert u een 'schoon opstarten'-proces uit door alle apps en services van derden in MSConfig uit te schakelen en ze vervolgens een voor een opnieuw in te schakelen totdat het probleem zich voordoet. U kunt vervolgens 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 kan moeilijk en zeer tijdrovend zijn om de hoofdoorzaak van de beschadiging te achterhalen. Zelfs als de beschadiging wordt gevonden, is het nog moeilijker om te weten wat de oorzaak is. Als u de beschadigde registersleutel handmatig wijzigt, wordt het knooppunt in een niet-ondersteunde status geplaatst. Daarom raden we de klant aan het knooppunt te herstellen of opnieuw te laden om de beschadiging te corrigeren.

Als de NSCI de testcontrole (geel uitroepteken) mislukt, duidt dit niet noodzakelijkerwijs op een verbindingsprobleem. Zorg ervoor dat de gebruikelijke communicatie plaatsvindt zoals het hoort.

• Als dat het geval is, moet het onderzoek zich specifiek richten op de reden waarom de NCSI de testcontroles mislukt. De details hiervoor worden behandeld in een afzonderlijk onderwerp.
• Zo niet, onderzoek dan eerst de verbindingsproblemen, omdat dit waarschijnlijk wordt gecorrigeerd nadat de verbinding is hersteld.

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

Als het knooppunt kan pingen of telnet kan uitvoeren naar knooppunten in hetzelfde subnet of hetzelfde netwerksegment, zou dit bevestigen dat de externe connectiviteit werkt. Verdere tests zijn nog steeds vereist om te begrijpen of er een basisverbindingsprobleem bestaat.

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

1. De fout Doelhost onbereikbaar betekent dat de ARP-aanvragen die worden verzonden door het knooppunt geen antwoord krijgen.

2. 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 reageert. Dit antwoord moet worden weergegeven in de brontracering. Als dit proces mislukt, is het probleem waarschijnlijk een onjuiste configuratie of andere problemen die van invloed zijn op de infrastructuur.

   Mogelijke oorzaken kunnen zijn:

   1. Onjuiste of niet-overeenkomende VLAN's.
   2. Een onjuiste switchpoortconfiguratie (trunk versus toegangspoort).
   3. Andere hardwareproblemen.

3. De fout Time-out van aanvraag betekent dat de ARP-aanvraag een antwoord heeft gekregen, maar dat de ICMP-echoaanvraag die wordt verzonden door het knooppunt geen ICMP-echo-antwoord krijgt. Dit duidt alleen niet op een probleem. ICMP-verkeer kan worden geblokkeerd door het netwerk of de firewallsoftware op de knooppunten. Het kan handig zijn om de firewallprofielen (Windows) uit te schakelen of 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 verbinding. Ga door met het testen van de basisconnectiviteit.
   3. Als stap 1 niet is geslaagd (en als firewallprofielen zijn uitgeschakeld), verzamelt u een tweezijdige netsh netconnection scenariotracering om de problemen verder op te lossen.

Stap 5: Ping 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 basisverbindingsprobleem bestaat. Als het knooppunt niet kan pingen of Telnet naar de standaardgateway, betekent dit dat de ICMP-antwoorden zijn uitgeschakeld op de router.

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.

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

   Opmerking

   De leverancier van de toepassing kan Microsoft zijn als het probleem bijvoorbeeld een fout is bij het maken van verbinding met een share. In deze situaties is het handig om tweezijdige netsh netconnection-scenariotracering te gebruiken om aanvullende informatie te verzamelen en u te helpen controleren of er geen problemen zijn in de netwerkstack.

2. Als de verbinding met de specifieke poort niet tot stand is gebracht:

   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 toepassingen van derden één voor één en test tussen elke verwijdering.
      Als dit lukt, neemt u contact op met de leverancier van de problematische software.
   4. Probeer veilige modus met netwerken.
      Als dit lukt, kunt u de oorzaak isoleren door een 'schone opstart' 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 netconnection-scenariotracering uitvoeren van de bron naar het betreffende doelknooppunt. Een netwerk-SDP zou ook nuttig zijn.

3. Als het knooppunt niet kan pingen, Telnet of PsPing naar andere knooppunten in het doelsubnet, kan het probleem waarschijnlijk te maken hebben met infrastructuur. Ook hier kan ICMP worden geblokkeerd in de omgeving. Controleer daarom de connectiviteit met behulp van Telnet of PsPing om verbinding te maken met bekende luisterpoorten. Op dit punt is een tweezijdige netwerktracering nodig om aan te geven waar het pakketverlies optreedt op het netwerk. Zorg ervoor dat beide traceringen worden uitgevoerd voordat u de connectiviteitstest uitvoert, zodat het probleem wordt vastgelegd.

Veelvoorkomende 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 omdat er problemen met softwarevertraging op netwerk- of gebruikersniveau zijn.

Als u dit probleem wilt oplossen, gebruikt u de netstat -a opdracht om de status van alle activiteiten op TCP- en UDP-poorten op de lokale computer weer te geven.
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 een van beide wachtrijen worden geblokkeerd of als de status onregelmatig is, is de verbinding waarschijnlijk een fout. Als dat niet het probleem is, ondervindt u waarschijnlijk een vertraging op het netwerk of op gebruikersniveau.

Lange verbindingstijden bij gebruik van Lmhosts voor naamomzetting

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

U kunt dit probleem oplossen door veelgebruikte vermeldingen boven aan het bestand te plaatsen 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 nbtstat -R opdracht uit om de lokale naamcache onmiddellijk bij te werken.

Systeemfout 53 opgetreden

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

Als de computer zich in 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 de naam niet wordt omgezet in NetBIOS-naamomzetting of omdat 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 probeert te 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.

U kunt dit probleem oplossen door te bepalen of de standaardgateway zich op 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 een IP-adres 192.168.0.33 en een subnetmasker van 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 opneemt met Microsoft Ondersteuning, kunt u informatie over uw probleem verzamelen.

Voorwaarden

1. TSS moet worden uitgevoerd door accounts met beheerdersbevoegdheden op het lokale systeem en de gebruiksrechtovereenkomst moet worden geaccepteerd (zodra de gebruiksrechtovereenkomst is geaccepteerd, wordt TSS niet meer gevraagd).
2. We raden het PowerShell-uitvoeringsbeleid voor lokale machines aan RemoteSigned .

Belangrijke informatie verzamelen voordat u contact opneemt met Microsoft-ondersteuning

1. Download TSS op alle knooppunten en pak het uit in de map C:\tss .

2. Open de map C:\tss vanaf een PowerShell-opdrachtprompt met verhoogde bevoegdheid.

3. Start de traceringen op de bron- en doelserver met behulp van de volgende cmdlet:

   TSS.ps1 -Scenario NET_General
   

4. Accepteer de gebruiksrechtovereenkomst als de traceringen voor het eerst worden uitgevoerd op de bron- of doelserver.

5. Opname toestaan (PSR of video).

6. Reproduceer het probleem voordat u Y invoert.

   Opmerking

   Als u logboeken verzamelt op zowel de client als de server, wacht u op dit bericht op beide knooppunten voordat u het probleem reproduceert.

7. 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 kan worden geüpload.

Verwijzing

• Problemen met TCP/IP-connectiviteit oplossen
• Problemen met poortuitputting oplossen
• RPC-fouten (Remote Procedure Call) oplossen
• Gegevens verzamelen met behulp van Network Monitor
• Kan de TCP/IP-eigenschappen van de netwerkadapter niet openen
• Directe host-SMB via TCP/IP
• TCP/IP-netwerken configureren terwijl NetBIOS is uitgeschakeld
• TCP-verkeer stopt
• Standaard dynamisch poortbereik voor TCP/IP is gewijzigd
• TCP/IP-eigenschappen worden teruggezet naar de standaardinstellingen