Problemen met TCP/IP-connectiviteit oplossen

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

Van toepassing op: Windows 10

U kunt connectiviteitsfouten tegenkomen bij het einde van de toepassing of time-outfouten. Hier volgen de meest voorkomende scenario's:

• Toepassingsconnectiviteit met een databaseserver
• SQL-time-outfouten
• Time-outfouten voor BizTalk-toepassingen
• RDP-fouten (Remote Desktop Protocol)
• Fouten bij toegang tot bestandsshares
• Algemene connectiviteit

Wanneer u vermoedt dat het probleem zich op het netwerk bevindt, verzamelt u een netwerktracering. De netwerktracering wordt vervolgens gefilterd. Tijdens het oplossen van connectiviteitsfouten kunt u tcp opnieuw instellen tegenkomen in een netwerkopname die kan duiden op een netwerkprobleem.

• TCP wordt gedefinieerd als verbindingsgeoriënteerd en betrouwbaar protocol. Een van de manieren waarop TCP betrouwbaarheid garandeert, is via het handshakeproces. Het tot stand brengen van een TCP-sessie zou beginnen met een handshake in drie richtingen, gevolgd door gegevensoverdracht en vervolgens een vierrichtingssluiting. De vierrichtingssluiting waarbij zowel de afzender als de ontvanger het eens zijn over het sluiten van de sessie, wordt aangeduid als een goede afsluiting. Na de vierwegssluiting staat de server 4 minuten tijd toe (standaard), gedurende welke eventuele in behandeling zijnde pakketten op het netwerk moeten worden verwerkt. Deze periode is de TIME_WAIT status. Nadat de status TIME_WAIT is voltooid, worden alle resources die voor deze verbinding zijn toegewezen, vrijgegeven.
• TCP reset is een abrupte afsluiting van de sessie; hierdoor worden de resources die zijn toegewezen aan de verbinding onmiddellijk vrijgegeven en wordt alle andere informatie over de verbinding gewist.
• Tcp opnieuw instellen wordt geïdentificeerd door de vlag RESET in de TCP-header ingesteld op 1.

Een netwerktracering op de bron en de bestemming helpt u om de stroom van het verkeer te bepalen en te zien op welk moment de fout wordt waargenomen.

In de volgende secties worden enkele scenario's beschreven wanneer u een RESET ziet.

Pakketdalingen

Wanneer een TCP-peer TCP-pakketten verzendt waarvoor geen antwoord is ontvangen van het andere uiteinde, zou de TCP-peer de gegevens opnieuw verzenden en wanneer er geen antwoord is ontvangen, wordt de sessie beëindigd door een ACK RESET te verzenden (dit ACK RESET betekent dat de toepassing alle gegevens erkent die tot nu toe zijn uitgewisseld, maar vanwege pakketverval wordt de verbinding gesloten).

Met de gelijktijdige netwerktraceringen op bron en bestemming kunt u dit gedrag verifiëren, waarbij aan de bronzijde de pakketten worden weergegeven die opnieuw worden verzonden en op de bestemming geen van deze pakketten worden gezien. Dit scenario geeft aan dat het netwerkapparaat tussen de bron en de bestemming de pakketten verwijdert.

Als de eerste TCP-handshake mislukt vanwege pakketuitval, ziet u dat het TCP SYN-pakket slechts drie keer opnieuw wordt verzonden.

Verbinding aan bronzijde op poort 445:

Doelzijde: als u hetzelfde filter toepast, ziet u geen pakketten.

Voor de rest van de gegevens verzendt TCP de pakketten vijf keer opnieuw.

Brontracering 192.168.1.62:

Doeltracering 192.168.1.2:

U ziet geen van de bovenstaande pakketten. Engage uw netwerkteam om de verschillende hops te onderzoeken en te zien of een van deze hops mogelijk dalingen in het netwerk veroorzaakt.

Als u ziet dat de SYN-pakketten de bestemming bereiken, maar de bestemming nog steeds niet reageert, controleert u of de poort waarmee u verbinding probeert te maken zich in de luisterstatus bevindt. (Netstat-uitvoer helpt hierbij). Als de poort luistert en er nog steeds geen reactie is, kan er een wfp-daling zijn.

Onjuiste parameter in de TCP-header

U ziet dit gedrag wanneer de pakketten in het netwerk worden gewijzigd door middelste apparaten en TCP aan de ontvangende kant het pakket niet kan accepteren, zoals het reeksnummer dat wordt gewijzigd, of pakketten die opnieuw worden afgespeeld door middelste apparaat door het volgordenummer te wijzigen. Nogmaals, de gelijktijdige netwerktracering op de bron en bestemming kan u laten zien of een van de TCP-headers is gewijzigd. Begin met het vergelijken van de brontracering en doeltracering. U kunt zien of er een wijziging in de pakketten zelf is of dat er nieuwe pakketten de bestemming bereiken namens de bron.

In dit geval hebt u opnieuw hulp nodig van het netwerkteam om te identificeren welk apparaat pakketten wijzigt of pakketten opnieuw afspeelt naar de bestemming. De meest voorkomende zijn RiverBed-apparaten of WAN-accelerators.

Opnieuw instellen aan de toepassingszijde

Wanneer u hebt vastgesteld dat de resets niet worden veroorzaakt door opnieuw verzenden of onjuiste parameters of pakketten die zijn gewijzigd met behulp van netwerktracering, hebt u deze beperkt tot het opnieuw instellen op toepassingsniveau.

Het opnieuw instellen van de toepassing is degene waarbij de bevestigingsvlag is ingesteld op 1, samen met de vlag voor opnieuw instellen. Deze instelling betekent dat de server de ontvangst van het pakket erkent, maar om een of andere reden de verbinding niet accepteert. In deze fase is het moment waarop de toepassing die het pakket heeft ontvangen, iets niet bevalt dat het heeft ontvangen.

In de onderstaande schermopnamen ziet u dat de pakketten op de bron en de bestemming hetzelfde zijn zonder enige wijziging of daling, maar u ziet een expliciete reset die door de bestemming naar de bron wordt verzonden.

Bronzijde

Aan de doelzijde tracering

U ziet ook een ACK+RST-vlagpakket in een geval wanneer het TCP-instellingspakket SYN wordt verzonden. Het TCP SYN-pakket wordt verzonden wanneer de client verbinding wil maken op een bepaalde poort, maar als de bestemming/server om een of andere reden het pakket niet wil accepteren, wordt er een ACK+RST-pakket verzonden.

De toepassing die het opnieuw instellen veroorzaakt (geïdentificeerd door poortnummers) moet worden onderzocht om te begrijpen waardoor de verbinding opnieuw wordt ingesteld.

Opmerking

De bovenstaande informatie gaat over het opnieuw instellen vanuit een TCP-standpunt en niet over UDP. UDP is een verbindingsloos protocol en de pakketten worden onbetrouwbare verzonden. U ziet geen herverzending of opnieuw instellen wanneer u UDP als transportprotocol gebruikt. UDP maakt echter gebruik van ICMP als een protocol voor foutrapportage. Wanneer u het UDP-pakket op een poort hebt verzonden en de bestemming geen poort bevat, ziet u dat de bestemming de ICMP-doelhost onbereikbaar verzendt: Poort onbereikbaar direct na het UDP-pakket.

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 het connectiviteitsprobleem ziet u mogelijk ook in de netwerktracering dat een computer pakketten ontvangt, maar niet reageert. In dergelijke gevallen kan er een daling op serverniveau zijn. Als u wilt weten of de lokale firewall het pakket wegvalt, schakelt u de firewallcontrole op de computer in.

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

Vervolgens kunt u de beveiligingsgebeurtenislogboeken bekijken om te zien of er een pakket is verwijderd op een bepaald poort-IP-adres en een filter-id die eraan is gekoppeld.

Voer nu de opdracht netsh wfp show stateuit. Met deze uitvoering wordt een wfpstate.xml-bestand gegenereerd. Nadat u dit bestand hebt geopend en filtert op de id die u in de bovenstaande gebeurtenis (2944008) vindt, ziet u een firewallregelnaam die is gekoppeld aan deze id die de verbinding blokkeert.