Slik feilsøker du TCP / IP-tilkobling og konfigurasjonsproblemer
Når du må sørge for at applikasjoner på serveren kan koble riktig, hjelper ikke den generelle feilsøkingen. Det krever avanserte måter å feilsøk TCP / IP-tilkobling spesielt når du har mye timeout-feil. Tilkoblingsproblemet kan være relatert til databaseserveren, RDP-feil, fildeling og så videre.
På grunnleggende nivå, når data sendes fra ett punkt til et annet via TCP, til slutt, er både avsender og mottaker enig i at informasjon er hva den skal være, og ting er greit. Når det oppstår et problem med TCP, holder en av sidene venter (TIME_WAIT-tilstand), det kan være brått i nærheten av øktene, noe som resulterer i RESET-flagget i TCP-overskriften.
Feilsøk TCP / IP-tilkobling
Dette RESET-flagget kan ses gjennom verktøyet Meldingsanalysator eller et av nettverksovervåkingsverktøyene som kan hjelpe deg med å finne ut TCP-overskriften. Overskriften gir informasjon som bidrar til å identifisere om det oppsto et problem, spesielt RESET-flagg. Tenk deg at alle sendte data har en header eller sender som gir informasjon om hvor data er plassert.
Når du bruker meldingsanalysatoren, må du sette opp IP-adressen til serveren, portnummeret hvis tilgjengelig, og grave inn i hvert sporresultat for detaljert informasjon. Hvis det oppstår feil, markerer verktøyet det. Klikk på den, og du bør kunne se nivået på feilmeldingen for den pakken. Det er enkelt å bruke, men da trenger det også en riktig forståelse av hvordan du bruker den.
Finne pakkedråper
Når data sendes, og det ikke mottas noe svar fra den andre enden, betyr det at det er et tap av pakken. Kilden venter på bekreftelse, og når den ikke aksepteres, vil den sende en ping med ACK RESET-flagg. Dette flagget betyr at siden det ikke var noen bekreftelse, betyr det at det kan være pakkedråper eller datatap og dermed forbindelsen blir droppet.
Det betyr vanligvis at nettverksenheten i mellom har noe problem. Bruk nettverksverktøyet til å overvåke portene og kjøre sporingsprogrammet. Hvis du ikke ser de samme sporresultatene, vet du at problemet er et mellomrom.Den feilaktige parameteren i TCP-overskriften
Innenfor enheter og programvare endrer vanligvis TCP-overskrifter. Det er standard på datamaskiner hvor Internett-sikkerhetsprogramvaren endrer sertifikatene som kommer fra HTTPS-kompatible nettsteder. Enheter som WAN-akseleratorer kan gjøre det samme. En admin må se på konfigurasjonen av disse maskinvareenhetene for å løse dette problemet.
For å finne ut dette, har du sporet sporet på både kilde og destinasjon, og hvis resultatene avviger, spesielt TCP-pakkedetaljer, har vi et problem.
Tilbakestilling av applikasjonssiden
Hvis sporene ikke viser noe probabilistisk, kan det være søknaden som forårsaker problemet. Det skjer når serveren har akseptert om mottatte data, men godtar ikke tilkoblingen. Så programmet ville være som det ikke fikk noe, og du ville lure på at alle koblinger er på plass.
Du kan identifisere dette scenariet ved å se på TCP-flaggene. Hvis pakken har ACK + RST betyr det at programmet forårsaker problemet, det vil si at destinasjon / server av en eller annen grunn ikke ønsker å godta pakken av en eller annen grunn.
Hvis søknaden din bruker UDP, vil det være vanskelig å finne det på denne måten. I stedet må du bruke ICMP som en feilrapporteringsprotokoll. Hvis du merker meldingen ICMP Destination host unreachable: Port unreachable melding umiddelbart etter UDP-pakken, er applikasjonen årsaken.
Tips:
- Under feilsøking, hvis du ser alt i orden, men serveren ikke svarer, kan det være brannmuren problemet. Pass på at du konfigurerer brannmuren for å holde disse portene eller applikasjonen ren. Du må se på både lokal og server brannmur.
- Se også sikkerhetshendelsesloggene. Du kan overvåke om det er en pakkedråp på en bestemt port-IP.
