Windows पर पैकेट कैप्चर व्यवहार में — pktmon, netsh trace और Wireshark में से चुनना

«व्यवसाय ऐप का सर्वर संचार महीने में कुछ बार विफल होता है। ऐप लॉग केवल ‘timeout’ लिखता है। उस समय सर्वर-पक्ष लॉग में मेल खाती त्रुटि नहीं। हम नहीं जानते कैसे दोहराएँ» — बग-जाँच परामर्श में यह आकार लगातार आता है।

ऐप लॉग केवल वही रखता है जो ऐप ने «लिखने का फैसला किया»। आप देखते हैं कि परिणाम timeout है, पर कनेक्ट अनुरोध (SYN) का जवाब न मिला, कनेक्शन बना फिर सर्वर चुप हो गया, RST से टूटा, या पैकेट गंतव्य तक पहुँचा भी — लॉग से एक परत नीचे रहता है — उन पैकेटों में जो सच में तार पर गए। यदि Process Monitor फ़ाइल और रजिस्ट्री पहुँच को एक परत नीचे देखने का तरीका है, पैकेट कैप्चर बातचीत को एक परत नीचे देखने का तरीका है।

flowchart TB
    accTitle: ऐप लॉग से एक परत नीचे के पैकेट
    accDescr: ऐप लॉग केवल वही रखता है जो ऐप ने लिखने का फैसला किया; SYN का जवाब न मिलना, कनेक्ट के बाद चुप्पी, RST से टूटना, या पैकेट पहुँचना केवल उन पैकेटों में रहता है जो सच में तार पर गए
    log["ऐप लॉग"] --> dec["केवल लिखने का फैसला बचा रहता है"]
    dec --> to["परिणाम एक-शब्द timeout है"]
    to -->|एक परत नीचे देखें| pkt["पैकेट जो सच में तार पर गए"]
    pkt --> q1["SYN का जवाब नहीं?"]
    pkt --> q2["कनेक्ट के बाद चुप्पी?"]
    pkt --> q3["RST से टूटा?"]
    pkt --> q4["गंतव्य तक पहुँचा?"]

चित्र 1: लॉग केवल परिणाम रखता है; timeout का टूटना केवल एक परत नीचे के पैकेटों में रहता है।

जहाँ लोग अटकते हैं वह बाधा है «ग्राहक सर्वर पर Wireshark नहीं लगा सकते»। वे साइटें जहाँ परिवर्तन नियंत्रण या सुरक्षा नीति जाँच के लिए अतिरिक्त सॉफ़्टवेयर नहीं मंज़ूर करतीं, दुर्लभ नहीं। पर Windows पहले से दो पैकेट-कैप्चर टूल भेजता है: pktmon और netsh trace। अंतर्निहित OS टूल से कैप्चर करें, बना फ़ाइल अपने PC पर ले जाएँ, और Wireshark में पढ़ें — उस विभाजन से इंस्टॉल-निषिद्ध साइट पर भी पैकेट दिखते हैं।

यह लेख छोटे-मझोले उद्यमों के आईटी कर्मचारियों और Windows ऐप डेवलपरों के लिए है। यह pktmon, netsh trace और Wireshark में चयन तथा प्रत्येक की व्यावहारिक प्रक्रिया व्यवस्थित करता है। लूपबैक ट्रैफ़िक के जाल, क्लाइंट या सर्वर पर कैप्चर का निर्णय, TLS के पेलोड छिपाने के साथ जीना, और कैप्चर को ऐप लॉग से जोड़ना — सब अगस्त 2026 तक के प्राथमिक स्रोतों से।

1. पहले निष्कर्ष

• «अंतर्निहित टूल से कैप्चर, Wireshark से पढ़ें» मैदान पर मूल विभाजन है। ग्राहक सर्वर पर सॉफ़्टवेयर न लग सके तो भी pktmon और netsh trace Windows में बने हैं। कैप्चर लॉग को pcapng में बदलें और अपने मशीन पर Wireshark में विश्लेषण करें।¹²
• pktmon Windows 10 / Windows Server 2019 और बाद का अंतर्निहित पैकेट-कैप्चर टूल है। चार कदमों में — फ़िल्टर दर्ज करें, शुरू, रोकें, रूपांतरित करें — और इसकी खास ताकत यह देखना है कि नेटवर्क स्टैक के किस घटक ने पैकेट गिराया (drop कारण)।³⁴
• netsh trace पुराना अंतर्निहित टूल है; यह ETW प्रदाताओं का समूह «परिदृश्य» के रूप में चालू कर सकता है। पैकेटों के अलावा यह Windows घटकों के अंदर की घटनाएँ रखता है, और persistent=yes से कैप्चर रीबूट पार बच सकता है।⁵⁶
• दोनों टूल ETL लिखते हैं जिसे Wireshark जैसा का तैसा नहीं खोल सकता। pktmon के लिए pktmon etl2pcap से, netsh trace के लिए Microsoft के ओपन-सोर्स etl2pcapng से pcapng बनाएँ।¹²
• Microsoft स्वयं «पहले pktmon, फिर यदि वह पर्याप्त न हो तो netsh trace, और प्रोटोकॉल विश्लेषण के लिए Wireshark» बताती है। इस लेख का विभाजन उसी आधिकारिक सिफ़ारिश का अनुसरण करता है।⁷
• डिफ़ॉल्ट में pktmon प्रत्येक पैकेट के केवल पहले 128 बाइट रिकॉर्ड करता है। यदि Wireshark में पेलोड पढ़ना हो तो शुरू करते समय --pkt-size 0 (पूरा पैकेट रिकॉर्ड) न भूलें।⁸
• localhost का ट्रैफ़िक सामान्य कैप्चर में नहीं दिखता। वह NIC से कभी नहीं जाता। Wireshark में Npcap लूपबैक एडाप्टर, या अंतर्निहित टूल से pktmon का स्टैक-भीतर कैप्चर इस्तेमाल करें।⁹
• TLS पेलोड छिपाए तो भी बहुत कुछ सीख सकते हैं। कनेक्ट स्थापना, TLS हैंडशेक सफल हुआ या नहीं, RST, और कौन सा पक्ष चुप हुआ एन्क्रिप्ट रहने पर भी दिखता है। SSLKEYLOGFILE से डिक्रिप्शन केवल विकास-पर्यावरण तकनीक है।¹⁰
• कैप्चर में संचार स्वयं होता है। मानें कि साख और व्यक्तिगत जानकारी शामिल हो सकती है, और न्यूनतम आवश्यक कैप्चर तथा सौंपने से पहले संकीर्ण करना प्रक्रिया में बाँधें।

2. तीन कैप्चर टूल और उनमें चयन

पहले, तीनों टूल की भूमिकाओं की एक तालिका।

एक वाक्य में, pktmon और netsh trace «कैप्चर» टूल हैं, और Wireshark «पढ़ने» का टूल है। Wireshark कैप्चर भी कर सकता है, पर जहाँ इंस्टॉल नहीं हो सकता वहाँ वह काम नहीं आता। उलटा, अंतर्निहित टूल के ETL को पाठ बनाकर पढ़ सकते हैं, पर बिना प्रदर्शन फ़िल्टर और बिना TCP विश्लेषण घूरना दुख है। «मैदान पर अंतर्निहित टूल से कैप्चर, pcapng में बदलें, अपने मशीन पर Wireshark में पढ़ें» सीमित साइट पर सबसे छोटा रास्ता है।

flowchart TB
    accTitle: अंतर्निहित टूल से कैप्चर, Wireshark से पढ़ें
    accDescr: मैदान पर pktmon या netsh trace से ETL कैप्चर करें, प्रत्येक को उसके रूपांतरण टूल से pcapng बनाएँ, और अपने मशीन पर Wireshark में विश्लेषण करें
    pk["pktmon（अंतर्निहित）"] --> etla["ETL फ़ाइल"]
    ns["netsh trace（अंतर्निहित）"] --> etlb["ETL+.cab"]
    etla -->|pktmon etl2pcap| pcap["pcapng"]
    etlb -->|etl2pcapng| pcap
    pcap --> ws["अपने मशीन पर Wireshark में विश्लेषण"]

चित्र 2: मैदान पर अंतर्निहित टूल से ETL कैप्चर करें, pcapng बनाएँ, और अपने मशीन पर Wireshark में पढ़ें।

Microsoft की पैकेट-हानि जाँच मार्गदर्शिका का आकार वही है: पहले pktmon से कैप्चर कर कारण अलग करें, फिर यदि वह पर्याप्त न हो तो netsh trace start scenario=InternetClient जैसे घटक-स्तर ट्रेस पर जाएँ, और Wireshark में प्रोटोकॉल व्यवहार विश्लेषण करें।⁷

पैकेट वास्तव में क्या दिखाता है पढ़ने की पूर्वपेक्षा के रूप में, स्तरित परतों — Ethernet, IP, TCP, अनुप्रयोग डेटा — की तस्वीर भी मदद करती है। परत शरीर-रचना «Getting a Real Feel for the OSI Model» में चित्रित है।

3. व्यवहार में pktmon — फ़िल्टर, शुरू, रोकें, रूपांतरित करें

pktmon का मूल प्रवाह चार कदम है। उन्हें ऊँचे अधिकार वाले टर्मिनल में चलाएँ।

:: 1. लक्ष्य संकीर्ण करने के लिए पहले फ़िल्टर पंजीकृत करें (सर्वर 192.168.10.20 पर TCP 8443)
pktmon filter add App8443 -i 192.168.10.20 -t tcp -p 8443
pktmon filter list

:: 2. कैप्चर शुरू करें। पूरे पैकेट रिकॉर्ड करें, 1GB रिंग बफ़र में ओवरराइट करें
pktmon start --capture --pkt-size 0 --file-name C:\temp\app-timeout.etl --file-size 1024 --log-mode circular

:: 3. घटना दोहराएँ। प्रतीक्षा के दौरान counters से मात्रा और ड्रॉप जाँच सकते हैं
pktmon counters --drop-reason

:: 4. रोकें, फिर Wireshark के लिए pcapng में बदलें
pktmon stop
pktmon etl2pcap C:\temp\app-timeout.etl --out C:\temp\app-timeout.pcapng

:: 5. पंजीकृत फ़िल्टर साफ़ करें (फ़िल्टर स्पष्ट रूप से हटाने तक रह जाते हैं)।
::    ध्यान: filter remove नाम नहीं ले सकता; यह «सभी» पंजीकृत फ़िल्टर हटाता है।
::    जिस मशीन पर किसी अन्य जाँच के फ़िल्टर रह सकते हों, पहले pktmon filter list से जाँचें
pktmon filter remove

flowchart TB
    accTitle: मूल pktmon प्रक्रिया
    accDescr: फ़िल्टर से लक्ष्य संकीर्ण करें, कैप्चर शुरू करें, घटना दोहराएँ, रोकें, etl2pcap से pcapng बनाएँ, और अंत में दर्ज फ़िल्टर हटाएँ
    fa["1. filter add से लक्ष्य संकीर्ण करें"] --> st["2. start --capture से कैप्चर शुरू"]
    st --> re["3. घटना दोहराएँ"]
    re -.-> ct["काउंटर से मात्रा और drop जाँचें"]
    re --> sp["4. रोकें"]
    sp --> cv["etl2pcap से pcapng बनाएँ"]
    cv --> rm["5. filter remove से साफ़ करें"]

चित्र 3: pktmon फ़िल्टर पंजीकरण से शुरू होता है, फिर कैप्चर, रोक और रूपांतरण, और अंत में फ़िल्टर स्पष्ट हटाते हैं।

ध्यान रखने योग्य बिंदु:

• कैप्चर शुरू करने से पहले फ़िल्टर दर्ज करें। Microsoft का दस्तावेज़ भी शुरू से पहले फ़िल्टर लगाने की दृढ़ सिफ़ारिश करता है, क्योंकि सारा ट्रैफ़िक कैप्चर बहुत शोर है। फ़िल्टर IP पता, पोर्ट, MAC पता, प्रोटोकॉल, VLAN ID आदि निर्दिष्ट कर सकते हैं, और 32 तक दर्ज हो सकते हैं। कई फ़िल्टर OR हैं: कोई भी मेल खाए तो पैकेट रिकॉर्ड होता है।³
• pktmon फ़िल्टर स्रोत और गंतव्य नहीं अलग करता। -i 192.168.10.20 का अर्थ है «पैकेट जहाँ यह पता स्रोत या गंतव्य हो»। दिशा बाद में रूपांतरण के बाद Wireshark प्रदर्शन फ़िल्टर से संकीर्ण करें।³
• डिफ़ॉल्ट पैकेट आकार 128 बाइट है। हेडर विश्लेषण के लिए पर्याप्त है, पर अनुप्रयोग डेटा भी चाहिए तो --pkt-size 0 से पूरा पैकेट रिकॉर्ड करें।⁸
• लॉग डिफ़ॉल्ट वृत्ताकार (रिंग-बफ़र) मोड है, डिफ़ॉल्ट आकार 512MB। --file-size से सीमा बदल सकते हैं, और --log-mode real-time स्क्रीन पर तुरंत छापता है और लॉग फ़ाइल नहीं बनाता। पहले वास्तविक-समय मोड में पुष्टि करें कि आप सच में वांछित ट्रैफ़िक देख रहे हैं, फिर उत्पादन कैप्चर सेट करें, और खाली लेना बचता है।⁸

flowchart TB
    accTitle: pktmon फ़िल्टर कैसे लागू होते हैं
    accDescr: कई दर्ज फ़िल्टर OR मेल पर रिकॉर्ड करते हैं, निर्दिष्ट पता स्रोत और गंतव्य नहीं अलग करता, और दिशा रूपांतरण के बाद Wireshark प्रदर्शन फ़िल्टर से संकीर्ण होती है
    f1["फ़िल्टर 1"] --> orc["कोई भी मेल खाए तो रिकॉर्ड"]
    f2["फ़िल्टर 2"] --> orc
    f3["फ़िल्टर 3（32 तक）"] --> orc
    orc --> rec["कैप्चर लॉग में रिकॉर्ड（OR）"]
    rec -.-> nodir["स्रोत और गंतव्य अलग नहीं"]
    nodir -.-> ws["रूपांतरण के बाद Wireshark में दिशा संकीर्ण करें"]

चित्र 4: कई फ़िल्टर OR की तरह काम करते हैं, और होस्ट स्रोत है या गंतव्य रूपांतरण के बाद Wireshark में संकीर्ण होता है।

3.1. जो केवल pktmon कर सकता है — देखना पैकेट कहाँ गिरा

Wireshark के मुकाबले pktmon का खास मूल्य यह है कि यह पैकेट को एक NIC पर नहीं, नेटवर्क स्टैक के अंदर कई बिंदुओं पर कैप्चर करता है, और बता सकता है कहाँ और क्यों गिरा (drop)। क्योंकि आप देख सकते हैं पैकेट किस घटक तक पहुँचा और कहाँ गायब हुआ, «MTU मेल नहीं» या «VLAN फ़िल्टर» जैसे drop कारण बिना अंधा खोजे कारण तक पहुँचाते हैं।⁴

flowchart TB
    accTitle: pktmon स्टैक के अंदर कई बिंदुओं पर कैप्चर करता है
    accDescr: pktmon पैकेट को एक NIC पर नहीं नेटवर्क स्टैक के अंदर कई बिंदुओं पर कैप्चर करता है, इसलिए कारण सहित बता सकता है पैकेट किस घटक तक पहुँचा और कहाँ गिरा
    pin["पैकेट"] --> p1["बिंदु 1 पर कैप्चर"]
    p1 --> p2["बिंदु 2 पर कैप्चर"]
    p2 --> p3["बिंदु 3 पर गिरा"]
    p3 -.-> rz["drop स्थान और कारण बताता है"]
    rz -.-> ex["जैसे MTU मेल नहीं या VLAN फ़िल्टर"]

चित्र 5: स्टैक के अंदर कई बिंदुओं पर कैप्चर बताता है पैकेट कितनी दूर गया और कहाँ गिरा, कारण सहित।

• pktmon list निगरानी योग्य नेटवर्क घटक (NIC, प्रोटोकॉल स्टैक, फ़िल्टर ड्राइवर आदि) और उनके ID दिखाता है।
• pktmon counters --drop-reason प्रत्येक घटक के pass/drop काउंटर और सबसे हाल drop कारण सूचीबद्ध करता है। लॉग विश्लेषण से पहले पहले कट के रूप में सुविधाजनक।¹¹
• pktmon etl2txt से पाठ में बदलें और गिरे पैकेट drop तथा dropReason के साथ निकलते हैं।³

संदेह कि «OS में कुछ ऐप तक पहुँचने से पहले इसे गिरा रहा है» केवल Wireshark घूरकर नहीं सुलझता। यह क्षमता उदाहरण के लिए फ़ायरवॉल के इनबाउंड नियम न होने से गिराने के मामले अलग करने में मदद करती है («The Windows Firewall and Business Applications»)।

एक चेतावनी। pktmon वही पैकेट स्टैक के कई बिंदुओं पर रिकॉर्ड करता है, इसलिए जैसा का तैसा pcapng बनाने से वही पैकेट एक से अधिक बार दिख सकता है। pcapng «किस घटक ने यह कैप्चर किया» नहीं ले जाता, इसलिए Wireshark में पढ़ते समय मानक चाल --component-id से एक बिंदु चुनकर रूपांतरित करना है (या --drop-only से केवल drop अलग फ़ाइल में रखना)।¹

flowchart TB
    accTitle: pcapng रूपांतरण के बाद वही पैकेट दो बार क्यों दिख सकता है
    accDescr: pktmon वही पैकेट स्टैक के कई बिंदुओं पर रिकॉर्ड करता है, pcapng यह नहीं रखता कि किस घटक ने कैप्चर किया इसलिए डुप्लिकेट दिख सकते हैं, और मानक चाल component-id से बिंदु संकीर्ण करके रूपांतरित करना या drop-only फ़ाइल में केवल drop रखना है
    same["वही पैकेट कई बिंदुओं पर रिकॉर्ड"] --> conv["जैसा का तैसा pcapng बनाएँ"]
    conv --> lost["कैप्चर-बिंदु जानकारी नहीं जाती"]
    lost --> dup["वही पैकेट एक से अधिक बार दिखता है"]
    dup --> c1["--component-id से बिंदु संकीर्ण करें"]
    dup --> c2["--drop-only से अलग फ़ाइल"]

चित्र 6: कैप्चर-बिंदु जानकारी pcapng में नहीं जाती, इसलिए मानक चाल रूपांतरण से पहले बिंदु संकीर्ण करना है।

4. व्यवहार में netsh trace — परिदृश्य, ETL, और रीबूट पार बचने वाले कैप्चर

netsh trace वह ट्रेस तंत्र है जो Windows में pktmon से अधिक समय से है। इसकी विशेषता यह है कि «परिदृश्य» के रूप में वह उस समस्या से जुड़े पूरे ETW प्रदाता सेट को एक साथ चालू कर सकता है।⁶

:: List available scenarios and inspect the providers in a scenario
netsh trace show scenarios
netsh trace show scenario netconnection

:: Start the capture. Packet capture included, 1GB circular buffer
netsh trace start scenario=netconnection capture=yes tracefile=C:\temp\nettrace.etl maxSize=1024 filemode=circular

:: Reproduce the incident, then stop (the merge takes a little time)
netsh trace stop

• पैकेट कैप्चर चालू करने के लिए capture=yes जोड़ें, और ipv4.address=192.168.10.20 जैसे कैप्चर फ़िल्टर से लक्ष्य संकीर्ण करें। फ़िल्टर सूची netsh trace show capturefilterHelp में है।⁶
• रोकने से ETL के अलावा .cab फ़ाइल बनती है। .cab में एडाप्टर विन्यास और OS बिल्ड जैसी सिस्टम जानकारी होती है, इसलिए यह वातावरण संग्रह भी बनता है।⁶
• एक समय में केवल एक ट्रेस सत्र चल सकता है। दूसरा कैप्चर शुरू करने से पहले netsh trace show status से जाँचें कि कोई बचा सत्र अभी चल तो नहीं रहा।⁶
• persistent=yes जोड़ें और सत्र रीबूट पार बचता है। «रीबूट के तुरंत बाद संचार एक क्षण विफल» या «स्टार्टअप पर सेवा कनेक्शन विफल» — घटनाएँ जिन्हें हाथ से समय पर शुरू नहीं कर सकते — netsh trace की अनूठी ज़मीन है।⁵

flowchart TB
    accTitle: netsh trace परिदृश्य कैप्चर करना
    accDescr: परिदृश्य से शुरू करने से ETW प्रदाताओं का समूह चालू होता है, capture=yes पैकेट भी कैप्चर करता है, और रोकने से ETL फ़ाइल तथा .cab फ़ाइल बनती है
    sc["परिदृश्य से शुरू करें"] --> pv["प्रदाता सेट चालू करें"]
    sc -->|capture=yes| pc["पैकेट भी कैप्चर होते हैं"]
    pv --> re["घटना दोहराएँ"]
    pc --> re
    re --> sp["रोकें"]
    sp --> etl["ETL फ़ाइल"]
    sp --> cab[".cab（सिस्टम जानकारी）"]

चित्र 7: परिदृश्य से शुरू करने से प्रदाताओं का समूह चालू होता है, और रोकने से ETL तथा .cab बनते हैं।

4.1. ETL को Wireshark में पठनीय बनाना — etl2pcapng

netsh trace ETL Wireshark में जैसा का तैसा नहीं खुलता। etl2pcapng, Microsoft का GitHub पर प्रकाशित ओपन-सोर्स टूल, netsh trace start capture=yes से कैप्चर ETL के अंदर के पैकेट को pcapng बनाता है।²

etl2pcapng.exe C:\temp\nettrace.etl C:\temp\nettrace.pcapng

रूपांतरण पर etl2pcapng प्रत्येक पैकेट से जुड़े प्रक्रिया ID को पैकेट टिप्पणी के रूप में लिखता है। Wireshark में «यह किस प्रक्रिया का ट्रैफ़िक है» देखना मदद करता है जब एक ही सर्वर पर कई ऐप बात कर रहे हों।²

ETW-घटना पक्ष (परिदृश्य प्रदाताओं द्वारा रिकॉर्ड Windows-आंतरिक घटनाएँ) pcapng में नहीं बदलता। यदि घटनाएँ भी चाहिए तो netsh trace convert input=C:\temp\nettrace.etl से पाठ आदि बनाएँ, या ETL Windows Performance Analyzer में खोलें।⁵⁷

flowchart TB
    accTitle: netsh trace ETL पढ़ना दो पथों में बँटता है
    accDescr: ETL के अंदर पैकेट etl2pcapng से pcapng बनते हैं और Wireshark में पढ़े जाते हैं; ETW घटनाएँ pcapng नहीं बनतीं, इसलिए उन्हें netsh trace convert या Windows Performance Analyzer से पढ़ें
    etl["netsh trace ETL"] --> pk["पैकेट"]
    etl --> ev["ETW घटनाएँ"]
    pk -->|etl2pcapng| pc["pcapng बनाएँ"]
    pc --> ws["Wireshark में पढ़ें"]
    pc -.-> pid["प्रक्रिया ID टिप्पणी रहती है"]
    ev -.-> no["pcapng नहीं बनता"]
    no --> alt["convert या WPA से पढ़ें"]

चित्र 8: ETL में से पैकेट पढ़ने के लिए pcapng बनते हैं; ETW घटनाएँ दूसरे साधन से पढ़ी जाती हैं।

5. Wireshark में पढ़ने की पहली झलक — प्रदर्शन फ़िल्टर और TCP विश्लेषण

pcapng खोलने के बाद पहले प्रदर्शन फ़िल्टर से शोर काटें। आम वाले तालिका में हैं।¹²¹³

tcp.analysis.* विश्लेषण झंडे हैं जो Wireshark TCP अनुक्रम संख्याओं का पीछा कर लगाता है। पुनःप्रेषण, डुप्लिकेट ACK, क्रम से बाहर, ZeroWindow आदि यंत्रवत पकड़े जाते हैं, इसलिए पढ़ना शुरू करने का मानक तरीका पहले tcp.analysis.flags टाइप कर «समस्या जैसी» जगहों की सूची बनाना है।¹³

timeout जाँच में निम्नलिखित आकार क्रम से देखें।

1. क्या तीन-तरफ़ा हैंडशेक पूरा हुआ? क्या तीन पैकेट SYN → SYN/ACK → ACK सब हैं? यदि SYN बिना जवाब दोहराया जाए तो वह साथी तक नहीं पहुँचा, या बीच में चुपचाप गिरा (विशिष्ट फ़ायरवॉल पैटर्न)।
2. RST किस पक्ष ने भेजा? SYN पर तुरंत RST का अर्थ है गंतव्य पोर्ट पर कोई सुन नहीं रहा; कनेक्शन बनने के बाद RST का अर्थ है एक पक्ष ने कनेक्शन जबरन गिराया। RST का स्रोत IP «किसने काटा» का सीधा प्रमाण है।
3. क्या पुनःप्रेषण जारी हैं? उसी खंड का बार-बार पुनःप्रेषण संकेत है कि स्वीकृति (ACK) भेजने वाले तक नहीं लौट रही। बाहर गया डेटा खोया या लौटता ACK खोया, एक-तरफ़ा कैप्चर से नहीं सुलझता (इसलिए अगले अध्याय में «दोनों पक्षों पर कैप्चर» मायने रखता है)। पुनःप्रेषण और timeout अधिक गहराई से «Why TCP Retransmissions Stall Industrial Camera Communication» में हैं।
4. क्या ZeroWindow मौजूद है? वह संकेत है कि प्राप्त करने वाला ऐप सॉकेट से पढ़ नहीं रहा और प्राप्त बफ़र भरा है। यह प्राप्त ऐप के डिज़ाइन («The Misconception That TCP Lets You Receive in the Same Units You Send») पर संदेह का आधार है, नेटवर्क पर नहीं।

flowchart TB
    accTitle: timeout जाँच में देखने वाले आकारों का क्रम
    accDescr: तीन-तरफ़ा-हैंडशेक पूर्णता, RST की उपस्थिति और स्रोत, जारी पुनःप्रेषण, फिर ZeroWindow पुष्टि कर कारण पर पहला निशान लगाएँ
    hs{"SYN का जवाब मिला?"} -->|नहीं| ng["कभी नहीं पहुँचा（विशिष्ट फ़ायरवॉल）"]
    hs -->|हाँ| rs{"RST मौजूद है?"}
    rs -->|हाँ| who["RST स्रोत ने काटा"]
    rs -->|नहीं| rt{"पुनःप्रेषण जारी?"}
    rt -->|हाँ| ack["ACK नहीं लौट रहा"]
    rt -->|नहीं| zw{"ZeroWindow मौजूद?"}
    zw -->|हाँ| app["प्राप्तकर्ता पढ़ नहीं रहा"]

चित्र 9: हैंडशेक, RST, पुनःप्रेषण, फिर ZeroWindow इसी क्रम में देखने से अगली जगह संकीर्ण होती है।

पैकेट एक-एक पढ़ने से पहले आँकड़ा सुविधाओं से पूरी तस्वीर लेना भी मदद करता है। [Statistics] → [Conversations] «कौन सा IP जोड़ा / पोर्ट जोड़ा कब से कब तक कितना बोला» की सूची है, इसलिए वांछित बातचीत पहचानकर केवल उसी पर फ़िल्टर करें। [Statistics] → [I/O Graph] समय पर मात्रा का ग्राफ़ है; «इस समय से एक दिशा चुप» जैसे आकार उभरते हैं। रुचि की TCP बातचीत पर दायाँ क्लिक कर [Follow] → [TCP Stream] चुनें और उस कनेक्शन का आदान-प्रदान सादे पाठ में पढ़ सकते हैं।

flowchart TB
    accTitle: आँकड़ों से तस्वीर लें, फिर बातचीत संकीर्ण करें
    accDescr: Conversations में कौन सी बातचीत कब कितनी हुई सूचीबद्ध करें, I/O Graph से चुप अंतराल पकड़ें, रुचि की बातचीत पर फ़िल्टर करें, और TCP स्ट्रीम के रूप में पढ़ें
    ov["आँकड़ों से पूरी तस्वीर लें"] --> cv["Conversations में बातचीत सूची"]
    ov --> io["I/O Graph पर मात्रा देखें"]
    cv --> flt["रुचि की बातचीत पर फ़िल्टर"]
    io -.-> mute["चुप अंतराल दिख जाता है"]
    flt --> fs["TCP स्ट्रीम के रूप में पढ़ें"]

चित्र 10: पैकेट-दर-पैकेट पढ़ने से पहले आँकड़ों से तस्वीर लें, रुचि की बातचीत संकीर्ण करें, फिर पढ़ें।

6. लूपबैक जाल — localhost का ट्रैफ़िक NIC से नहीं जाता

एक ही PC पर ऐपों के बीच संचार जाँचने की कोशिश — उदाहरण व्यवसाय ऐप localhost:8080 पर मध्य सेवा से जुड़ना — और «Wireshark में कुछ नहीं दिखता» पर अटकना क्लासिक जाल है।

कारण स्पष्ट है। localhost (127.0.0.1) का ट्रैफ़िक भौतिक NIC से कभी नहीं जाता; वह OS के आंतरिक लूपबैक पथ पर घूम जाता है। भौतिक एडाप्टर लक्ष्य करने वाला सामान्य कैप्चर इसलिए उसे कभी नहीं देखता।⁹

flowchart TB
    accTitle: localhost ट्रैफ़िक कैप्चर में क्यों नहीं दिखता
    accDescr: localhost ट्रैफ़िक भौतिक NIC से नहीं जाता और OS आंतरिक लूपबैक पथ पर घूमता है, इसलिए भौतिक एडाप्टर लक्ष्य करने वाले सामान्य कैप्चर में कभी नहीं दिखता
    app["ऐप"] --> stack["नेटवर्क स्टैक"]
    stack -->|बाहरी| nic["भौतिक NIC"]
    nic --> seen["सामान्य कैप्चर में दिखता है"]
    stack -->|localhost| lo["OS में घूम जाता है"]
    lo -.-> miss["सामान्य कैप्चर में नहीं"]
    lo -.-> alt["Npcap लूपबैक या pktmon"]

चित्र 11: localhost ट्रैफ़िक NIC से पहले घूम जाता है, इसलिए भौतिक-एडाप्टर कैप्चर उसे कभी नहीं देखता।

निपटने के दो तरीके हैं।

• Wireshark में कैप्चर करते समय: कैप्चर लक्ष्य के रूप में Npcap का «Adapter for loopback traffic capture» चुनें। Windows Wireshark इंस्टॉलर (3.0 और बाद) Npcap बाँधता है, इसलिए Wireshark पहले से लगा हो तो अतिरिक्त काम नहीं।⁹
• अंतर्निहित टूल से कैप्चर करते समय: pktmon NIC के बाहर नहीं, नेटवर्क स्टैक के अंदर कई बिंदुओं पर कैप्चर करता है⁴, इसलिए लूपबैक ट्रैफ़िक भी देख सकता है। पक्का करने के लिए, उत्पादन प्रतीक्षा सेट करने से पहले उस मशीन पर pktmon start -c -m real-time वास्तविक-समय प्रदर्शन से पुष्टि करें कि वांछित लूपबैक ट्रैफ़िक सच में दिख रहा है।

दो उलझनों पर भी नज़र रखें।

• «localhost» IPv6 ::1 पर हल हो सकता है। ऐप IPv6 ::1 से जुड़ रहा है, पर जाँचकर्ता केवल 127.0.0.1 (IPv4) देखकर गलत निष्कर्ष निकालता है «ट्रैफ़िक नहीं»। प्रदर्शन फ़िल्टर दोनों पर फैलाएँ, जैसे ip.addr == 127.0.0.1 || ipv6.addr == ::1, या ऐप की गंतव्य सेटिंग स्पष्ट पता बनाएँ।⁹
• अपने वास्तविक IP का ट्रैफ़िक भी तार पर नहीं जाता। जब वही PC 192.168.10.5 से 192.168.10.5 जुड़ता है, गंतव्य वास्तविक IP है पर OS फिर भी उसे अंदर घुमाता है। याद रखें «मैंने वास्तविक IP लिखा, इसलिए NIC से जाना चाहिए» गारंटी नहीं।

flowchart TB
    accTitle: उलझन जब localhost IPv6 पर हल हो
    accDescr: ऐप का localhost IPv6 ::1 पर हल हो सकता है, और जाँचकर्ता केवल 127.0.0.1 देखे तो गलत निष्कर्ष निकालता है कि ट्रैफ़िक नहीं, इसलिए प्रदर्शन फ़िल्टर दोनों पतों पर फैलाएँ या गंतव्य स्पष्ट पता बनाएँ
    app["ऐप localhost से जुड़ता है"] --> v6["वास्तव में ::1（IPv6） पर हल"]
    look["जाँचकर्ता केवल 127.0.0.1 देखता है"] --> none["स्क्रीन पर कुछ नहीं"]
    v6 --> none
    none --> fix1["फ़िल्टर दोनों पतों पर फैलाएँ"]
    none --> fix2["गंतव्य स्पष्ट पता बनाएँ"]

चित्र 12: उस उलझन पर नज़र रखें जहाँ localhost ::1 पर हल होता है और केवल 127.0.0.1 देखने से «ट्रैफ़िक नहीं» निकलता है।

7. कहाँ कैप्चर करें — एक पक्ष, दोनों पक्ष, और घड़ी समन्वय

कैप्चर का मूल्य «कहाँ कैप्चर किया» तय करता है। अंगूठे का नियम इस प्रकार है।

एक-तरफ़ा कैप्चर केवल «मेरी स्थिति से देखे तथ्य» बताता है। क्लाइंट पर जारी पुनःप्रेषण यह नहीं अलग करता कि भेजा पैकेट पथ पर गायब हुआ, या सर्वर तक पहुँचा और जवाब गायब हुआ। दोनों पक्षों पर कैप्चर कर पंक्तिबद्ध करें, और «क्लाइंट ने भेजा / सर्वर ने नहीं पाया» — कौन सा पक्ष चुप — सुलझता है। जब ज़िम्मेदारी सीमा (ऐप, OS, नेटवर्क उपकरण, या दूसरा सिरा) सुलझानी हो, शुरू से दोनों-पक्ष कैप्चर बनाना योग्य है।

flowchart TB
    accTitle: एक-तरफ़ा और दोनों-पक्ष कैप्चर क्या बताते हैं
    accDescr: एक-तरफ़ा कैप्चर यह नहीं अलग करता कि बाहर गया पैकेट गायब हुआ या लौटता जवाब गायब हुआ; दोनों पक्षों पर कैप्चर कर पंक्तिबद्ध करने से कौन सा पक्ष चुप सुलझता है
    one["एक पक्ष पर कैप्चर"] --> fact["आपके पक्ष के तथ्य"]
    fact --> und["बाहर या लौट?"]
    both["दोनों पक्षों पर कैप्चर"] --> mt["पंक्तिबद्ध करें"]
    mt --> fix["कौन सा पक्ष चुप"]
    mt -.-> pre["घड़ी समन्वय चाहिए"]

चित्र 13: एक पक्ष केवल आपके देखे तथ्य दिखाता है; दोनों पक्ष पंक्तिबद्ध करना ही ज़िम्मेदारी सीमा पहले सुलझाता है।

7.1. सहसंबंध की पूर्वपेक्षा घड़ी समन्वय है

दोनों पक्षों के कैप्चर पंक्तिबद्ध करने के लिए दोनों मशीनों की घड़ियाँ सहमत होनी चाहिए। कैप्चर शुरू करने से पहले घड़ी ऑफ़सेट जाँचें और रिकॉर्ड करें।

:: Check time-sync status (sync source, last sync time)
w32tm /query /status

:: Measure the offset against the peer server (5 samples)
w32tm /stripchart /computer:sv-app01 /dataonly /samples:5

w32tm /stripchart वह कमांड है जो आप और साथी कंप्यूटर के बीच समय ऑफ़सेट दिखाता है, और कैप्चर पंक्तिबद्ध करते समय «सर्वर घड़ी +0.8 सेकंड थी» जैसे सुधार का आधार बनता है।¹⁴ बड़े ऑफ़सेट वाले वातावरण में पहले समय समन्वय ठीक कर फिर कैप्चर करना अंत में छोटा रास्ता है।

flowchart TB
    accTitle: सहसंबंध से पहले घड़ी ऑफ़सेट जाँचने की प्रक्रिया
    accDescr: w32tm से अपना समय-समन्वय स्थिति पुष्टि करें, stripchart से साथी सर्वर के विरुद्ध ऑफ़सेट मापकर रिकॉर्ड करें, कैप्चर पंक्तिबद्ध करते समय उस ऑफ़सेट को सुधार आधार बनाएँ, और ऑफ़सेट बड़ा हो तो पहले समन्वय ठीक कर फिर कैप्चर करें
    st["query से समन्वय स्थिति जाँचें"] --> mc["stripchart से ऑफ़सेट मापें"]
    mc --> rc["ऑफ़सेट रिकॉर्ड करें"]
    rc --> use["सहसंबंध समय पर सुधार आधार"]
    mc -.-> big["ऑफ़सेट बड़ा हो तो पहले समन्वय ठीक करें"]

चित्र 14: कैप्चर से पहले घड़ी ऑफ़सेट मापकर रिकॉर्ड करें, और कैप्चर पंक्तिबद्ध करते समय सुधार आधार बनाएँ।

7.2. «कब होगा नहीं पता» के लिए — रिंग बफ़र

जिस घटना की पुनरुत्पादन शर्तें अज्ञात हों, मूल चाल रिंग बफ़र चला छोड़ना और घटना होने पर रोकना है।

• pktmon: डिफ़ॉल्ट वृत्ताकार मोड है। --file-size से सीमा (MB) सेट करें; पुराने पैकेट ओवरराइट होते हैं।⁸
• netsh trace: maxSize=1024 filemode=circular के रूप में निर्दिष्ट करें।⁵
• Wireshark: [Capture] → [Options] → [Output] के तहत «कई फ़ाइलें + रिंग बफ़र» विन्यास कर सकते हैं। फ़ाइल आकार या समय से घूमता है और केवल नवीनतम N फ़ाइलें रखता है, इसलिए डिस्क-उपयोग सीमा के साथ लंबा चल सकता है।¹⁵

हर मामले में मैदान के व्यक्ति के साथ नियम बाँटें कि घटना होने पर «पहले समय नोट करें, फिर» कैप्चर रोकें। रिंग बफ़र जितना अधिक प्रतीक्षा उतना अतीत मिटाता है, इसलिए घटना से रोक तक का पथ लंबा हो तो वांछित अंतराल ओवरराइट हो जाता है।

flowchart TB
    accTitle: रिंग-बफ़र कैप्चर से प्रतीक्षा
    accDescr: अज्ञात पुनरुत्पादन शर्तों वाली घटना के लिए रिंग बफ़र चला छोड़ें, घटना होने पर समय नोट कर तुरंत रोकें; देर से रोकें तो पुराने पैकेट ओवरराइट होते हैं और वांछित अंतराल गायब हो जाता है
    st["रिंग-बफ़र कैप्चर शुरू करें"] --> wt["चला छोड़ें और प्रतीक्षा करें"]
    wt --> ev["घटना होती है"]
    ev --> memo["समय नोट करें"]
    memo --> sp["तुरंत रोकें"]
    wt -.-> ow["पुराने पैकेट ओवरराइट होते हैं"]
    ow -.-> late["देर से रोकना वांछित अंतराल मिटाता है"]

चित्र 15: रिंग बफ़र जितना अधिक प्रतीक्षा उतना अतीत मिटाता है, इसलिए समय नोट कर तुरंत रोकें।

8. समस्या कि TLS पेलोड छिपाता है — फिर भी क्या दिखता है

आज अधिकांश व्यवसाय ट्रैफ़िक TLS (HTTPS) है। लोग सोचते हैं «एन्क्रिप्ट हो तो कैप्चर व्यर्थ», पर timeout जाँच में जो चाहिए उसका अधिकांश एन्क्रिप्शन रहते हुए भी दिखता है।

• TCP कनेक्शन स्थापित हुआ या नहीं (तीन-तरफ़ा हैंडशेक)
• TLS हैंडशेक कितनी दूर गया — ClientHello पर ServerHello लौटा या नहीं, हैंडशेक के दौरान RST या अलर्ट से कटा या नहीं
• ClientHello पर गंतव्य होस्ट नाम (SNI), और समझौता TLS संस्करण
• कनेक्शन खड़ा होने के बाद कौन सा पक्ष भेजना बंद किया। चुप्पी का स्थान, पुनःप्रेषण, RST, या साफ़ बंद (FIN)

अर्थात् «जुड़ नहीं सकता», «बीच में गिरता है», और «जवाब नहीं लौटता» अलग करना लगभग कभी पेलोड डिक्रिप्शन नहीं माँगता। एन्क्रिप्शन जो खोता है वह «उन्होंने क्या कहा» है; «कौन चुप हुआ, और कब» रहता है।

flowchart TB
    accTitle: TLS कैप्चर क्या दिखा सकता है और क्या नहीं
    accDescr: एन्क्रिप्शन केवल अनुप्रयोग-डेटा पेलोड छिपाता है; TCP कनेक्ट स्थापना, TLS हैंडशेक सफलता या विफलता, SNI और TLS संस्करण, RST, और कौन सा पक्ष चुप हुआ एन्क्रिप्शन रहते हुए भी दिखता है
    tls["TLS ट्रैफ़िक कैप्चर"] --> vis["दिखता है"]
    tls --> hid["नहीं दिखता"]
    vis --> v1["TCP कनेक्ट सेटअप"]
    vis --> v2["TLS परिणाम और SNI"]
    vis --> v3["RST / कौन चुप"]
    hid --> h1["ऐप-डेटा पेलोड"]

चित्र 16: एन्क्रिप्शन केवल पेलोड खोता है; बातचीत का कंकाल TLS रहते हुए भी पठनीय है।

जब फिर भी पेलोड चाहिए, Wireshark SSLKEYLOGFILE पर्यावरण चर से लिखी सत्र कुंजियों से TLS डिक्रिप्ट कर सकता है। समर्थन Firefox, Chrome, Chromium-आधारित Edge, और OpenSSL-परिवार लाइब्रेरी जैसे कुछ कार्यान्वयन तक सीमित है; Windows अंतर्निहित SChannel (WinHTTP या WinINET इस्तेमाल करने वाले ऐप) इस तंत्र का समर्थन नहीं करता।¹⁰ क्योंकि «सत्र कुंजी फ़ाइल में लिखी जाती है» का अर्थ है उस फ़ाइल वाला पूरा बातचीत डिक्रिप्ट कर सकता है, यह उत्पादन तकनीक नहीं; इसे विकास वातावरण में पुनरुत्पादन और डिबग मानें।

flowchart TB
    accTitle: SSLKEYLOGFILE डिक्रिप्शन कैसे काम करता है और उसकी सीमाएँ
    accDescr: SSLKEYLOGFILE से लिखी सत्र कुंजियाँ Wireshark को TLS डिक्रिप्ट करने देती हैं, पर केवल कुछ कार्यान्वयन जैसे Firefox और Chrome परिवार समर्थन करते हैं और SChannel नहीं; कुंजी फ़ाइल वाला बातचीत डिक्रिप्ट कर सकता है, इसलिए इसे केवल विकास-पर्यावरण तकनीक मानें
    env["SSLKEYLOGFILE सेट करें"] --> key["सत्र कुंजियाँ लिखें"]
    key --> ws["Wireshark में पढ़ें"]
    key -.-> risk["कुंजी धारक डिक्रिप्ट कर सकता है"]
    risk -.-> dev["केवल विकास"]
    env -.-> sup["केवल कुछ TLS स्टैक"]
    sup -.-> sch["SChannel: समर्थन नहीं"]

चित्र 17: सत्र कुंजियाँ लिखना डिक्रिप्ट कर सकता है, पर समर्थित कार्यान्वयन सीमित हैं, और कुंजी की प्रकृति इसे केवल विकास-पर्यावरण तकनीक बनाती है।

जब ट्रैफ़िक आंतरिक प्रॉक्सी से जाए, कैप्चर में दिखने वाला गंतव्य प्रॉक्सी सर्वर होता है, और TLS CONNECT सुरंग के अंदर बहता है। ऐप किस प्रॉक्सी की ओर जा रहा है यह पूर्व प्रश्न उसी दिन के साथी लेख «Corporate Proxies and Windows Apps — Sorting Out Proxy Resolution in WinINET, WinHTTP, and .NET» में व्यवस्थित है।

9. ऐप लॉग से सहसंबंध — समय को एक ही अक्ष पर रखना

कैप्चर अकेले शायद ही निष्कर्ष देता है। व्यवहार में निर्णायक चाल ऐप लॉग की एक पंक्ति और पैकेटों के एक चक्कर को एक ही समय-अक्ष पर रखना है।

प्रक्रिया इस प्रकार दिखती है।

1. ऐप लॉग से घटना समय पहचानें (उदाहरण, 10:23:41 पर timeout अपवाद)। यदि timeout मान 30 सेकंड है, शुरू लगभग 10:23:11 होना चाहिए।
2. Wireshark का समय प्रदर्शन [View] → [Time Display Format] → [Date and Time of Day] पर बदलें, और प्रदर्शन फ़िल्टर से अंतराल संकीर्ण करें (समय से भी फ़िल्टर कर सकते हैं, जैसे frame.time >= "2026-08-20 10:23:00" && frame.time <= "2026-08-20 10:24:00")।
3. उस अंतराल में अध्याय 5 क्रम (हैंडशेक → RST → पुनःप्रेषण → ZeroWindow) पुष्टि करें। यदि «लॉग के timeout समय से 30 सेकंड पहले SYN भेजा गया, और उसके बाद केवल SYN पुनःप्रेषण» तक पंक्तिबद्ध हो सके, लॉग का «timeout» अवलोकन «इस कैप्चर बिंदु पर कोई जवाब ही नहीं लौटा» से बदल जाता है (SYN साथी तक नहीं पहुँचा, या लौटता SYN/ACK रास्ते में खोया, केवल इस कैप्चर बिंदु से नहीं सुलझता। सुलझाना हो तो सर्वर पर कैप्चर कर पंक्तिबद्ध करें)।
4. कैप्चर समय और लॉग समय के बीच ऑफ़सेट हमेशा सुधारें (खंड 7.1 में मापा घड़ी ऑफ़सेट, और लॉग का टाइमज़ोन संकेत)। कुछ सेकंड की सहसंबंध त्रुटि गलत बातचीत को अपराधी ठोक देगी।

flowchart TB
    accTitle: ऐप लॉग और पैकेट पंक्तिबद्ध करने की प्रक्रिया
    accDescr: ऐप लॉग से घटना समय पहचानें, timeout मान से शुरू समय पीछे निकालें, Wireshark में प्रदर्शन फ़िल्टर से अंतराल संकीर्ण करें, आकार क्रम से पुष्टि करें, घड़ी ऑफ़सेट सुधारें, और उन्हें एक ही समय-अक्ष पर रखें
    lg["1. लॉग से घटना समय पहचानें"] --> rev["timeout मान से शुरू पीछे निकालें"]
    rev --> flt["2. प्रदर्शन फ़िल्टर से अंतराल संकीर्ण करें"]
    flt --> chk["3. अध्याय 5 क्रम में आकार पुष्टि करें"]
    chk --> adj["4. घड़ी ऑफ़सेट सुधारें"]
    adj --> done["लॉग का एक शब्द अवलोकन बनता है"]

चित्र 18: लॉग समय से अंतराल संकीर्ण करें, आकार पुष्टि करें, घड़ी ऑफ़सेट सुधारें, और उन्हें एक अक्ष पर रखें।

जब जाँच परिणाम तीसरे पक्ष (विक्रेता, वाहक, ग्राहक के नेटवर्क कर्मचारी) को सौंपें, सौंपने से पहले फ़िल्टर से शोर काटना शिष्टाचार और सुरक्षा उपाय दोनों है। Wireshark में प्रदर्शन फ़िल्टर से रुचि की बातचीत संकीर्ण करें और [File] → [Export Specified Packets] से «केवल प्रदर्शित पैकेट» सहेजें, तो केवल आवश्यक सीमा का छोटा pcapng मिलता है।

अंत में, व्यवहार चेतावनी। कैप्चर फ़ाइल में संचार स्वयं होता है। उसमें सादे-पाठ प्रोटोकॉल की साख, HTTP कुकी और API कुंजी, मेल या रिपोर्ट की सामग्री, और व्यक्तिगत जानकारी हो सकती है। निम्नलिखित तीन बिंदु कैप्चर प्रक्रिया के साथ एक सेट के रूप में तय करें।

• न्यूनतम आवश्यक कैप्चर: पूर्व-कैप्चर फ़िल्टर (अध्याय 3 और 4) से लक्ष्य संकीर्ण करें और समय खिड़की जितनी संभव छोटी रखें। ग्राहक वातावरण पर «सब कुछ कैप्चर कर लो» न करें
• सौंपने से पहले संकीर्ण करें: केवल लक्ष्य बातचीत निर्यात करें; असंबंधित तीसरे-पक्ष ट्रैफ़िक शामिल न करें। यदि संवेदनशील भाग रह जाएँ तो प्राप्तकर्ता से छिपाने या दूसरे साधन पर सहमत हों
• धारण और मिटाना: तय करें कैप्चर फ़ाइलें कहाँ रखी जाएँ, कितने समय, और कब मिटाई जाएँ, और जाँच समाप्त होने पर मिटाएँ

flowchart TB
    accTitle: कैप्चर फ़ाइल सौंपने से पहले तीन निर्णय
    accDescr: कैप्चर में संचार स्वयं होता है, इसलिए कैप्चर प्रक्रिया के साथ सेट के रूप में तय करें कि पूर्व-कैप्चर फ़िल्टर और समय खिड़की से न्यूनतम संकीर्ण करेंगे, सौंपने से पहले केवल लक्ष्य बातचीत निकालेंगे ताकि असंबंधित ट्रैफ़िक शामिल न हो, और धारण स्थान तथा अवधि तय कर जाँच के बाद मिटाएँगे
    cap["कैप्चर = ट्रैफ़िक"] --> p1["न्यूनतम कैप्चर करें"]
    cap --> p2["पहले लक्ष्य निकालें"]
    cap --> p3["धारण सेट करें, मिटाएँ"]
    p2 -.-> exp["फ़िल्टर कर निर्यात करें"]

चित्र 19: न्यूनतम कैप्चर, सौंपने से पहले संकीर्ण करना, तथा धारण और मिटाना कैप्चर प्रक्रिया के साथ सेट के रूप में तय करें।

10. सार

• ऐप लॉग के «timeout» से एक परत नीचे तार पर सच में गए पैकेट का तथ्य है। SYN का जवाब न मिला, RST ने कनेक्शन तोड़ा, पुनःप्रेषण जारी रहे, या ZeroWindow दिखा — अगली जगह बदल देता है।
• जहाँ Wireshark नहीं लगा सकते वहाँ भी Windows अंतर्निहित pktmon और netsh trace से कैप्चर हो जाता है। अंतर्निहित टूल से कैप्चर, अपने मशीन पर Wireshark से पढ़ें — वह विभाजन मूल रूप है।
• pktmon चार कदम: फ़िल्टर दर्ज करें → pktmon start --capture → pktmon stop → pktmon etl2pcap। डिफ़ॉल्ट 128 बाइट पर कटा है, इसलिए पेलोड चाहिए तो --pkt-size 0 न भूलें। drop स्थान और कारण देखना केवल pktmon की ताकत है।
• netsh trace ETW प्रदाताओं का समूह परिदृश्य के रूप में कैप्चर करता है, और persistent=yes से रीबूट पार बच सकता है। पढ़ने के लिए ETL को etl2pcapng से pcapng बनाएँ।
• Wireshark में tcp.analysis.flags से शुरू करें और हैंडशेक, RST, पुनःप्रेषण, ZeroWindow इसी क्रम में देखें। पहले Conversations और I/O Graph से तस्वीर लें फिर संकीर्ण करना तेज़ है।
• localhost ट्रैफ़िक NIC से कभी नहीं जाता, इसलिए साधारण तरीके से कैप्चर नहीं हो सकता। Npcap लूपबैक एडाप्टर या pktmon का स्टैक-भीतर कैप्चर इस्तेमाल करें।
• दोनों पक्षों पर कैप्चर कर पंक्तिबद्ध करें तो «कौन सा पक्ष चुप» सुलझता है। पूर्वपेक्षा घड़ी समन्वय (w32tm) है। अज्ञात पुनरुत्पादन शर्तों वाली घटना के लिए रिंग बफ़र से प्रतीक्षा करें।
• TLS के नीचे भी बातचीत का कंकाल दिखता है। डिक्रिप्शन (SSLKEYLOGFILE) को केवल विकास-पर्यावरण तकनीक मानें, और कैप्चर फ़ाइल स्वयं को गोपनीय मानें: न्यूनतम कैप्चर, संकीर्ण करना, और मिटाना संचालन में बाँधें।

पैकेट कैप्चर अक्सर «नेटवर्क विशेषज्ञ का टूल» समझा जाता है, पर व्यवहार में यह ऐप-पक्ष जाँच टूल है जिसका अर्थ तब शुरू होता है जब आप उसे ऐप लॉग से पंक्तिबद्ध करते हैं। अगली बार जब जाँच एक शब्द «timeout» पर रुके, एक परत नीचे देखें।

संबंधित लेख

• TCP पुनःप्रेषण औद्योगिक कैमरा संचार क्यों रोकते हैं, और उन्हें कैसे अलग करें
• यह भ्रम कि TCP आपको भेजने की वही इकाइयों में प्राप्त करने देता है — बाइट स्ट्रीम के इर्द-गिर्द प्राप्ति डिज़ाइन
• OSI मॉडल का वास्तविक अहसास — एक HTTP अनुरोध को उसकी सात परतों में चीरना
• Process Monitor (ProcMon) की व्यावहारिक मार्गदर्शिका — 10 मिनट में «सेटिंग लागू नहीं» और «ACCESS DENIED» इंगित करना
• Windows फ़ायरवॉल और व्यवसाय अनुप्रयोग — इंस्टॉलर से इनबाउंड नियम दर्ज करें
• कॉर्पोरेट प्रॉक्सी और Windows ऐप — WinINET, WinHTTP और .NET में प्रॉक्सी समाधान सुलझाना

संबंधित परामर्श क्षेत्र

KomuraSoft LLC संचार-मूल बग जाँच सँभालती है जैसे «व्यवसाय ऐप का संचार समय-समय पर विफल होता है और कारण नहीं मिलता» और «केवल ग्राहक वातावरण पर होने वाली कनेक्शन त्रुटि अलग करनी है»। हम कैप्चर डिज़ाइन (कहाँ, क्या, और कितना कैप्चर), Wireshark विश्लेषण, ऐप लॉग से सहसंबंध, और ऐप-पक्ष सुधार को एक सतत कार्य के रूप में लेते हैं।

• Windows ऐप विकास
• बग और कारणों की जाँच
• तकनीकी परामर्श और डिज़ाइन समीक्षा
• संपर्क करें

संदर्भ लिंक

संबंधित लेख

निकटवर्ती विषयों में गहराई से जाने के लिए समान टैग वाले नवीनतम लेख।

संबंधित विषय

ये पृष्ठ विषय को सेवाओं और निर्णयों के व्यापक संदर्भ में रखते हैं।

इस विषय से जुड़ी सेवाएँ

यह लेख निम्नलिखित सेवाओं से सीधे जुड़ा है।

अक्सर पूछे जाने वाले प्रश्न

इस लेख के विषय पर परामर्श में अक्सर पूछे जाने वाले प्रश्न।

ग्राहक सर्वर पर जहाँ Wireshark नहीं लगा सकते, पैकेट कैसे कैप्चर करें?

Windows के अंतर्निहित टूल pktmon या netsh trace इस्तेमाल करें और अतिरिक्त सॉफ़्टवेयर लगाए बिना कैप्चर कर सकते हैं। pktmon में ऊँचे अधिकार वाले टर्मिनल में फ़िल्टर दर्ज करें, pktmon start --capture से कैप्चर शुरू करें, और pktmon stop से रोकें। बना ETL फ़ाइल pktmon etl2pcap से pcapng बन जाती है, इसलिए विश्लेषण अपने मशीन पर Wireshark में ले जाएँ। "अंतर्निहित टूल से कैप्चर, Wireshark से पढ़ें" इंस्टॉल सीमित साइटों पर मूल विभाजन है।

pktmon इस्तेमाल करें या netsh trace?

यदि OS में pktmon है (Windows 10 / Windows Server 2019 और बाद), pktmon से शुरू करें। कमांड सरल हैं, आप देख सकते हैं कि नेटवर्क स्टैक का कौन सा घटक पैकेट गिराया (drop कारण), और pcapng रूपांतरण आत्मनिर्भर है। netsh trace तब बेहतर है जब पुराने OS पर कैप्चर करें जिसमें pktmon नहीं, जब Windows घटक ETW घटनाएँ परिदृश्य के रूप में इकट्ठा करनी हों, या जब कैप्चर रीबूट पार persistent=yes से बचे। Microsoft की समस्या-निवारण सामग्री भी यही क्रम बताती है: पहले pktmon, फिर यदि वह पर्याप्त न हो तो netsh trace।

localhost (127.0.0.1) का ट्रैफ़िक Wireshark में क्यों नहीं दिखता?

localhost का ट्रैफ़िक भौतिक NIC से कभी नहीं जाता; वह OS के आंतरिक लूपबैक पथ पर घूम जाता है। भौतिक एडाप्टर लक्ष्य करने वाला सामान्य कैप्चर इसलिए उसे कभी नहीं देखता। Wireshark में Npcap का "Adapter for loopback traffic capture" चुनें और लूपबैक ट्रैफ़िक कैप्चर हो जाता है। pktmon नेटवर्क स्टैक के अंदर कैप्चर करता है, इसलिए लूपबैक भी देख सकता है। दूसरी आम उलझन: "localhost" IPv6 ::1 पर हल होता है, इसलिए 127.0.0.1 देखने वाली स्क्रीन खाली रहती है — पता स्पष्ट लिखकर पुष्टि करें।

पैकेट कैप्चर में HTTPS (TLS) ट्रैफ़िक की सामग्री देख सकते हैं?

अनुप्रयोग-डेटा पेलोड एन्क्रिप्टेड है और दिखाई नहीं देता। बातचीत का "कंकाल" — TCP जुड़ना और टूटना, TLS हैंडशेक सफल हुआ या नहीं, RST तोड़ना, कौन सा पक्ष जवाब देना बंद किया — एन्क्रिप्ट रहने पर भी दिखता है, इसलिए अधिकांश timeout जाँच TLS एन्क्रिप्ट छोड़कर चल सकती है। यदि पेलोड चाहिए तो SSLKEYLOGFILE से डिक्रिप्शन है, पर केवल कुछ TLS कार्यान्वयन जैसे Firefox और Chrome परिवार समर्थन करते हैं; Windows अंतर्निहित SChannel समर्थित नहीं। तंत्र गुप्त कुंजी सामग्री लिखता है, इसलिए इसे केवल विकास-पर्यावरण विकल्प मानें।

कैप्चर फ़ाइल बाहरी सहायता डेस्क को भेजना सुरक्षित है?

जैसी है वैसी भेजना खतरनाक है। कैप्चर में संचार स्वयं होता है और सादे-पाठ प्रोटोकॉल की साख, कुकी, API कुंजी और व्यक्तिगत जानकारी शामिल हो सकती है। पहले कैप्चर समय पर फ़िल्टर और समय खिड़की न्यूनतम रखें, और सौंपने से पहले Wireshark प्रदर्शन फ़िल्टर से केवल लक्ष्य बातचीत निकालकर निर्यात करें। जो रह जाए, भेजने से पहले प्राप्तकर्ता से संवेदनशील भागों के व्यवहार (छिपाना, या दूसरे साधन से देना) पर सहमत हों। पहले तय करें कि कैप्चर फ़ाइलें कितने समय रखी जाएँगी और कब मिटाई जाएँगी।

लेखक की प्रोफ़ाइल

लेख के लेखक का परिचय पृष्ठ।

Go Komura

KomuraSoft LLC के प्रतिनिधि

Windows सॉफ़्टवेयर विकास, तकनीकी परामर्श और बग जाँच में विशेषज्ञ, विशेष रूप से मौजूदा सिस्टम वाली परियोजनाओं और पुनरुत्पादन में कठिन बग में।