Så här felsöker du TCP / IP-anslutning och konfigurationsproblem
När du behöver se till att program på servern kan anslutas ordentligt, hjälper den allmänna felsökningen inte. Det kräver avancerade sätt att felsöka TCP / IP-anslutning speciellt när du har mycket timeout-fel. Anslutningsproblemet kan relateras till databasservern, RDP-fel, fildelning och så vidare.
På en grundläggande nivå, när data skickas från en punkt till en annan via TCP, i slutändan, överensstämmer både avsändare och mottagare med att informationen är vad den ska vara, och det är okej. När det finns ett problem med TCP, fortsätter en av sidorna att vänta (TIME_WAIT-tillstånd), det kan vara det plötsliga slutet på sessionerna, vilket resulterar i RESET-flaggan i TCP-rubriken.
Felsöka TCP / IP-anslutning
Den här RESET-flaggan kan ses genom verktyget Message Analyzer eller något av nätverksövervakningsverktygen som kan hjälpa dig att räkna ut TCP-header. Rubriken bär information som hjälper till att identifiera om det uppstod ett problem, särskilt RESET-flaggan. Tänk dig att varje data som skickas har en rubrik eller sändare som ger information om varifrån data finns.
När du använder Message Analyzer måste du konfigurera serverns IP-adress, portnumret om det finns tillgängligt och gräva i varje spårresultat för detaljerad information. Om det finns något fel markerar verktyget det. Klicka på den, och du ska kunna se nivån på felmeddelandet för det paketet. Det är lätt att använda, men då behöver det också en korrekt förståelse för hur man använder den.
Hitta packet droppar
När data skickas och inget svar tas emot från andra änden betyder det att det finns en paketförlust. Källan väntar på bekräftelse, och när det inte accepteras kommer det att skicka en ping med ACK RESET-flaggan. Denna flagg innebär att eftersom det inte fanns någon bekräftelse betyder det att det kan vara paketdroppar eller dataförlust och följaktligen är anslutningen tappad.
Det betyder vanligtvis att nätverksenheten däremellan har något problem. Använd nätverksverktyget för att övervaka portarna och köra spårprogrammet. Om du inte ser samma spårresultat, vet du att problemet är någonstans däremellan.Den felaktiga parametern i TCP-huvudet
Mellan enheter och programvara ändrar vanligtvis TCP-huvuden. Det är standard på datorer där internet säkerhetsprogram ändrar certifikaten som kommer från HTTPS-kompatibla webbplatser. Enheter som WAN-acceleratorer kan göra detsamma.IT-administratören måste titta på konfigurationen för dessa maskinvaruenheter för att lösa detta problem.
För att räkna ut det, har du spårat spåret på både källa och destination, och om resultaten skiljer sig, särskilt TCP-paketets detaljer, har vi ett problem.
Återställning av programsidan
Om spåren inte visar något probabilistisk kan det vara den applikation som orsakar problemet. Det händer när servern har accepterat om mottagna data men inte accepterar anslutningen. Så ansökan skulle vara som att det inte fanns någonting, och du skulle undra att alla länkar är på plats.
Du kan identifiera detta scenario genom att titta på TCP-flaggor. Om paketet har ACK + RST betyder det att applikationen orsakar problemet, det vill säga destination / server av någon anledning vill inte acceptera paketet av någon anledning.
Om din ansökan använder UDP, blir det svårt att hitta det på så sätt. I stället måste du använda ICMP som ett felrapporteringsprotokoll. Om du märker meddelandet ICMP Destination värd unreachable: Port unreachable meddelande omedelbart efter UDP-paketet, är applikationen orsaken.
tips:
- Under felsökningen kan det vara brandväggsproblemet om du ser allt bra, men servern inte svarar. Var noga med att omkonfigurera brandväggen för att hålla portarna eller programmet raderade. Du måste titta på både lokal och server brandvägg.
- Läs även loggarna för säkerhetshändelser. Du kan övervaka om det finns en paketdroppe på en viss port-IP.
