Problemen met TCP/IP-connectiviteit oplossen

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

Van toepassing op: Ondersteunde versies van Windows-client en Windows Server

Dit artikel bevat een uitgebreide handleiding voor het oplossen van connectiviteitsfouten met Transmission Control Protocol (TCP)/Internet Protocol (IP).

Symptomen en analyse

Er kunnen connectiviteitsproblemen optreden op toepassingsniveau of er kunnen time-outfouten optreden. Hier volgen enkele veelvoorkomende scenario's:

• Toepassingsconnectiviteit met een databaseserver
• Sql-time-outfouten
• Time-outfouten voor BizTalk-toepassingen
• RdP-fouten (Remote Desktop Protocol)
• Toegangsfouten voor bestandsshares
• Algemene connectiviteit

Wanneer een netwerkprobleem wordt vermoed, raden we u aan een netwerkpakketopname te verzamelen. Deze opname kan worden gefilterd om de problematische TCP-verbinding te identificeren en de oorzaak van de fout te bepalen.

Tijdens het probleemoplossingsproces kunt u een TCP RESET tegenkomen in de netwerkopname, wat kan duiden op een netwerkprobleem.

Inleiding tot TCP

TCP wordt gekenmerkt als een verbindingsgeoriënteerd en betrouwbaar protocol. Het zorgt voor betrouwbaarheid via het handshake-proces. Een TCP-sessie start met een handshake in drie richtingen, gevolgd door gegevensoverdracht, en eindigt met een sluiting in vier richtingen.

• Een vierrichtingssluiting, waarbij zowel de afzender als de ontvanger akkoord gaan met het sluiten van de sessie, wordt een sierlijke sluiting genoemd. Dit wordt geïdentificeerd door de FIN-vlag in de TCP-header die wordt ingesteld op 1.
• Na de sluiting in vier richtingen wacht de machine 4 minuten (standaard) voordat de poort wordt vrijgegeven. Dit wordt aangeduid als TIME_WAIT status. Tijdens deze TIME_WAIT status kunnen alle in behandeling zijnde pakketten voor de TCP-verbinding worden verwerkt. Zodra de status TIME_WAIT is voltooid, worden alle resources die voor de verbinding zijn toegewezen, vrijgegeven.
• Een TCP-reset is een plotselinge sessiesluiting, waardoor de directe release van toegewezen resources en het verwijderen van alle verbindingsgegevens wordt veroorzaakt. Dit wordt geïdentificeerd door de vlag RESET in de TCP-header in te stellen op 1.

Een netwerktracering die gelijktijdig op de bron en de bestemming wordt verzameld, helpt u om de stroom van het verkeer te bepalen en het storingspunt te identificeren.

In de volgende secties worden scenario's beschreven waarin een RESET kan optreden.

Pakketverlies via het netwerk

Wanneer een TCP-peer pakketten verzendt zonder een antwoord te ontvangen, worden de gegevens opnieuw door de peer verzonden. Als er nog steeds geen antwoord is, eindigt de sessie met een ACK RESET, die aangeeft dat de toepassing de uitgewisselde gegevens bevestigt, maar de verbinding sluit vanwege pakketverlies.

Gelijktijdige netwerktraceringen op zowel de bron als de bestemming kunnen dit gedrag verifiëren. Aan de bronzijde ziet u de opnieuw verzonden pakketten. Aan de doelzijde zijn deze pakketten niet aanwezig. Dit scenario geeft aan dat een netwerkapparaat tussen de bron en bestemming de pakketten verwijdert.

Zie Pakketverlies diagnosticeren voor meer informatie over het diagnosticeren van problemen met pakketverlies.

Scenario 1: Pakketverlies tijdens eerste TCP-handshake

Als de eerste TCP-handshake mislukt als gevolg van pakketuitval, wordt het TCP SYN-pakket standaard drie keer opnieuw verzonden.

Notitie

Het aantal keren dat het TCP SYN-pakket opnieuw wordt verzonden, kan verschillen op basis van het besturingssysteem. Dit wordt bepaald door de waarde Max SYN-hertransmissies onder TCP Global-parameters , die kunnen worden weergegeven met behulp van de opdracht netsh int tcp show global.

Stel dat een bronmachine met IP-adres 10.10.10.1 verbinding maakt met de bestemming met IP-adres 10.10.10.2 via TCP-poort 445. Hier volgt een schermopname van de netwerktracering die is verzameld op de broncomputer, waarin de eerste TCP-handshake wordt weergegeven waarin het TCP SYN-pakket wordt verzonden en vervolgens opnieuw wordt verzonden door de bron, omdat er geen antwoord is ontvangen van de bestemming.

Hetzelfde TCP-gesprek dat wordt gezien in de netwerktracering die op de bestemming is verzameld, laat zien dat geen van de bovenstaande pakketten door de bestemming is ontvangen. Dit impliceert dat het TCP SYN-pakket is verwijderd via het tussenliggende netwerk.

Als de TCP SYN-pakketten het doel bereiken, maar de bestemming niet reageert, controleert u of de verbonden TCP-poort op de doelcomputer de status LISTENING heeft. Dit kan worden gecontroleerd in de uitvoer van de opdracht netstat -anob.

Als de poort luistert en er nog steeds geen antwoord is, kan er een daling optreden bij het Windows-filterplatform (WFP).

Scenario 2: Pakketverlies tijdens gegevensoverdracht na het tot stand brengen van tcp-verbindingen

In een scenario waarin een gegevenspakket dat wordt verzonden nadat de TCP-verbinding tot stand is gebracht, wordt verwijderd via het netwerk, het pakket vijf keer opnieuw door TCP verzonden.

Stel dat een bronmachine met IP-adres 192.168.1.62 een verbinding tot stand heeft gebracht met doelcomputer met IP-adres 192.168.1.2 via TCP-poort 445. De bronmachine verzendt gegevens (SMB Negotiate-pakket) die vijf keer opnieuw wordt verzonden, zoals hieronder wordt weergegeven. Na geen antwoord van de bestemming verzendt de bronmachine een ACK-RST om deze TCP-verbinding te sluiten.

Bron 192.168.1.62 zijtracering:

U ziet geen van de bovenstaande pakketten die de bestemming bereiken.

U moet contact opnemen met uw interne netwerkteam om de verschillende hops tussen de bron en de bestemming te onderzoeken en te controleren of een van de hops mogelijk pakketdruppels veroorzaakt.

Onjuiste parameter in de TCP-header

Dit gedrag treedt op wanneer tussenliggende apparaten in het netwerk pakketten wijzigen, waardoor TCP aan het ontvangende einde deze weigert. Het TCP-volgnummer kan bijvoorbeeld worden gewijzigd of pakketten kunnen opnieuw worden afgespeeld door een tussenliggend apparaat met een gewijzigd TCP-volgnummer.

Een gelijktijdige netwerktracering op de bron en bestemming kan helpen bij het identificeren van wijzigingen in de TCP-headers.

Begin met het vergelijken van de bron- en doeltraceringen om wijzigingen in de pakketten te detecteren of de aanwezigheid van nieuwe pakketten die namens de bron de bestemming bereiken.

In dergelijke gevallen raden we u aan om hulp te zoeken van het interne netwerkteam om apparaten te identificeren die pakketten naar de bestemming wijzigen of opnieuw afspelen. Veelvoorkomende schuldigen zijn Riverbed-apparaten of WAN-accelerators.

Opnieuw instellen op toepassingsniveau

Wanneer u hebt vastgesteld dat de resets niet worden veroorzaakt door pakketuitval, onjuiste parameters of pakketwijzigingen (zoals geïdentificeerd via netwerktraceringen), kunt u concluderen dat het probleem een reset op toepassingsniveau is.

Resets op toepassingsniveau worden gekenmerkt door de vlag Bevestiging (ACK) die wordt ingesteld op 1, samen met de vlag Opnieuw instellen (R). Dit geeft aan dat de server de ontvangst van het pakket bevestigt, maar de verbinding om een of andere reden niet accepteert. Dit probleem treedt meestal op wanneer de toepassing die het pakket ontvangt, iets onaanvaardbaars vindt in de gegevens.

In de onderstaande schermopnamen kunt u zien dat de pakketten op zowel de bron als de bestemming identiek zijn, zonder wijzigingen of dalingen. Een expliciete reset wordt echter door de bestemming naar de bron verzonden.

Tracering aan de bronzijde:

Tracering aan doelzijde:

Een MET ACK+RST gemarkeerd TCP-pakket kan ook optreden wanneer een TCP SYN-pakket wordt verzonden. Het TCP SYN-pakket wordt gestart door de bronmachine om een verbinding op een specifieke poort tot stand te brengen. Als de doelserver het pakket echter om welke reden dan ook niet wil accepteren, reageert de server met een ACK+RST-pakket.

In dergelijke gevallen is het essentieel om de toepassing te onderzoeken waardoor het opnieuw instellen (geïdentificeerd door poortnummers) wordt veroorzaakt om te begrijpen waarom de verbinding opnieuw wordt ingesteld.

Notitie

De voorgaande informatie heeft betrekking op het opnieuw instellen van een TCP-perspectief en niet van UDP. UDP is een verbindingsloos protocol en pakketten worden onbetrouwbare verzonden. Daarom worden hertransmissies of resets niet waargenomen bij het gebruik van UDP als transportprotocol. UDP maakt echter gebruik van ICMP als een protocol voor foutrapportage. Wanneer een UDP-pakket wordt verzonden naar een poort die niet op de bestemming wordt vermeld, reageert de bestemming onmiddellijk met het bericht 'Doelhost onbereikbaar: Poort onbereikbaar'.

10.10.10.1  10.10.10.2  UDP UDP:SrcPort=49875,DstPort=3343
 
10.10.10.2  10.10.10.1  ICMP    ICMP:Destination Unreachable Message, Port Unreachable,10.10.10.2:3343

Tijdens het oplossen van problemen met TCP/IP-connectiviteit ziet u mogelijk in de netwerktracering dat een machine pakketten ontvangt, maar niet hierop reageert. Dit kan duiden op een daling in de netwerkstack van de doelserver.

Als u wilt bepalen of het pakket wordt verwijderd door de lokale Windows Firewall, schakelt u controle in voor het Windows-filterplatform (WFP) op de computer met behulp van de volgende opdracht.

auditpol /set /subcategory:"Filtering Platform Packet Drop" /success:enable /failure:enable

Vervolgens kunt u de beveiligingsgebeurtenislogboeken bekijken om een pakketuitval op een specifieke TCP-poort en een specifiek IP-adres te identificeren, samen met een bijbehorende WFP-filter-id.

Voer vervolgens de opdracht netsh wfp show state uit waarmee een wfpstate.xml-bestand wordt gegenereerd.

U kunt dit bestand openen met Kladblok en filteren op de id in de gebeurtenislogboeken (bijvoorbeeld 2944008 in de voorbeeldgebeurtenis). Het resultaat toont de naam van de firewallregel die is gekoppeld aan de filter-id die de verbinding blokkeert.