Windows पर packet capture practically — pktmon, netsh trace और Wireshark में से चुनना

«Business app का server communication महीने में कुछ बार fail होता है। ऐप लॉग केवल ‘timeout’ लिखता है। उस समय server-side लॉग में matching error नहीं। हम नहीं जानते कैसे reproduce करें» — bug-investigation consulting में यह आकार लगातार आता है।

ऐप लॉग केवल वही रखता है जो ऐप ने «लिखने का फैसला किया»। आप देखते हैं कि result timeout है, पर connect request (SYN) का जवाब न मिला, connection बना फिर server चुप हो गया, RST से टूटा, या packet destination तक पहुँचा भी — लॉग से एक परत नीचे रहता है — उन packets में जो सच में wire पर गए। अगर Process Monitor फ़ाइल और registry access को एक परत नीचे देखने का तरीका है, packet capture बातचीत को एक परत नीचे देखने का तरीका है।

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

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

जहाँ लोग अटकते हैं वह बाधा है «customer server पर Wireshark install नहीं कर सकते»। वे sites जहाँ change control या security policy जाँच के लिए extra software नहीं मंज़ूर करतीं, दुर्लभ नहीं। पर Windows पहले से दो packet-capture tools भेजता है: pktmon और netsh trace। Built-in OS tool से capture करें, बनी फ़ाइल अपने PC पर ले जाएँ, और Wireshark में पढ़ें — उस division से install-निषिद्ध site पर भी packets दिखते हैं।

यह लेख SME के IT staff और Windows app developers के लिए है। यह pktmon, netsh trace और Wireshark में चयन तथा प्रत्येक की practical procedure व्यवस्थित करता है। Loopback traffic के जाल, client या server पर capture का निर्णय, TLS के payload छिपाने के साथ जीना, और capture को ऐप लॉग से जोड़ना — सब अगस्त 2026 तक के primary sources से।

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

• «Built-in tool से capture, Wireshark से पढ़ें» field पर मूल division of work है। Customer server पर software न लग सके तो भी pktmon और netsh trace Windows में बने हैं। Capture लॉग को pcapng में convert करें और अपने मशीन पर Wireshark में analyse करें।¹²
• pktmon Windows 10 / Windows Server 2019 और बाद का built-in packet-capture tool है। चार कदमों में — filter register करें, start, stop, convert — और इसकी खास ताकत यह देखना है कि network stack के किस component ने packet drop किया (drop reason)।³⁴
• netsh trace पुराना built-in tool है; यह ETW providers का समूह «scenario» के रूप में चालू कर सकता है। Packets के अलावा यह Windows components के अंदर की events रखता है, और persistent=yes से capture reboot के पार बच सकता है।⁵⁶
• दोनों tools ETL लिखते हैं जिसे Wireshark जैसा का तैसा नहीं खोल सकता। pktmon के लिए pktmon etl2pcap से, netsh trace के लिए Microsoft के open-source etl2pcapng से pcapng बनाएँ।¹²
• Microsoft स्वयं «पहले pktmon, फिर अगर वह काफ़ी न हो तो netsh trace, और protocol analysis के लिए Wireshark» बताती है। इस लेख का division उसी official recommendation का अनुसरण करता है।⁷
• Default में pktmon प्रत्येक packet के केवल पहले 128 bytes record करता है। अगर Wireshark में payload पढ़ना हो तो start करते समय --pkt-size 0 (पूरा packet record) न भूलें।⁸
• localhost का traffic सामान्य capture में नहीं दिखता। वह NIC से कभी नहीं जाता। Wireshark में Npcap loopback adapter, या built-in tool से pktmon का stack-के-अंदर capture इस्तेमाल करें।⁹
• TLS payload छिपाए तो भी बहुत कुछ सीख सकते हैं। Connect establishment, TLS handshake सफल हुआ या नहीं, RST, और कौन सा पक्ष चुप हुआ encrypt रहने पर भी दिखता है। SSLKEYLOGFILE से decryption केवल development-environment technique है।¹⁰
• Capture में communication स्वयं होता है। मानें कि credentials और personal data शामिल हो सकती है, और न्यूनतम ज़रूरी capture तथा सौंपने से पहले संकीर्ण करना procedure में बाँधें।

2. तीन capture tools और उनमें चयन

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

एक वाक्य में, pktmon और netsh trace «capture» tools हैं, और Wireshark «पढ़ने» का tool है। Wireshark capture भी कर सकता है, पर जहाँ install नहीं हो सकता वहाँ वह काम नहीं आता। उलटा, built-in tools के ETL को text बनाकर पढ़ सकते हैं, पर बिना display filter और बिना TCP analysis घूरना दुख है। «Field पर built-in tool से capture, pcapng में convert करें, अपने मशीन पर Wireshark में पढ़ें» restricted site पर सबसे छोटा रास्ता है।

flowchart TB
    accTitle: Built-in tool से capture, Wireshark से पढ़ें
    accDescr: Field पर pktmon या netsh trace से ETL capture करें, प्रत्येक को उसके conversion tool से pcapng बनाएँ, और अपने मशीन पर Wireshark में analyse करें
    pk["pktmon（built-in）"] --> etla["ETL फ़ाइल"]
    ns["netsh trace（built-in）"] --> etlb["ETL+.cab"]
    etla -->|pktmon etl2pcap| pcap["pcapng"]
    etlb -->|etl2pcapng| pcap
    pcap --> ws["अपने मशीन पर Wireshark में analysis"]

चित्र 2: Field पर built-in tool से ETL capture करें, pcapng बनाएँ, और अपने मशीन पर Wireshark में पढ़ें।

Microsoft की packet-loss जाँच guide का आकार वही है: पहले pktmon से capture कर reason अलग करें, फिर अगर वह काफ़ी न हो तो netsh trace start scenario=InternetClient जैसे component-level trace पर जाएँ, और Wireshark में protocol व्यवहार analyse करें।⁷

Packet वास्तव में क्या दिखाता है पढ़ने की prerequisite के रूप में, layered layers — Ethernet, IP, TCP, application data — की तस्वीर भी मदद करती है। Layer anatomy «Getting a Real Feel for the OSI Model» में चित्रित है।

3. Practically pktmon — filter, start, stop, convert

pktmon का मूल flow चार कदम है। उन्हें elevated (Administrator) terminal में चलाएँ।

:: 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 procedure
    accDescr: Filter से लक्ष्य संकीर्ण करें, capture start करें, event reproduce करें, stop करें, etl2pcap से pcapng बनाएँ, और अंत में दर्ज filters हटाएँ
    fa["1. filter add से लक्ष्य संकीर्ण करें"] --> st["2. start --capture से capture शुरू"]
    st --> re["3. Event reproduce करें"]
    re -.-> ct["Counters से मात्रा और drop जाँचें"]
    re --> sp["4. Stop करें"]
    sp --> cv["etl2pcap से pcapng बनाएँ"]
    cv --> rm["5. filter remove से साफ़ करें"]

चित्र 3: pktmon filter registration से शुरू होता है, फिर capture, stop और conversion, और अंत में filters स्पष्ट हटाते हैं।

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

• Capture start करने से पहले filter register करें। Microsoft का document भी start से पहले filter लगाने की दृढ़ recommendation करता है, क्योंकि सारा traffic capture बहुत शोर है। Filter IP address, port, MAC address, protocol, VLAN ID आदि specify कर सकते हैं, और 32 तक register हो सकते हैं। कई filters OR हैं: कोई भी match करे तो packet record होता है।³
• pktmon filter source और destination नहीं अलग करता। -i 192.168.10.20 का अर्थ है «packet जहाँ यह address source या destination हो»। Direction बाद में conversion के बाद Wireshark display filter से संकीर्ण करें।³
• Default packet size 128 bytes है। Header analysis के लिए काफ़ी है, पर application data भी चाहिए तो --pkt-size 0 से पूरा packet record करें।⁸
• लॉग default circular (ring-buffer) mode है, default आकार 512MB। --file-size से सीमा बदल सकते हैं, और --log-mode real-time स्क्रीन पर तुरंत छापता है और लॉग फ़ाइल नहीं बनाता। पहले real-time mode में confirm करें कि आप सच में वांछित traffic देख रहे हैं, फिर production capture सेट करें, और खाली लेना बचता है।⁸

flowchart TB
    accTitle: pktmon filters कैसे apply होते हैं
    accDescr: कई दर्ज filters OR match पर record करते हैं, specified address source और destination नहीं अलग करता, और direction conversion के बाद Wireshark display filter से संकीर्ण होती है
    f1["Filter 1"] --> orc["कोई भी match करे तो record"]
    f2["Filter 2"] --> orc
    f3["Filter 3（32 तक）"] --> orc
    orc --> rec["Capture लॉग में record（OR）"]
    rec -.-> nodir["Source और destination अलग नहीं"]
    nodir -.-> ws["Conversion के बाद Wireshark में direction संकीर्ण करें"]

चित्र 4: कई filters OR की तरह काम करते हैं, और host source है या destination conversion के बाद Wireshark में संकीर्ण होता है।

3.1. जो केवल pktmon कर सकता है — देखना packet कहाँ drop हुआ

Wireshark के मुकाबले pktmon का खास मूल्य यह है कि यह packet को एक NIC पर नहीं, network stack के अंदर कई बिंदुओं पर capture करता है, और बता सकता है कहाँ और क्यों drop हुआ। क्योंकि आप देख सकते हैं packet किस component तक पहुँचा और कहाँ गायब हुआ, «MTU mismatch» या «VLAN filter» जैसे drop reasons बिना अंधा खोजे कारण तक पहुँचाते हैं।⁴

flowchart TB
    accTitle: pktmon stack के अंदर कई बिंदुओं पर capture करता है
    accDescr: pktmon packet को एक NIC पर नहीं network stack के अंदर कई बिंदुओं पर capture करता है, इसलिए reason सहित बता सकता है packet किस component तक पहुँचा और कहाँ drop हुआ
    pin["Packet"] --> p1["बिंदु 1 पर capture"]
    p1 --> p2["बिंदु 2 पर capture"]
    p2 --> p3["बिंदु 3 पर drop"]
    p3 -.-> rz["Drop स्थान और reason बताता है"]
    rz -.-> ex["जैसे MTU mismatch या VLAN filter"]

चित्र 5: Stack के अंदर कई बिंदुओं पर capture बताता है packet कितनी दूर गया और कहाँ drop हुआ, reason सहित।

• pktmon list monitor-योग्य network components (NIC, protocol stack, filter drivers आदि) और उनके ID दिखाता है।
• pktmon counters --drop-reason प्रत्येक component के pass/drop counters और सबसे हाल drop reason सूचीबद्ध करता है। लॉग analysis से पहले पहले कट के रूप में सुविधाजनक।¹¹
• pktmon etl2txt से text में convert करें और drop हुए packets drop तथा dropReason के साथ निकलते हैं।³

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

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

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

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

4. Practically netsh trace — scenarios, ETL, और reboot के पार बचने वाले capture

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

:: 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

• Packet capture चालू करने के लिए capture=yes जोड़ें, और ipv4.address=192.168.10.20 जैसे capture filters से लक्ष्य संकीर्ण करें। Filter सूची netsh trace show capturefilterHelp में है।⁶
• रोकने से ETL के अलावा .cab फ़ाइल बनती है। .cab में adapter configuration और OS build जैसी system जानकारी होती है, इसलिए यह environment archive भी बनता है।⁶
• एक समय में केवल एक trace session चल सकता है। दूसरा capture start करने से पहले netsh trace show status से जाँचें कि कोई बचा session अभी चल तो नहीं रहा।⁶
• persistent=yes जोड़ें और session reboot के पार बचता है। «Reboot के तुरंत बाद communication एक क्षण fail» या «startup पर service connection fail» — events जिन्हें हाथ से समय पर start नहीं कर सकते — netsh trace की अनूठी ज़मीन है।⁵

flowchart TB
    accTitle: netsh trace scenario capture करना
    accDescr: Scenario से start करने से ETW providers का समूह चालू होता है, capture=yes packets भी capture करता है, और रोकने से ETL फ़ाइल तथा .cab फ़ाइल बनती है
    sc["Scenario से start करें"] --> pv["Provider set चालू करें"]
    sc -->|capture=yes| pc["Packets भी capture होते हैं"]
    pv --> re["Event reproduce करें"]
    pc --> re
    re --> sp["Stop करें"]
    sp --> etl["ETL फ़ाइल"]
    sp --> cab[".cab（system जानकारी）"]

चित्र 7: Scenario से start करने से providers का समूह चालू होता है, और रोकने से ETL तथा .cab बनते हैं।

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

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

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

Conversion पर etl2pcapng प्रत्येक packet से जुड़े process ID को packet comment के रूप में लिखता है। Wireshark में «यह किस process का traffic है» देखना मदद करता है जब एक ही server पर कई apps बात कर रहे हों।²

ETW-event पक्ष (scenario providers द्वारा record Windows-internal events) pcapng में नहीं बदलता। अगर events भी चाहिए तो netsh trace convert input=C:\temp\nettrace.etl से text आदि बनाएँ, या ETL Windows Performance Analyzer में खोलें।⁵⁷

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

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

5. Wireshark में पढ़ने की पहली झलक — display filters और TCP analysis

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

tcp.analysis.* analysis flags हैं जो Wireshark TCP sequence numbers का पीछा कर लगाता है। Retransmission, duplicate ACK, out of order, ZeroWindow आदि यंत्रवत पकड़े जाते हैं, इसलिए पढ़ना शुरू करने का मानक तरीका पहले tcp.analysis.flags टाइप कर «समस्या जैसी» जगहों की सूची बनाना है।¹³

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

1. क्या three-way handshake पूरा हुआ? क्या तीन packets SYN → SYN/ACK → ACK सब हैं? अगर SYN बिना जवाब दोहराया जाए तो वह साथी तक नहीं पहुँचा, या बीच में चुपचाप drop हुआ (विशिष्ट firewall pattern)।
2. RST किस पक्ष ने भेजा? SYN पर तुरंत RST का अर्थ है destination port पर कोई listen नहीं कर रहा; connection बनने के बाद RST का अर्थ है एक पक्ष ने connection जबरन गिराया। RST का source IP «किसने काटा» का सीधा प्रमाण है।
3. क्या retransmissions जारी हैं? उसी segment का बार-बार retransmission संकेत है कि acknowledgement (ACK) भेजने वाले तक नहीं लौट रही। बाहर गया data खोया या लौटता ACK खोया, एक-तरफ़ा capture से नहीं सुलझता (इसलिए अगले अध्याय में «दोनों पक्षों पर capture» मायने रखता है)। Retransmission और timeout अधिक गहराई से «Why TCP Retransmissions Stall Industrial Camera Communication» में हैं।
4. क्या ZeroWindow मौजूद है? वह संकेत है कि receive करने वाला ऐप socket से पढ़ नहीं रहा और receive buffer भरा है। यह receive ऐप के डिज़ाइन («The Misconception That TCP Lets You Receive in the Same Units You Send») पर संदेह का आधार है, network पर नहीं।

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

चित्र 9: Handshake, RST, retransmission, फिर ZeroWindow इसी क्रम में देखने से अगली जगह संकीर्ण होती है।

Packets एक-एक पढ़ने से पहले statistics सुविधाओं से पूरी तस्वीर लेना भी मदद करता है। [Statistics] → [Conversations] «कौन सा IP pair / port pair कब से कब तक कितना बोला» की सूची है, इसलिए वांछित conversation पहचानकर केवल उसी पर filter करें। [Statistics] → [I/O Graph] समय पर मात्रा का graph है; «इस समय से एक दिशा चुप» जैसे आकार उभरते हैं। रुचि की TCP conversation पर दायाँ क्लिक कर [Follow] → [TCP Stream] चुनें और उस connection का आदान-प्रदान plain text में पढ़ सकते हैं।

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

चित्र 10: Packet-दर-packet पढ़ने से पहले statistics से तस्वीर लें, रुचि की conversation संकीर्ण करें, फिर पढ़ें।

6. Loopback जाल — localhost का traffic NIC से नहीं जाता

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

कारण स्पष्ट है। localhost (127.0.0.1) का traffic physical NIC से कभी नहीं जाता; वह OS के internal loopback path पर घूम जाता है। Physical adapter को target करने वाला सामान्य capture इसलिए उसे कभी नहीं देखता।⁹

flowchart TB
    accTitle: localhost traffic capture में क्यों नहीं दिखता
    accDescr: localhost traffic physical NIC से नहीं जाता और OS internal loopback path पर घूमता है, इसलिए physical adapter target करने वाले सामान्य capture में कभी नहीं दिखता
    app["ऐप"] --> stack["Network stack"]
    stack -->|बाहरी| nic["Physical NIC"]
    nic --> seen["सामान्य capture में दिखता है"]
    stack -->|localhost| lo["OS में घूम जाता है"]
    lo -.-> miss["सामान्य capture में नहीं"]
    lo -.-> alt["Npcap loopback या pktmon"]

चित्र 11: localhost traffic NIC से पहले घूम जाता है, इसलिए physical-adapter capture उसे कभी नहीं देखता।

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

• Wireshark में capture करते समय: Capture target के रूप में Npcap का «Adapter for loopback traffic capture» चुनें। Windows Wireshark installer (3.0 और बाद) Npcap बाँधता है, इसलिए Wireshark पहले से लगा हो तो extra काम नहीं।⁹
• Built-in tool से capture करते समय: pktmon NIC के बाहर नहीं, network stack के अंदर कई बिंदुओं पर capture करता है⁴, इसलिए loopback traffic भी देख सकता है। पक्का करने के लिए, production wait सेट करने से पहले उस मशीन पर pktmon start -c -m real-time real-time display से confirm करें कि वांछित loopback traffic सच में दिख रहा है।

दो confusions पर भी नज़र रखें।

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

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

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

7. कहाँ capture करें — एक पक्ष, दोनों पक्ष, और clock sync

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

एक-तरफ़ा capture केवल «मेरी स्थिति से देखे तथ्य» बताता है। Client पर जारी retransmissions यह नहीं अलग करता कि भेजा packet path पर गायब हुआ, या server तक पहुँचा और जवाब गायब हुआ। दोनों पक्षों पर capture कर align करें, और «client ने भेजा / server ने नहीं पाया» — कौन सा पक्ष चुप — सुलझता है। जब ज़िम्मेदारी सीमा (ऐप, OS, network device, या दूसरा सिरा) सुलझानी हो, शुरू से दोनों-पक्ष capture बनाना योग्य है।

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

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

7.1. Correlation की prerequisite clock sync है

दोनों पक्षों के capture align करने के लिए दोनों मशीनों की clocks सहमत होनी चाहिए। Capture start करने से पहले clock offset जाँचें और record करें।

:: 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 वह command है जो आप और साथी computer के बीच time offset दिखाता है, और capture align करते समय «server clock +0.8 seconds थी» जैसे correction का आधार बनता है।¹⁴ बड़े offset वाले environments में पहले time sync ठीक कर फिर capture करना अंत में छोटा रास्ता है।

flowchart TB
    accTitle: Correlation से पहले clock offset जाँचने की procedure
    accDescr: w32tm से अपना time-sync status confirm करें, stripchart से साथी server के विरुद्ध offset मापकर record करें, capture align करते समय उस offset को correction आधार बनाएँ, और offset बड़ा हो तो पहले sync ठीक कर फिर capture करें
    st["query से sync status जाँचें"] --> mc["stripchart से offset मापें"]
    mc --> rc["Offset record करें"]
    rc --> use["Correlation समय पर correction आधार"]
    mc -.-> big["Offset बड़ा हो तो पहले sync ठीक करें"]

चित्र 14: Capture से पहले clock offset मापकर record करें, और capture align करते समय correction आधार बनाएँ।

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

जिस event की reproduction शर्तें अज्ञात हों, मूल चाल ring buffer चला छोड़ना और event होने पर रोकना है।

• pktmon: Default circular mode है। --file-size से सीमा (MB) सेट करें; पुराने packets overwrite होते हैं।⁸
• netsh trace: maxSize=1024 filemode=circular के रूप में specify करें।⁵
• Wireshark: [Capture] → [Options] → [Output] के तहत «कई फ़ाइलें + ring buffer» configure कर सकते हैं। फ़ाइल आकार या समय से घूमता है और केवल नवीनतम N फ़ाइलें रखता है, इसलिए disk-usage सीमा के साथ लंबा चल सकता है।¹⁵

हर मामले में field के व्यक्ति के साथ नियम बाँटें कि event होने पर «पहले समय नोट करें, फिर» capture रोकें। Ring buffer जितना अधिक प्रतीक्षा उतना अतीत मिटाता है, इसलिए event से stop तक का पथ लंबा हो तो वांछित अंतराल overwrite हो जाता है।

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

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

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

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

• TCP connection स्थापित हुआ या नहीं (three-way handshake)
• TLS handshake कितनी दूर गया — ClientHello पर ServerHello लौटा या नहीं, handshake के दौरान RST या alert से कटा या नहीं
• ClientHello पर destination host name (SNI), और negotiated TLS version
• Connection खड़ा होने के बाद कौन सा पक्ष भेजना बंद किया। चुप्पी का स्थान, retransmission, RST, या साफ़ बंद (FIN)

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

flowchart TB
    accTitle: TLS capture क्या दिखा सकता है और क्या नहीं
    accDescr: Encryption केवल application-data payload छिपाता है; TCP connect establishment, TLS handshake सफलता या विफलता, SNI और TLS version, RST, और कौन सा पक्ष चुप हुआ encryption रहते हुए भी दिखता है
    tls["TLS traffic capture"] --> vis["दिखता है"]
    tls --> hid["नहीं दिखता"]
    vis --> v1["TCP connect setup"]
    vis --> v2["TLS result और SNI"]
    vis --> v3["RST / कौन चुप"]
    hid --> h1["App-data payload"]

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

जब फिर भी payload चाहिए, Wireshark SSLKEYLOGFILE environment variable से लिखी session keys से TLS decrypt कर सकता है। Support Firefox, Chrome, Chromium-based Edge, और OpenSSL-परिवार libraries जैसे कुछ implementations तक सीमित है; Windows built-in SChannel (WinHTTP या WinINET इस्तेमाल करने वाले apps) इस mechanism का support नहीं करता।¹⁰ क्योंकि «session key फ़ाइल में लिखी जाती है» का अर्थ है उस फ़ाइल वाला पूरा बातचीत decrypt कर सकता है, यह production technique नहीं; इसे development environment में reproduction और debug मानें।

flowchart TB
    accTitle: SSLKEYLOGFILE decryption कैसे काम करता है और उसकी सीमाएँ
    accDescr: SSLKEYLOGFILE से लिखी session keys Wireshark को TLS decrypt करने देती हैं, पर केवल कुछ implementations जैसे Firefox और Chrome परिवार support करते हैं और SChannel नहीं; key फ़ाइल वाला बातचीत decrypt कर सकता है, इसलिए इसे केवल development-environment technique मानें
    env["SSLKEYLOGFILE सेट करें"] --> key["Session keys लिखें"]
    key --> ws["Wireshark में पढ़ें"]
    key -.-> risk["Key धारक decrypt कर सकता है"]
    risk -.-> dev["केवल development"]
    env -.-> sup["केवल कुछ TLS stacks"]
    sup -.-> sch["SChannel: support नहीं"]

चित्र 17: Session keys लिखना decrypt कर सकता है, पर supported implementations सीमित हैं, और key की प्रकृति इसे केवल development-environment technique बनाती है।

जब traffic internal proxy से जाए, capture में दिखने वाला destination proxy server होता है, और TLS CONNECT tunnel के अंदर बहता है। ऐप किस proxy की ओर जा रहा है यह पूर्व प्रश्न उसी दिन के साथी लेख «Corporate Proxies and Windows Apps — Sorting Out Proxy Resolution in WinINET, WinHTTP, and .NET» में व्यवस्थित है।

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

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

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

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

flowchart TB
    accTitle: ऐप लॉग और packets align करने की procedure
    accDescr: ऐप लॉग से event समय पहचानें, timeout मान से start समय पीछे निकालें, Wireshark में display filter से अंतराल संकीर्ण करें, आकार क्रम से पुष्टि करें, clock offset सुधारें, और उन्हें एक ही time-axis पर रखें
    lg["1. लॉग से event समय पहचानें"] --> rev["Timeout मान से start पीछे निकालें"]
    rev --> flt["2. Display filter से अंतराल संकीर्ण करें"]
    flt --> chk["3. अध्याय 5 क्रम में आकार पुष्टि करें"]
    chk --> adj["4. Clock offset सुधारें"]
    adj --> done["लॉग का एक शब्द अवलोकन बनता है"]

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

जब जाँच परिणाम तीसरे पक्ष (vendor, carrier, customer के network staff) को सौंपें, सौंपने से पहले filter से शोर काटना शिष्टाचार और security उपाय दोनों है। Wireshark में display filter से रुचि की conversation संकीर्ण करें और [File] → [Export Specified Packets] से «केवल displayed packets» सहेजें, तो केवल ज़रूरी सीमा का छोटा pcapng मिलता है।

अंत में, व्यवहार चेतावनी। Capture फ़ाइल में communication स्वयं होता है। उसमें plaintext protocols के credentials, HTTP cookies और API keys, मेल या report की content, और personal data हो सकती है। निम्नलिखित तीन बिंदु capture procedure के साथ एक सेट के रूप में तय करें।

• न्यूनतम ज़रूरी capture: Pre-capture filter (अध्याय 3 और 4) से लक्ष्य संकीर्ण करें और time window जितनी संभव छोटी रखें। Customer environment पर «सब कुछ capture कर लो» न करें
• सौंपने से पहले संकीर्ण करें: केवल target conversation export करें; unrelated third-party traffic शामिल न करें। अगर sensitive भाग रह जाएँ तो recipient से redact करने या दूसरे साधन पर सहमत हों
• Retention और delete: तय करें capture फ़ाइलें कहाँ रखी जाएँ, कितने समय, और कब delete की जाएँ, और जाँच समाप्त होने पर delete करें

flowchart TB
    accTitle: Capture फ़ाइल सौंपने से पहले तीन निर्णय
    accDescr: Capture में communication स्वयं होता है, इसलिए capture procedure के साथ सेट के रूप में तय करें कि pre-capture filter और time window से न्यूनतम संकीर्ण करेंगे, सौंपने से पहले केवल target conversation निकालेंगे ताकि unrelated traffic शामिल न हो, और retention स्थान तथा अवधि तय कर जाँच के बाद delete करेंगे
    cap["Capture = traffic"] --> p1["न्यूनतम capture करें"]
    cap --> p2["पहले लक्ष्य निकालें"]
    cap --> p3["Retention सेट करें, delete करें"]
    p2 -.-> exp["Filter कर export करें"]

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

10. सार

• ऐप लॉग के «timeout» से एक परत नीचे wire पर सच में गए packet का तथ्य है। SYN का जवाब न मिला, RST ने connection तोड़ा, retransmission जारी रहे, या ZeroWindow दिखा — अगली जगह बदल देता है।
• जहाँ Wireshark install नहीं कर सकते वहाँ भी Windows built-in pktmon और netsh trace से capture हो जाता है। Built-in tool से capture, अपने मशीन पर Wireshark से पढ़ें — वह division मूल रूप है।
• pktmon चार कदम: filter register करें → pktmon start --capture → pktmon stop → pktmon etl2pcap। Default 128 bytes पर कटा है, इसलिए payload चाहिए तो --pkt-size 0 न भूलें। Drop स्थान और reason देखना केवल pktmon की ताकत है।
• netsh trace ETW providers का समूह scenario के रूप में capture करता है, और persistent=yes से reboot के पार बच सकता है। पढ़ने के लिए ETL को etl2pcapng से pcapng बनाएँ।
• Wireshark में tcp.analysis.flags से शुरू करें और handshake, RST, retransmission, ZeroWindow इसी क्रम में देखें। पहले Conversations और I/O Graph से तस्वीर लें फिर संकीर्ण करना तेज़ है।
• localhost traffic NIC से कभी नहीं जाता, इसलिए साधारण तरीके से capture नहीं हो सकता। Npcap loopback adapter या pktmon का stack-के-अंदर capture इस्तेमाल करें।
• दोनों पक्षों पर capture कर align करें तो «कौन सा पक्ष चुप» सुलझता है। Prerequisite clock sync (w32tm) है। अज्ञात reproduction शर्तों वाली event के लिए ring buffer से प्रतीक्षा करें।
• TLS के नीचे भी बातचीत का skeleton दिखता है। Decryption (SSLKEYLOGFILE) को केवल development-environment technique मानें, और capture फ़ाइल स्वयं को confidential मानें: न्यूनतम capture, संकीर्ण करना, और delete संचालन में बाँधें।

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

संबंधित लेख

• TCP retransmission औद्योगिक कैमरा communication क्यों रोकते हैं, और उन्हें कैसे अलग करें
• यह भ्रम कि TCP आपको भेजने की वही इकाइयों में receive करने देता है — byte stream के इर्द-गिर्द receive डिज़ाइन
• OSI model का वास्तविक अहसास — एक HTTP request को उसकी सात layers में चीरना
• Process Monitor (ProcMon) की practical guide — 10 मिनट में «setting apply नहीं» और «ACCESS DENIED» इंगित करना
• Windows Firewall और business applications — installer से inbound rules दर्ज करें
• Corporate proxy और Windows apps — WinINET, WinHTTP और .NET में proxy resolution सुलझाना

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

KomuraSoft LLC communication-मूल bug investigation सँभालती है जैसे «business app का communication समय-समय पर fail होता है और कारण नहीं मिलता» और «केवल customer environment पर होने वाली connection error अलग करनी है»। हम capture डिज़ाइन (कहाँ, क्या, और कितना capture), Wireshark analysis, ऐप लॉग से correlation, और ऐप-पक्ष सुधार को एक सतत कार्य के रूप में लेते हैं।

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

संदर्भ लिंक

संबंधित लेख

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

संबंधित विषय

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

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

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

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

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

Customer server पर जहाँ Wireshark install नहीं कर सकते, packets कैसे capture करें?

Windows के built-in tools pktmon या netsh trace इस्तेमाल करें और extra software लगाए बिना capture कर सकते हैं। pktmon में elevated (Administrator) terminal में filter register करें, pktmon start --capture से capture शुरू करें, और pktmon stop से रोकें। बनी ETL फ़ाइल pktmon etl2pcap से pcapng बन जाती है, इसलिए analysis अपने मशीन पर Wireshark में ले जाएँ। "Built-in tool से capture, Wireshark से पढ़ें" — install-restricted sites पर यही मूल division of work है।

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

अगर OS में pktmon है (Windows 10 / Windows Server 2019 और बाद), pktmon से शुरू करें। Commands सरल हैं, आप देख सकते हैं कि network stack के किस component ने packet drop किया (drop reason), और pcapng conversion self-contained है। netsh trace तब बेहतर है जब पुराने OS पर capture करें जिसमें pktmon नहीं, जब Windows components की ETW events scenario के रूप में इकट्ठा करनी हों, या जब capture reboot के पार persistent=yes से बचे। Microsoft की troubleshooting सामग्री भी यही क्रम बताती है: पहले pktmon, फिर अगर वह काफ़ी न हो तो netsh trace।

localhost (127.0.0.1) का traffic Wireshark में क्यों नहीं दिखता?

localhost का traffic physical NIC से कभी नहीं जाता; वह OS के internal loopback path पर घूम जाता है। Physical adapter को target करने वाला सामान्य capture इसलिए उसे कभी नहीं देखता। Wireshark में Npcap का "Adapter for loopback traffic capture" चुनें और loopback traffic capture हो जाता है। pktmon network stack के अंदर capture करता है, इसलिए loopback भी देख सकता है। दूसरी आम confusion: "localhost" IPv6 ::1 पर resolve होता है, इसलिए 127.0.0.1 देखने वाली स्क्रीन खाली रहती है — address साफ़ लिखकर confirm करें।

Packet capture में HTTPS (TLS) traffic की content देख सकते हैं?

Application-data payload encrypted है और दिखाई नहीं देता। बातचीत का "skeleton" — TCP connect और teardown, TLS handshake सफल हुआ या नहीं, RST से तोड़ना, कौन सा पक्ष जवाब देना बंद किया — encrypt रहने पर भी दिखता है, इसलिए ज़्यादातर timeout जाँच TLS encrypt छोड़कर चल सकती है। अगर payload चाहिए तो SSLKEYLOGFILE से decryption है, पर केवल कुछ TLS implementations जैसे Firefox और Chrome परिवार support करते हैं; Windows built-in SChannel supported नहीं। Mechanism secret key material लिखता है, इसलिए इसे केवल development-environment option मानें।

Capture फ़ाइल बाहरी support desk को भेजना सुरक्षित है?

जैसी है वैसी भेजना खतरनाक है। Capture में communication स्वयं होता है और plaintext protocols के credentials, cookies, API keys और personal data शामिल हो सकती है। पहले capture time पर filter और time window न्यूनतम रखें, और सौंपने से पहले Wireshark display filter से केवल target conversation निकालकर export करें। जो रह जाए, भेजने से पहले recipient से sensitive भागों के व्यवहार (redact करना, या दूसरे साधन से देना) पर सहमत हों। पहले तय करें कि capture फ़ाइलें कितने समय रखी जाएँगी और कब delete की जाएँगी।

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

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

Go Komura

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

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