Felsöka TCP/IP-anslutning

Prova vår virtuella agent – Det kan hjälpa dig att snabbt identifiera och åtgärda vanliga Active Directory-replikeringsproblem.

Gäller för: Versioner av Windows-klienten och Windows Server som stöds

Den här artikeln innehåller en omfattande guide för felsökning av TCP/IP-anslutningsfel.

Symptom och analys

Du kan stöta på anslutningsproblem på programnivå eller så kan det uppstå timeout-fel. Här är några vanliga scenarier:

• Programanslutning till en databasserver
• SQL-timeoutfel
• Timeout-fel för BizTalk-program
• RDP-fel (Remote Desktop Protocol)
• Fel vid filresursåtkomst
• Allmän anslutning

När ett nätverksrelaterat problem misstänks rekommenderar vi att du samlar in ett nätverkspaket. Den här avbildningen kan filtreras för att identifiera den problematiska TCP-anslutningen och fastställa orsaken till felet.

Under felsökningsprocessen kan du stöta på en TCP RESET i nätverksfångsten, vilket kan tyda på ett nätverksproblem.

Introduktion av TCP

TCP karakteriseras som ett anslutningsorienterat och tillförlitligt protokoll. Det säkerställer tillförlitlighet genom handskakningsprocessen. En TCP-session initieras med ett trevägshandskakning följt av dataöverföring och avslutas med en fyrvägsstängning.

• En fyrvägsstängning, där både avsändaren och mottagaren går med på att stänga sessionen, kallas en graciös stängning. Detta identifieras av FIN-flaggan i TCP-huvudet som anges till 1.

• Efter fyrvägsstängningen väntar datorn i 4 minuter (som standard) innan porten släpps. Detta kallas TIME_WAIT tillstånd. Under den här TIME_WAIT kan väntande paket för TCP-anslutningen bearbetas. När TIME_WAIT-tillståndet har slutförts frigörs alla resurser som allokerats för anslutningen.

• En TCP-återställning är en plötslig stängning av sessionen, vilket gör att allokerade resurser omedelbart frisläpps och all anslutningsinformation raderas. Detta identifieras av reset-flaggan i TCP-huvudet som anges till 1. En nätverksspårning som samlas in samtidigt på källan och målet hjälper dig att fastställa trafikflödet och identifiera felpunkten.

I följande avsnitt beskrivs scenarier där en ÅTERSTÄLLNING kan ske.

Paketförlust över nätverket

När en TCP-peer skickar paket utan att ta emot ett svar, överför peer-peer data igen. Om det fortfarande inte finns något svar avslutas sessionen med en ACK-återställning, vilket indikerar att programmet bekräftar de utbytna data men stänger anslutningen på grund av paketförlust.

Samtidiga nätverksspårningar både på källan och målet kan verifiera det här beteendet. På källsidan kan du se de återöverförda paketen. På målsidan finns inte dessa paket. Det här scenariot anger att en nätverksenhet mellan källan och målet släpper paketen.

Scenario 1: Paketförlust under inledande TCP-handskakning

Om den inledande TCP-handskakningen misslyckas på grund av att paketet sjunker, överförs TCP SYN-paketet tre gånger som standard.

Kommentar

Antalet gånger som TCP SYN-paketet överförs på nytt kan skilja sig beroende på operativsystemet. Detta bestäms av värdet Max SYN Retransmissions under globala TCP-parametrar , som kan visas med kommandot netsh int tcp show global.

Anta att en källdator med IP-adress 10.10.10.1 ansluter till målet med IP-adress 10.10.10.2 via TCP-port 445. Följande är en skärmbild av nätverksspårningen som samlas in på källdatorn, som visar den första TCP-handskakningen där TCP SYN-paketet skickas och sedan överförs på nytt av källan eftersom inget svar togs emot från målet.

Samma TCP-konversation som visas i nätverksspårningen som samlats in på målet visar att inget av ovanstående paket togs emot av målet. Detta innebär att TCP SYN-paketet släpptes över det mellanliggande nätverket.

Om TCP SYN-paketen når målet, men målet inte svarar, kontrollerar du om TCP-porten som är ansluten till är i läget LYSSNA på måldatorn. Detta kan kontrolleras i utdata från kommandot netstat -anob.

Om porten lyssnar och det fortfarande inte finns något svar kan det finnas en droppe på Windows Filtering Platform (WFP).

Scenario 2: Paketförlust vid dataöverföring efter TCP-anslutningsetablering

I ett scenario där ett datapaket som skickas efter att TCP-anslutningen har upprättats släpps över nätverket, överför TCP paketet fem gånger som standard.

Anta att en källdator med IP-adressen 192.168.1.62 har upprättat en anslutning till måldatorn med IP-adress 192.168.1.2 via TCP-port 445. Källdatorn skickar data (SMB Negotiate-paket) som överförs fem gånger, enligt nedan. Efter inget svar från målet skickar källdatorn en ACK-RST för att stänga den här TCP-anslutningen.

Källa 192.168.1.62 sidospårning:

Du skulle inte se något av ovanstående paket nå målet.

Du måste kontakta ditt interna nätverksteam för att undersöka de olika hoppen mellan källan och målet och kontrollera om något av hoppen potentiellt orsakar paketförluster.

Felaktig parameter i TCP-huvudet

Det här beteendet inträffar när mellanliggande enheter i nätverket ändrar paket, vilket gör att TCP i den mottagande änden avvisar dem. TCP-sekvensnumret kan till exempel ändras, eller så kan paketen spelas upp igen av en mellanliggande enhet med ett ändrat TCP-sekvensnummer.

En samtidig nätverksspårning på källan och målet kan hjälpa dig att identifiera eventuella ändringar i TCP-huvudena.

Börja med att jämföra käll- och målspårningarna för att identifiera eventuella ändringar i paketen eller förekomsten av nya paket som når målet för källans räkning.

I sådana fall rekommenderar vi att du söker hjälp från det interna nätverksteamet för att identifiera alla enheter som ändrar eller spelar upp paket till målet. Vanliga syndare är Riverbed-enheter eller WAN-acceleratorer.

Återställning på programnivå

När du har fastställt att återställningarna inte beror på paketförluster, felaktiga parametrar eller paketändringar (som identifieras via nätverksspårningar) kan du dra slutsatsen att problemet är en återställning på programnivå.

Återställningar på programnivå kännetecknas av att flaggan Bekräftelse (ACK) anges till 1 tillsammans med flaggan Återställ (R). Detta indikerar att servern bekräftar mottagandet av paketet, men accepterar inte anslutningen av någon anledning. Det här problemet uppstår vanligtvis när programmet som tar emot paketet finner något oacceptabelt i data.

I skärmbilderna nedan kan du se att paketen på både källan och målet är identiska, utan ändringar eller droppar. En explicit återställning skickas dock av målet till källan.

Spårning på källsidan:

Spårning på målsidan:

Ett ACK+RST-flaggat TCP-paket kan också inträffa när ett TCP SYN-paket skickas ut. TCP SYN-paketet initieras av källdatorn för att upprätta en anslutning på en specifik port. Men om målservern inte vill acceptera paketet av någon anledning svarar servern med ett ACK+RST-paket.

I sådana fall är det viktigt att undersöka programmet som orsakar återställningen (identifieras med portnummer) för att förstå varför anslutningen återställs.

Kommentar

Ovanstående information gäller återställningar från ett TCP-perspektiv och inte UDP. UDP är ett anslutningslöst protokoll och paket skickas opålitligt. Därför observeras inte återöverföringar eller återställningar när UDP används som ett transportprotokoll. UDP använder dock ICMP som ett protokoll för felrapportering. När ett UDP-paket skickas till en port som inte visas på målet svarar målet omedelbart med meddelandet "Målvärden kan inte nås: Porten kan inte nås".

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

Under felsökningen av TCP/IP-anslutningsproblem kan du se i nätverksspårningen att en dator tar emot paket men inte svarar på dem. Detta kan tyda på en droppe i målserverns nätverksstack.

Om du vill ta reda på om den lokala Windows-brandväggen släpper paketet aktiverar du granskning för Windows-filtreringsplattformen (WFP) på datorn med hjälp av följande kommando.

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

Du kan sedan granska säkerhetshändelseloggarna för att identifiera ett paketfall på en specifik TCP-port och IP-adress, tillsammans med ett associerat WFP-filter-ID.

Kör sedan kommandot netsh wfp show state som genererar en wfpstate.xml fil.

Du kan öppna den här filen med anteckningar och filtrera efter det ID som finns i händelseloggarna (till exempel 2944008 i exempelhändelsen). Resultatet visar namnet på brandväggsregeln som är associerat med filter-ID:t som blockerar anslutningen.