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["গন্তব্যে পৌঁছেছে?"]

চিত্র ১: লগ শুধু ফল রাখে; timeout-এর ভাঙন শুধু এক স্তর নিচের প্যাকেটে থাকে।

মানুষ যেখানে আটকে যায় সেই বাধা «গ্রাহক সার্ভারে Wireshark বসানো যায় না»। যে সাইটে পরিবর্তন নিয়ন্ত্রণ বা নিরাপত্তা নীতি অনুসন্ধানের জন্য অতিরিক্ত সফটওয়্যার মঞ্জুর করে না, সেগুলো বিরল নয়। কিন্তু Windows আগে থেকেই দুটি প্যাকেট-ক্যাপচার টুল পাঠায়: pktmon ও netsh trace। অন্তর্নির্মিত OS টুলে ক্যাপচার করুন, তৈরি ফাইল নিজের PC-তে নিয়ে যান, Wireshark-এ পড়ুন — সেই ভাগে ইনস্টল-নিষিদ্ধ সাইটেও প্যাকেট দেখা যায়।

এই নিবন্ধ ছোট-মাঝারি প্রতিষ্ঠানের আইটি কর্মী ও Windows অ্যাপ ডেভেলপারদের জন্য। এটি pktmon, netsh trace ও Wireshark-এর মধ্যে নির্বাচন এবং প্রতিটির ব্যবহারিক পদ্ধতি সাজায়। লুপব্যাক ট্রাফিকের ফাঁদ, ক্লায়েন্ট না সার্ভারে ক্যাপচার, TLS পেলোড লুকিয়ে রাখার সঙ্গে বাঁচা, এবং ক্যাপচারকে অ্যাপ লগের সঙ্গে মেলানো — সব আগস্ট ২০২৬ পর্যন্ত প্রাথমিক উৎস থেকে।

১. আগে উপসংহার

• «অন্তর্নির্মিত টুলে ক্যাপচার, 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 প্রতি প্যাকেটের শুধু প্রথম ১২৮ বাইট রেকর্ড করে। Wireshark-এ পেলোড পড়তে চাইলে শুরুতে --pkt-size 0 (পুরো প্যাকেট রেকর্ড) ভুলবেন না।⁸
• localhost-এর ট্রাফিক সাধারণ ক্যাপচারে দেখা যায় না। সে NIC দিয়ে যায় না। Wireshark-এ Npcap লুপব্যাক অ্যাডাপ্টার, বা অন্তর্নির্মিত টুলে pktmon-এর স্ট্যাক-ভিতর ক্যাপচার ব্যবহার করুন।⁹
• TLS পেলোড লুকালেও অনেক কিছু শেখা যায়। সংযোগ স্থাপন, TLS হ্যান্ডশেক সফল কি না, RST, এবং কোন পক্ষ চুপ এনক্রিপ্ট থাকলেও দেখা যায়। SSLKEYLOGFILE দিয়ে ডিক্রিপশন শুধু উন্নয়ন-পরিবেশের কৌশল।¹⁰
• ক্যাপচারে যোগাযোগ নিজেই থাকে। ধরে নিন পরিচয়পত্র ও ব্যক্তিগত তথ্য থাকতে পারে, এবং ন্যূনতম প্রয়োজনীয় ক্যাপচার ও হস্তান্তরের আগে সংকীর্ণকরণ পদ্ধতিতে বেঁধে দিন।

২. তিন ক্যাপচার টুল ও কীভাবে বেছে নেবেন

আগে, তিন টুলের ভূমিকার এক টেবিল।

এক বাক্যে, 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-এ বিশ্লেষণ"]

চিত্র ২: মাঠে অন্তর্নির্মিত টুলে ETL ক্যাপচার করুন, pcapng করুন, আর নিজের মেশিনে Wireshark-এ পড়ুন।

Microsoft-এর প্যাকেট-হার অনুসন্ধান নির্দেশিকার আকৃতি একই: আগে pktmon দিয়ে ক্যাপচার করে কারণ আলাদা করুন, তারপর যথেষ্ট না হলে netsh trace start scenario=InternetClient-এর মতো উপাদান-স্তরের ট্রেসে যান, আর Wireshark-এ প্রোটোকল আচরণ বিশ্লেষণ করুন।⁷

প্যাকেট সত্যি কী দেখায় পড়ার পূর্বশর্ত হিসেবে, স্তরিত স্তর — Ethernet, IP, TCP, অ্যাপ্লিকেশন ডেটা — এর ছবিও সাহায্য করে। স্তরের শরীরতত্ত্ব «Getting a Real Feel for the OSI Model»-এ চিত্রিত।

৩. বাস্তবে 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["১. filter add দিয়ে লক্ষ্য সংকীর্ণ"] --> st["২. start --capture দিয়ে ক্যাপচার শুরু"]
    st --> re["৩. ঘটনা পুনরুৎপাদন"]
    re -.-> ct["কাউন্টারে পরিমাণ ও drop দেখুন"]
    re --> sp["৪. থামান"]
    sp --> cv["etl2pcap দিয়ে pcapng করুন"]
    cv --> rm["৫. filter remove দিয়ে পরিষ্কার"]

চিত্র ৩: pktmon ফিল্টার নিবন্ধন দিয়ে শুরু হয়, তারপর ক্যাপচার, থামানো ও রূপান্তর, আর শেষে ফিল্টার স্পষ্ট সরিয়ে ফেলেন।

মনে রাখার বিষয়:

• ক্যাপচার শুরুর আগে ফিল্টার নিবন্ধন করুন। Microsoft-এর নথিও শুরুর আগে ফিল্টার লাগানোর জোরালো সুপারিশ করে, কারণ সব ট্রাফিক ক্যাপচার খুব কোলাহলপূর্ণ। ফিল্টার IP ঠিকানা, পোর্ট, MAC ঠিকানা, প্রোটোকল, VLAN ID ইত্যাদি নির্দিষ্ট করতে পারে, আর ৩২টি পর্যন্ত নিবন্ধন করা যায়। একাধিক ফিল্টার OR: যেকোনোটি মিললে প্যাকেট রেকর্ড হয়।³
• pktmon ফিল্টার উৎস ও গন্তব্য আলাদা করে না। -i 192.168.10.20 মানে «প্যাকেট যেখানে এই ঠিকানা উৎস বা গন্তব্য»। দিক পরে রূপান্তরের পর Wireshark প্রদর্শন ফিল্টারে সংকীর্ণ করুন।³
• ডিফল্ট প্যাকেট আকার ১২৮ বাইট। হেডার বিশ্লেষণে যথেষ্ট, কিন্তু অ্যাপ্লিকেশন ডেটাও চাইলে --pkt-size 0 দিয়ে পুরো প্যাকেট রেকর্ড করুন।⁸
• লগ ডিফল্ট বৃত্তাকার (রিং-বাফার) মোড, ডিফল্ট আকার ৫১২MB। --file-size দিয়ে সীমা বদলানো যায়, আর --log-mode real-time স্ক্রিনে তৎক্ষণাৎ ছাপায় এবং লগ ফাইল তৈরি করে না। আগে রিয়েল-টাইম মোডে নিশ্চিত করুন যে আপনি সত্যি কাঙ্ক্ষিত ট্রাফিক দেখছেন, তারপর উৎপাদন ক্যাপচার সেট করুন, খালি তোলা এড়ান।⁸

flowchart TB
    accTitle: pktmon ফিল্টার কীভাবে কার্যকর হয়
    accDescr: একাধিক নিবন্ধিত ফিল্টার OR মিলে রেকর্ড করে, নির্দিষ্ট ঠিকানা উৎস ও গন্তব্য আলাদা করে না, আর দিক রূপান্তরের পর Wireshark প্রদর্শন ফিল্টারে সংকীর্ণ হয়
    f1["ফিল্টার ১"] --> orc["যেকোনো মিললে রেকর্ড"]
    f2["ফিল্টার ২"] --> orc
    f3["ফিল্টার ৩（৩২ পর্যন্ত）"] --> orc
    orc --> rec["ক্যাপচার লগে রেকর্ড（OR）"]
    rec -.-> nodir["উৎস ও গন্তব্য আলাদা নয়"]
    nodir -.-> ws["রূপান্তরের পর Wireshark-এ দিক সংকীর্ণ"]

চিত্র ৪: একাধিক ফিল্টার OR হিসেবে কাজ করে, আর হোস্ট উৎস না গন্তব্য রূপান্তরের পর Wireshark-এ সংকীর্ণ হয়।

৩.১. যা শুধু pktmon পারে — প্যাকেট কোথায় ফেলা হয়েছে দেখা

Wireshark-এর তুলনায় pktmon-এর বিশেষ মূল্য এই যে এটি প্যাকেট এক NIC-তে নয়, নেটওয়ার্ক স্ট্যাকের ভিতরে একাধিক বিন্দুতে ক্যাপচার করে, আর বলতে পারে কোথায় ও কেন ফেলা হয়েছে (drop)। প্যাকেট কোন উপাদানে পৌঁছেছে ও কোথায় হারিয়েছে দেখা যায় বলে «MTU মিলছে না» বা «VLAN ফিল্টার»-এর মতো drop কারণ অন্ধ খোঁজা ছাড়াই কারণে পৌঁছায়।⁴

flowchart TB
    accTitle: pktmon স্ট্যাকের ভিতরে একাধিক বিন্দুতে ক্যাপচার করে
    accDescr: pktmon প্যাকেট এক NIC-তে নয় নেটওয়ার্ক স্ট্যাকের ভিতরে একাধিক বিন্দুতে ক্যাপচার করে, তাই কারণসহ বলতে পারে প্যাকেট কোন উপাদানে পৌঁছেছে ও কোথায় ফেলা হয়েছে
    pin["প্যাকেট"] --> p1["বিন্দু ১-এ ক্যাপচার"]
    p1 --> p2["বিন্দু ২-এ ক্যাপচার"]
    p2 --> p3["বিন্দু ৩-এ ফেলা"]
    p3 -.-> rz["drop স্থান ও কারণ জানায়"]
    rz -.-> ex["যেমন MTU মিলছে না বা VLAN ফিল্টার"]

চিত্র ৫: স্ট্যাকের ভিতরে একাধিক বিন্দুতে ক্যাপচার বলে প্যাকেট কতদূর গিয়েছে ও কোথায় ফেলা হয়েছে, কারণসহ।

• 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 দিয়ে আলাদা ফাইল"]

চিত্র ৬: ক্যাপচার-বিন্দু তথ্য pcapng-এ যায় না, তাই মানক চাল রূপান্তরের আগে বিন্দু সংকীর্ণ করা।

৪. বাস্তবে 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（সিস্টেম তথ্য）"]

চিত্র ৭: পরিস্থিতি দিয়ে শুরু করলে প্রোভাইডারদের গুচ্ছ চালু হয়, আর থামালে ETL ও .cab তৈরি হয়।

৪.১. 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 দিয়ে পড়ুন"]

চিত্র ৮: ETL-এর মধ্যে প্যাকেট পড়তে pcapng হয়; ETW ঘটনা অন্য উপায়ে পড়া হয়।

৫. 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["গ্রাহক পড়ছে না"]

চিত্র ৯: হ্যান্ডশেক, 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 স্ট্রিম হিসেবে পড়ুন"]

চিত্র ১০: প্যাকেট-প্রতি পড়ার আগে পরিসংখ্যান দিয়ে ছবি নিন, আগ্রহের কথোপকথন সংকীর্ণ করুন, তারপর পড়ুন।

৬. লুপব্যাক ফাঁদ — 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"]

চিত্র ১১: localhost ট্রাফিক NIC-এর আগে ঘুরে যায়, তাই ভৌত-অ্যাডাপ্টার ক্যাপচার কখনো দেখে না।

মোকাবিলার দুই উপায় আছে।

• Wireshark-এ ক্যাপচার করার সময়: ক্যাপচার লক্ষ্য হিসেবে Npcap-এর «Adapter for loopback traffic capture» বেছে নিন। Windows Wireshark ইনস্টলার (৩.০ ও পরবর্তী) 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["গন্তব্য স্পষ্ট ঠিকানা করুন"]

চিত্র ১২: সেই বিভ্রান্তিতে নজর রাখুন যেখানে localhost ::1-এ মীমাংসিত হয় আর শুধু 127.0.0.1 দেখা «ট্রাফিক নেই» বের করে।

৭. কোথায় ক্যাপচার করবেন — এক পক্ষ, দুই পক্ষ ও ঘড়ি সিঙ্ক

ক্যাপচারের মূল্য «কোথায় ক্যাপচার করেছেন» ঠিক করে। অঙ্গুষ্ঠ নিয়ম নিম্নরূপ।

এক-পক্ষের ক্যাপচার শুধু «আমার অবস্থান থেকে দেখা তথ্য» বলে। ক্লায়েন্টে চলমান পুনঃপ্রেরণ আলাদা করে না পাঠানো প্যাকেট পথে হারিয়েছে, নাকি সার্ভারে পৌঁছে উত্তর হারিয়েছে। দুই পক্ষে ক্যাপচার করে সারিবদ্ধ করুন, «ক্লায়েন্ট পাঠিয়েছে / সার্ভার পায়নি» — কোন পক্ষ চুপ — মীমাংসা হয়। দায়িত্ব সীমা (অ্যাপ, OS, নেটওয়ার্ক যন্ত্র, বা অন্য প্রান্ত) মীমাংসা করতে হলে শুরু থেকে দুই-পক্ষ ক্যাপচার সাজানো মূল্যবান।

flowchart TB
    accTitle: এক-পক্ষ ও দুই-পক্ষ ক্যাপচার কী বলে
    accDescr: এক-পক্ষের ক্যাপচার আলাদা করে না বাইরে যাওয়া প্যাকেট হারিয়েছে নাকি ফিরতি উত্তর হারিয়েছে; দুই পক্ষে ক্যাপচার করে সারিবদ্ধ করলে কোন পক্ষ চুপ মীমাংসা হয়
    one["এক পক্ষে ক্যাপচার"] --> fact["আপনার পক্ষের তথ্য"]
    fact --> und["বাইরে না ফিরতি?"]
    both["দুই পক্ষে ক্যাপচার"] --> mt["সারিবদ্ধ করুন"]
    mt --> fix["কোন পক্ষ চুপ"]
    mt -.-> pre["ঘড়ি সিঙ্ক লাগে"]

চিত্র ১৩: এক পক্ষ শুধু আপনি দেখা তথ্য দেখায়; দুই পক্ষ সারিবদ্ধ করাই দায়িত্ব সীমা প্রথম মীমাংসা করে।

৭.১. সম্পর্কের পূর্বশর্ত ঘড়ি সিঙ্ক

দুই পক্ষের ক্যাপচার সারিবদ্ধ করতে দুই মেশিনের ঘড়ি একমত হতে হবে। ক্যাপচার শুরুর আগে ঘড়ি অফসেট পরীক্ষা ও রেকর্ড করুন।

:: 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 সেই কমান্ড যা আপনি ও সহযোগী কম্পিউটারের মধ্যে সময় অফসেট দেখায়, আর ক্যাপচার সারিবদ্ধ করার সময় «সার্ভার ঘড়ি +০.৮ সেকেন্ড ছিল»-এর মতো সংশোধনের ভিত্তি হয়।¹⁴ বড় অফসেটের পরিবেশে আগে সময় সিঙ্ক ঠিক করে তারপর ক্যাপচার করা শেষে ছোট পথ।

flowchart TB
    accTitle: সম্পর্কের আগে ঘড়ি অফসেট পরীক্ষার পদ্ধতি
    accDescr: w32tm দিয়ে নিজের সময়-সিঙ্ক অবস্থা নিশ্চিত করুন, stripchart দিয়ে সহযোগী সার্ভারের বিপরীতে অফসেট মেপে রেকর্ড করুন, ক্যাপচার সারিবদ্ধ করার সময় সেই অফসেট সংশোধনের ভিত্তি করুন, আর অফসেট বড় হলে আগে সিঙ্ক ঠিক করে তারপর ক্যাপচার করুন
    st["query দিয়ে সিঙ্ক অবস্থা দেখুন"] --> mc["stripchart দিয়ে অফসেট মাপুন"]
    mc --> rc["অফসেট রেকর্ড করুন"]
    rc --> use["সম্পর্কের সময় সংশোধনের ভিত্তি"]
    mc -.-> big["অফসেট বড় হলে আগে সিঙ্ক ঠিক করুন"]

চিত্র ১৪: ক্যাপচারের আগে ঘড়ি অফসেট মেপে রেকর্ড করুন, আর ক্যাপচার সারিবদ্ধ করার সময় সংশোধনের ভিত্তি করুন।

৭.২. «কখন হবে জানি না»-এর জন্য — রিং বাফার

যে ঘটনার পুনরুৎপাদন শর্ত অজানা, মূল চাল রিং বাফার চালিয়ে রাখা আর ঘটনা ঘটলে থামানো।

• 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["দেরিতে থামানো কাঙ্ক্ষিত ব্যবধান মুছে"]

চিত্র ১৫: রিং বাফার যত বেশি অপেক্ষা তত অতীত মুছে, তাই সময় নোট করে তাড়াতাড়ি থামান।

৮. সমস্যা যে 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["অ্যাপ-ডেটা পেলোড"]

চিত্র ১৬: এনক্রিপশন শুধু পেলোড হারায়; কথোপকথনের কঙ্কাল 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: সমর্থন নেই"]

চিত্র ১৭: সেশন কী লেখা ডিক্রিপ্ট করতে পারে, কিন্তু সমর্থিত ইমপ্লিমেন্টেশন সীমিত, আর কী-এর স্বভাব এটিকে শুধু উন্নয়ন-পরিবেশের কৌশল করে।

ট্রাফিক অভ্যন্তরীণ প্রক্সি দিয়ে গেলে ক্যাপচারে দেখা গন্তব্য প্রক্সি সার্ভার, আর TLS CONNECT টানেলের ভিতরে বয়ে যায়। অ্যাপ কোন প্রক্সির দিকে যাচ্ছে সেই আগের প্রশ্ন একই দিনের সঙ্গী নিবন্ধ «Corporate Proxies and Windows Apps — Sorting Out Proxy Resolution in WinINET, WinHTTP, and .NET»-এ সাজানো।

৯. অ্যাপ লগের সঙ্গে সম্পর্ক — সময় এক অক্ষে রাখা

ক্যাপচার একা খুব কম উপসংহার দেয়। বাস্তবে নির্ণায়ক চাল অ্যাপ লগের এক লাইন ও প্যাকেটের এক চক্কর একই সময়-অক্ষে রাখা।

পদ্ধতি এরকম দেখায়।

1. অ্যাপ লগ থেকে ঘটনার সময় চিনুন (উদাহরণ, 10:23:41-এ timeout ব্যতিক্রম)। timeout মান ৩০ সেকেন্ড হলে শুরু প্রায় 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. সেই ব্যবধানে অধ্যায় ৫-এর ক্রম (হ্যান্ডশেক → RST → পুনঃপ্রেরণ → ZeroWindow) নিশ্চিত করুন। «লগের timeout সময়ের ৩০ সেকেন্ড আগে SYN পাঠানো হয়েছে, তারপর শুধু SYN পুনঃপ্রেরণ» পর্যন্ত সারিবদ্ধ করা গেলে লগের «timeout» পর্যবেক্ষণ «এই ক্যাপচার বিন্দুতে কোনো উত্তরই ফেরেনি» দিয়ে বদলায় (SYN সহযোগীর কাছে পৌঁছায়নি, নাকি ফিরতি SYN/ACK পথে হারিয়েছে, শুধু এই ক্যাপচার বিন্দু থেকে মীমাংসা হয় না। মীমাংসা করতে হলে সার্ভারে ক্যাপচার করে সারিবদ্ধ করুন)।
4. ক্যাপচার সময় ও লগ সময়ের মধ্যে অফসেট সবসময় সংশোধন করুন (অনুচ্ছেদ ৭.১-এ মাপা ঘড়ি অফসেট, আর লগের টাইমজোন চিহ্ন)। কয়েক সেকেন্ডের সম্পর্ক ত্রুটি ভুল কথোপকথনকে অপরাধী গেঁথে দেবে।

flowchart TB
    accTitle: অ্যাপ লগ ও প্যাকেট সারিবদ্ধ করার পদ্ধতি
    accDescr: অ্যাপ লগ থেকে ঘটনার সময় চিনুন, timeout মান থেকে শুরুর সময় পেছনে বের করুন, Wireshark-এ প্রদর্শন ফিল্টার দিয়ে ব্যবধান সংকীর্ণ করুন, আকৃতি ক্রমে নিশ্চিত করুন, ঘড়ি অফসেট সংশোধন করুন, আর তাদের একই সময়-অক্ষে রাখুন
    lg["১. লগ থেকে ঘটনার সময় চিনুন"] --> rev["timeout মান থেকে শুরু পেছনে বের করুন"]
    rev --> flt["২. প্রদর্শন ফিল্টারে ব্যবধান সংকীর্ণ"]
    flt --> chk["৩. অধ্যায় ৫-এর ক্রমে আকৃতি নিশ্চিত"]
    chk --> adj["৪. ঘড়ি অফসেট সংশোধন"]
    adj --> done["লগের এক শব্দ পর্যবেক্ষণ হয়"]

চিত্র ১৮: লগ সময় থেকে ব্যবধান সংকীর্ণ করুন, আকৃতি নিশ্চিত করুন, ঘড়ি অফসেট সংশোধন করুন, আর তাদের এক অক্ষে রাখুন।

অনুসন্ধানের ফল তৃতীয় পক্ষকে (বিক্রেতা, বাহক, গ্রাহকের নেটওয়ার্ক কর্মী) হস্তান্তর করলে হস্তান্তরের আগে ফিল্টার দিয়ে শোর কাটা শিষ্টাচার ও নিরাপত্তা ব্যবস্থা দুইই। Wireshark-এ প্রদর্শন ফিল্টার দিয়ে আগ্রহের কথোপকথন সংকীর্ণ করে [File] → [Export Specified Packets] দিয়ে «শুধু প্রদর্শিত প্যাকেট» সংরক্ষণ করুন, শুধু প্রয়োজনীয় সীমার ছোট pcapng পাবেন।

শেষে, আচরণ সতর্কতা। ক্যাপচার ফাইলে যোগাযোগ নিজেই থাকে। তাতে সাদা-পাঠ্য প্রোটোকলের পরিচয়পত্র, HTTP কুকি ও API কী, মেইল বা প্রতিবেদনের বিষয়বস্তু, ও ব্যক্তিগত তথ্য থাকতে পারে। নিচের তিন বিষয় ক্যাপচার পদ্ধতির সঙ্গে এক সেট হিসেবে ঠিক করুন।

• ন্যূনতম প্রয়োজনীয় ক্যাপচার: প্রাক-ক্যাপচার ফিল্টার (অধ্যায় ৩ ও ৪) দিয়ে লক্ষ্য সংকীর্ণ করুন এবং সময় জানালা যত সম্ভব ছোট রাখুন। গ্রাহক পরিবেশে «সব ক্যাপচার করে ফেলুন» করবেন না
• হস্তান্তরের আগে সংকীর্ণ করুন: শুধু লক্ষ্য কথোপকথন রপ্তানি করুন; অসম্পর্কিত তৃতীয়-পক্ষ ট্রাফিক অন্তর্ভুক্ত করবেন না। সংবেদনশীল অংশ থাকলে প্রাপকের সঙ্গে ঢাকা বা অন্য উপায়ে একমত হোন
• ধারণ ও মুছে ফেলা: ঠিক করুন ক্যাপচার ফাইল কোথায় রাখা হবে, কতদিন, আর কখন মুছবেন, এবং অনুসন্ধান শেষে মুছুন

flowchart TB
    accTitle: ক্যাপচার ফাইল হস্তান্তরের আগে তিন সিদ্ধান্ত
    accDescr: ক্যাপচারে যোগাযোগ নিজেই থাকে, তাই ক্যাপচার পদ্ধতির সঙ্গে সেট হিসেবে ঠিক করুন যে প্রাক-ক্যাপচার ফিল্টার ও সময় জানালা দিয়ে ন্যূনতম সংকীর্ণ করবেন, হস্তান্তরের আগে শুধু লক্ষ্য কথোপকথন বের করবেন যাতে অসম্পর্কিত ট্রাফিক না আসে, আর ধারণ স্থান ও সময় ঠিক করে অনুসন্ধানের পর মুছবেন
    cap["ক্যাপচার = ট্রাফিক"] --> p1["ন্যূনতম ক্যাপচার করুন"]
    cap --> p2["আগে লক্ষ্য বের করুন"]
    cap --> p3["ধারণ সেট করুন, মুছুন"]
    p2 -.-> exp["ফিল্টার করে রপ্তানি"]

চিত্র ১৯: ন্যূনতম ক্যাপচার, হস্তান্তরের আগে সংকীর্ণকরণ, আর ধারণ ও মুছে ফেলা ক্যাপচার পদ্ধতির সঙ্গে সেট হিসেবে ঠিক করুন।

১০. সারসংক্ষেপ

• অ্যাপ লগের «timeout»-এর এক স্তর নিচে তারের উপর সত্যি গিয়েছিল এমন প্যাকেটের তথ্য। SYN-এর উত্তর আসেনি, RST সংযোগ ছিঁড়েছে, পুনঃপ্রেরণ চলেছে, বা ZeroWindow দেখা দিয়েছে — পরের জায়গা বদলায়।
• যে সাইটে Wireshark বসানো যায় না সেখানেও Windows অন্তর্নির্মিত pktmon ও netsh trace দিয়ে ক্যাপচার হয়। অন্তর্নির্মিত টুলে ক্যাপচার, নিজের মেশিনে Wireshark-এ পড়া — সেই ভাগ মূল রূপ।
• pktmon চার ধাপ: ফিল্টার নিবন্ধন → pktmon start --capture → pktmon stop → pktmon etl2pcap। ডিফল্টে ১২৮ বাইটে কাটা, তাই পেলোড চাইলে --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)-এর ব্যবহারিক নির্দেশিকা — ১০ মিনিটে «সেটিং প্রয়োগ হয়নি» ও «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 ভালো যখন pktmonহীন পুরনো OS-এ ক্যাপচার করেন, যখন 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 সফটওয়্যার ডেভেলপমেন্ট, প্রযুক্তিগত পরামর্শ ও বাগ তদন্তে বিশেষজ্ঞ, বিশেষ করে বিদ্যমান সিস্টেমযুক্ত প্রকল্প ও পুনরুৎপাদন করা কঠিন বাগে।