সমস্যা খোঁজা — tcpdump, Wireshark আর পদ্ধতিগত তদন্ত

১ · অনুমানে নয়, পদ্ধতিতে — লক্ষণ, পুনরুৎপাদন আর অনুমান

“নেট নেই” — এই কথার পেছনে হতে পারে খোলা তার, DHCP, ভুল DNS, firewall-এর নতুন নিয়ম, মেয়াদোত্তীর্ণ certificate, বা সার্ভারের ত্রুটি। ভালো ইঞ্জিনিয়ার বেশি কমান্ড জানেন বলে দ্রুত নন; তিনি পদ্ধতি মানেন — প্রতিটি পরীক্ষা সম্ভাব্য কারণের তালিকা ছোট করে।

ধাপ ১ — লক্ষণটি ঠিকঠাক লেখা

“কাজ করছে না” কোনো লক্ষণ নয়। ডাক্তার যেমন রোগীর ইতিহাস নেন, তেমনি প্রথমে পাঁচটি প্রশ্নের উত্তর লিখুন:

• কে? একজন ব্যবহারকারী, এক তলার সবাই, নাকি পুরো অফিস? শুধু Wi-Fi-তে, নাকি তারেও?
• কী? ঠিক কোন বার্তা — “This site can't be reached”, “Connection timed out”, “502 Bad Gateway”, নাকি শুধু খুব ধীর? Screenshot আর ঘড়ির সময়সহ।
• কোথায়? সব ওয়েবসাইট, নাকি একটি? একটি অ্যাপ, নাকি সব অ্যাপ? মোবাইল ডেটায় চলে কি?
• কবে থেকে? আজ সকাল ১০টা থেকে, নাকি সব সময় বিকেলে? সব সময়, নাকি মাঝে মাঝে (intermittent)?
• কী বদলেছে? নতুন router, OS update, firewall-এর নিয়ম, ISP বদল, certificate নবায়ন, DNS record — অভিজ্ঞতায় দেখা যায়, বেশিরভাগ হঠাৎ সমস্যার পেছনে সাম্প্রতিক কোনো পরিবর্তন থাকে।

ধাপ ২ — পুনরুৎপাদন, অনুমান, একবারে একটি পরিবর্তন

পুনরুৎপাদন (reproduce): নিজে সমস্যাটি ঘটাতে পারেন? মাঝে মাঝে ঘটলে মাপুন — “১০০টি অনুরোধে ৭টি ব্যর্থ” — আর আগে থেকে capture বা log চালু রাখুন। যে সমস্যা ঘটানো যায় না, তার সমাধানও যাচাই করা যায় না।

অনুমান আর পরীক্ষা: তথ্য দেখে একটি নির্দিষ্ট অনুমান বানান — “DNS resolver উত্তর দিচ্ছে না” — আর এমন একটি পরীক্ষা ভাবুন, যার ফল অনুমানটিকে ভুল প্রমাণ করতে পারে (যেমন অন্য resolver দিয়ে একই নাম খোঁজা)। তারপর একবারে একটিই জিনিস বদলান। একসাথে DNS বদলালেন, router restart করলেন আর VPN বন্ধ করলেন — সমস্যা গেল, কিন্তু কোনটিতে গেল কেউ জানে না; পরের বার আবার শূন্য থেকে শুরু।

লিখে রাখা: প্রতিটি কমান্ড, তার আউটপুট আর সময় একটি নোটে টুকে রাখুন। মাঝপথে অন্য কেউ দায়িত্ব নিলে, বা পরে মূল কারণ (root cause) খুঁজতে হলে এই নোটই ভরসা।

সহজ জিনিস আগে: তার লাগানো? Wi-Fi ঠিক নেটওয়ার্কে? IP ঠিকানা আছে? Gateway সাড়া দেয়? DNS কাজ করে? এক মিনিটের এই পাঁচ পরীক্ষায় বহু “জটিল” সমস্যা ধরা পড়ে।

২ · স্তর ধরে খোঁজা — bottom-up, top-down আর half-split

পর্ব ৩-এর স্তরের মডেল এখানে সবচেয়ে কাজের হাতিয়ার। প্রতিটি স্তর নিচের স্তরের ওপর নির্ভর করে: link না থাকলে IP অর্থহীন, IP না থাকলে DNS অর্থহীন, TCP সংযোগ না হলে TLS অর্থহীন। তাই একটি স্তর ঠিক প্রমাণ হলে তার নিচের সব স্তরও মোটামুটি ঠিক প্রমাণ হয় — কোনো স্তর থেকে উত্তর আসা মানে নিচের পথটুকু চালু।

Half-split আসলে binary search (DSA কোর্সের পরিচিত কৌশল)। nটি সম্ভাব্য জায়গার মধ্যে একটি ত্রুটিপূর্ণ হলে, প্রতিটি পরীক্ষা সম্ভাবনা অর্ধেক করে, তাই সবচেয়ে খারাপ ক্ষেত্রে পরীক্ষা লাগে:

যুক্তিটি সহজ: kটি হ্যাঁ/না পরীক্ষার ফল সর্বোচ্চ 2^k রকম হতে পারে, আর nটি জায়গা আলাদা করতে হলে 2^k ≥ n লাগবে — তাই k ≥ log₂ n; আর প্রতিবার ঠিক অর্ধেক করলে এই সংখ্যাতেই কাজ হয়। পরের অংশের আটটি ধাপে ভাগ করে গেলে ⌈log₂ ৮⌉ = ৩টি পরীক্ষা — যদি প্রতিটি ফল নির্ভরযোগ্য হয়। এই “যদি”-টিই আসল কথা: ICMP আটকানো থাকলে ping ব্যর্থ হয়েও পথ চালু থাকতে পারে (পর্ব ২০), তাই half-split-এ প্রতিটি “না”-কে একটি দ্বিতীয় পদ্ধতিতে (যেমন TCP সংযোগ) মিলিয়ে নিন।

৩ · “ওয়েবসাইট খুলছে না” — আট ধাপের সিদ্ধান্ত-পথ

সবচেয়ে প্রচলিত অভিযোগটি দিয়েই পদ্ধতিটি অনুশীলন করি। একজন ব্যবহারকারীর Linux ল্যাপটপ (Wi-Fi, ঠিকানা 192.168.0.105) থেকে https://shop.example.com খুলছে না। প্রতিটি ধাপে একটি প্রশ্ন, একটি কমান্ড, আর ফল দেখে সিদ্ধান্ত। প্রতিটি ধাপের বিস্তারিত আগের একটি পর্বে আছে — সংখ্যাগুলো টেবিলে।

এবার ধাপে ধাপে চলুন। নিচের আউটপুটগুলো একটি সাধারণ ল্যাপটপের উদাহরণ (চালানো নয়; ঠিকানাগুলো documentation-এর জন্য সংরক্ষিত)।

এই পর্যবেক্ষণগুলো একটি ছোট “সিদ্ধান্ত-যন্ত্রে” বসানো যায়: ক্রমানুসারে পরীক্ষা, প্রথম আসল ব্যর্থতায় থামা — তবে ওপরের স্তরের কোনো পরীক্ষা সফল হলে ping-এর ব্যর্থতা আসল নয়। নিচের কোড ছয়টি ঘটনায় সম্ভাব্য ত্রুটিপূর্ণ স্তর আর পরের কমান্ড ছাপে। “চালান” চাপুন, তারপর cases-এ নিজের পর্যবেক্ষণ যোগ করে দেখুন:

// "Website doesn't open": walk the checks bottom-up and stop at the first real failure.
const checks = [   // [observation, fault layer if it fails, next command, lesson no.]
  ["link",     "physical/link (cable, Wi-Fi)",        "ip -br link ; iw dev wlan0 link",                "14"],
  ["ip",       "IP config (DHCP)",                    "ip -4 addr ; journalctl -u NetworkManager",      "18"],
  ["gw_ping",  "local LAN / gateway",                 "ip route ; ip neigh show",                       "18, 22"],
  ["wan_ping", "ISP / routing beyond the gateway",    "mtr -rwn -c 50 <public-IP>",                      "20, 22"],
  ["dns_ok",   "DNS",                                 "dig example.com ; resolvectl status",            "35"],
  ["tcp_443",  "transport: port 443 blocked/closed",  "curl -v --connect-timeout 5 https://example.com", "29, 49"],
  ["tls_ok",   "TLS (certificate, clock, version)",   "openssl s_client -connect example.com:443 -servername example.com", "48"],
];
function diagnose(o) {
  for (const [i, [key, layer, cmd, n]] of checks.entries()) {
    if (o[key] !== false) continue;
    const laterOk = checks.slice(i + 1).some(([k]) => o[k] === true);
    if (key.endsWith("ping") && laterOk) {                 // ping failed, but higher layers work
      console.log(`     note: ${key} failed but later checks pass -> ICMP is filtered, not the fault`);
      continue;
    }
    return `${layer}\n     next: ${cmd}   (lesson ${n})`;
  }
  if (o.http_status >= 500) return `server or proxy side (HTTP ${o.http_status})\n     next: curl -sv -o /dev/null https://example.com ; read proxy/server logs   (lesson 36, 38)`;
  if (o.http_status >= 400) return `request side (HTTP ${o.http_status}: URL, login, permission)\n     next: curl -v, check URL and cookies   (lesson 36)`;
  return "network path is fine -> look at the browser (cache, extension, proxy setting)";
}
const T = true, F = false;
const cases = {   // observations in check order: link, ip, gw_ping, wan_ping, dns_ok, tcp_443, tls_ok
  "A: Wi-Fi connected, no IP":   { link: T, ip: F },
  "B: everything but names":     { link: T, ip: T, gw_ping: T, wan_ping: T, dns_ok: F },
  "C: ping blocked, site 502":   { link: T, ip: T, gw_ping: T, wan_ping: F, dns_ok: T, tcp_443: T, tls_ok: T, http_status: 502 },
  "D: TCP ok, TLS fails":        { link: T, ip: T, gw_ping: T, wan_ping: T, dns_ok: T, tcp_443: T, tls_ok: F },
  "E: gateway and internet silent": { link: T, ip: T, gw_ping: F, wan_ping: F, dns_ok: F },
  "F: all good, HTTP 200":       { link: T, ip: T, gw_ping: T, wan_ping: T, dns_ok: T, tcp_443: T, tls_ok: T, http_status: 200 },
};
for (const [name, obs] of Object.entries(cases)) { console.log(name); console.log("  -> " + diagnose(obs)); }

A: Wi-Fi connected, no IP
  -> IP config (DHCP)
     next: ip -4 addr ; journalctl -u NetworkManager   (lesson 18)
B: everything but names
  -> DNS
     next: dig example.com ; resolvectl status   (lesson 35)
C: ping blocked, site 502
     note: wan_ping failed but later checks pass -> ICMP is filtered, not the fault
  -> server or proxy side (HTTP 502)
     next: curl -sv -o /dev/null https://example.com ; read proxy/server logs   (lesson 36, 38)
D: TCP ok, TLS fails
  -> TLS (certificate, clock, version)
     next: openssl s_client -connect example.com:443 -servername example.com   (lesson 48)
E: gateway and internet silent
  -> local LAN / gateway
     next: ip route ; ip neigh show   (lesson 18, 22)
F: all good, HTTP 200
  -> network path is fine -> look at the browser (cache, extension, proxy setting)

৪ · Packet capture কীভাবে কাজ করে — tcpdump-এর option আর filter

কমান্ডগুলো বলে “কী হলো”; packet capture দেখায় “ঠিক কীভাবে হলো”। পর্ব ৬-এ tcpdump আর Wireshark-এর প্রথম পরিচয় পেয়েছেন। এবার ভেতরটা দেখি।

Capture-এর যন্ত্রপাতি

• libpcap: tcpdump, Wireshark আর আরও বহু টুল packet ধরতে একই লাইব্রেরি ব্যবহার করে। Linux-এ এটি kernel-এর একটি packet socket খোলে, যা interface দিয়ে আসা-যাওয়া প্রতিটি packet-এর একটি কপি পায় — আসল packet নিজের পথে চলতেই থাকে। Windows-এ একই কাজ করে Npcap driver, macOS-এ /dev/bpf* যন্ত্র।
• BPF filter: সব packet kernel থেকে প্রোগ্রামে কপি করা ব্যয়বহুল। তাই আপনার লেখা filter (যেমন tcp port 443) ছোট একটি bytecode প্রোগ্রামে রূপান্তরিত হয়ে kernel-এর ভেতরে বসে, আর না-মেলা packet সেখানেই বাদ পড়ে। tcpdump -d 'tcp port 443' সেই bytecode ছাপে।
• Promiscuous mode: সাধারণত network card শুধু নিজের MAC ঠিকানার, broadcast আর বেছে নেওয়া multicast frame ওপরে পাঠায়। Promiscuous mode-এ সে সব frame পাঠায়। কিন্তু আজকের switch-চালিত নেটওয়ার্কে (পর্ব ১২) switch অন্যের frame আপনার port-এ পাঠায়ই না — তাই promiscuous mode চালু করেও সাধারণত শুধু নিজের traffic আর broadcast দেখবেন।
• অন্যের traffic দেখার বৈধ উপায়: নেটওয়ার্কের দায়িত্বে থাকলে managed switch-এ একটি port-এর traffic আরেকটি port-এ কপি করা — port mirroring (Cisco-র ভাষায় SPAN), অথবা তারের মাঝে বসানো হার্ডওয়্যার TAP. দুটিই অনুমতি নিয়ে বসানো হয়।

কোথায় capture করবেন — host-এ, নাকি নেটওয়ার্কে

একই সংযোগের capture দুই প্রান্তে আলাদা গল্প বলে; দুটি মেলালে বোঝা যায় packet পথে হারাচ্ছে কি না। আরেকটি গুরুত্বপূর্ণ সূক্ষ্মতা: Linux-এ tcpdump আগত packet দেখে firewall-এর আগেই। তাই “tcpdump-এ SYN দেখা যাচ্ছে, কিন্তু অ্যাপ কিছু পাচ্ছে না, SYN-ACK-ও যাচ্ছে না” — এটি প্রায় নিশ্চিতভাবে host-এর নিজের firewall (netfilter, পর্ব ৪৯)। উল্টো দিকে, বাইরে যাওয়ার packet firewall-এ আটকালে tcpdump-এ পৌঁছায়ই না।

Capture-এ root লাগে, বা Linux-এ CAP_NET_RAW আর CAP_NET_ADMIN capability (অনেক distribution Wireshark-এর dumpcap-কে একটি বিশেষ group-এর জন্য এই অনুমতি দেয়)। কারণ পরিষ্কার: যে packet দেখতে পারে, সে অন্যের পাসওয়ার্ডও দেখতে পারে।

tcpdump-এর প্রধান option

Capture filter — BPF-এর ভাষা

নিচের উদাহরণগুলো একটি সাধারণ Linux যন্ত্রের, নিজের যন্ত্রে root হিসেবে (এই পাতার রানারে tcpdump নেই, আর capture-এর অনুমতিও নেই)। Filter সব সময় একক উদ্ধৃতিচিহ্নে রাখুন, যাতে shell কোনো চিহ্ন (&, !, [ ]) নিজে ব্যাখ্যা না করে:

sudo tcpdump -i eth0 -nn 'host 192.0.2.10'                 # ওই ঠিকানা থেকে বা ওই ঠিকানায়
sudo tcpdump -i eth0 -nn 'net 198.51.100.0/24 and port 53'  # একটি subnet-এর DNS
sudo tcpdump -i eth0 -nn 'tcp port 443 and not port 22'     # নিজের SSH সেশন বাদ
sudo tcpdump -i any  -nn 'tcp[tcpflags] & tcp-syn != 0'     # শুধু SYN আর SYN-ACK
sudo tcpdump -i any  -nn 'tcp[tcpflags] & (tcp-rst|tcp-fin) != 0'  # সংযোগ শেষের packet
sudo tcpdump -i eth0 -nn 'icmp'                             # ping, unreachable, frag-needed
sudo tcpdump -i eth0 -nn -s 128 -c 2000 -w /tmp/web.pcap 'host 203.0.113.80 and tcp port 443'

tcp[tcpflags] মানে TCP header-এর flag-বাইট (পর্ব ২৯-এর header-এর ১৩ নম্বর বাইট); & tcp-syn != 0 মানে “SYN বিটটি ১”। খেয়াল করুন, SYN-ACK-এও SYN বিট ১, তাই দুটোই ধরা পড়ে — নতুন সংযোগের চেষ্টা গুনতে এটি খুব কাজের। আর SSH দিয়ে দূরের সার্ভারে capture করলে not port 22 না দিলে tcpdump নিজের আউটপুটের SSH packet ধরে, সেটি আবার ছাপে, আবার ধরে — অন্তহীন চক্র।

একটি সূক্ষ্ম নিয়ম, যা প্রায় সবাই ভুল করেন: pcap-filter-এর ভাষায় not সবচেয়ে আগে প্রয়োগ হয়, কিন্তু and আর or-এর অগ্রাধিকার সমান, আর এরা বাম থেকে ডানে চলে — C বা Python-এর মতো and আগে নয়। নিচের ছোট evaluator ঠিক এই নিয়মে ছয়টি packet-এ পাঁচটি filter চালায়:

// A tiny pcap-filter evaluator. Like real BPF syntax: "not" binds tightest,
// "and"/"or" have EQUAL precedence and are applied left to right.
const pkts = [
  { n: 1, proto: "tcp",  src: "192.0.2.10",   dst: "198.51.100.20", sport: 50412, dport: 443, flags: "S" },
  { n: 2, proto: "tcp",  src: "198.51.100.20", dst: "192.0.2.10",  sport: 443, dport: 50412, flags: "SA" },
  { n: 3, proto: "udp",  src: "192.0.2.10",   dst: "192.0.2.53",   sport: 40001, dport: 53 },
  { n: 4, proto: "icmp", src: "192.0.2.1",    dst: "192.0.2.10" },
  { n: 5, proto: "tcp",  src: "192.0.2.77",   dst: "192.0.2.10",   sport: 51000, dport: 22, flags: "PA" },
  { n: 6, proto: "tcp",  src: "198.51.100.20", dst: "192.0.2.10",  sport: 443, dport: 50412, flags: "R" },
];
const inNet = (ip, cidr) => { const [base, len] = cidr.split("/"), size = 2 ** (32 - len),
  v = a => a.split(".").reduce((x, o) => x * 256 + +o, 0); return Math.floor(v(ip) / size) === Math.floor(v(base) / size); };
function prim(t, p) {                     // t = tokens of one primitive, e.g. ["src","port","53"]
  if (["tcp", "udp", "icmp"].includes(t[0]) && t.length > 1) return p.proto === t.shift() && prim(t, p);
  const dir = t[0] === "src" || t[0] === "dst" ? t.shift() : null, [kind, arg] = t;
  const pick = (a, b) => dir === "src" ? [a] : dir === "dst" ? [b] : [a, b];
  if (kind === "host") return pick(p.src, p.dst).includes(arg);
  if (kind === "net")  return pick(p.src, p.dst).some(ip => inNet(ip, arg));
  if (kind === "port") return pick(p.sport, p.dport).includes(+arg);
  if (kind === "SYN")  return p.proto === "tcp" && p.flags.includes("S");
  return p.proto === kind;                // tcp, udp, icmp
}
function match(expr, p) {
  const toks = expr.replace("tcp[tcpflags] & tcp-syn != 0", "SYN").split(/\s+/);
  let result = null, op = null, neg = false, cur = [];
  const flush = () => { if (!cur.length) return; let v = prim(cur, p) !== neg; cur = []; neg = false;
    result = result === null ? v : op === "and" ? result && v : result || v; };
  for (const w of toks) {
    if (w === "and" || w === "or") { flush(); op = w; } else if (w === "not") neg = true; else cur.push(w);
  }
  flush(); return result;
}
for (const f of ["host 198.51.100.20", "udp port 53 or icmp", "tcp[tcpflags] & tcp-syn != 0",
                 "net 192.0.2.0/24 and not port 22", "src host 192.0.2.10 or icmp and port 443"])
  console.log(f.padEnd(34), "->", pkts.filter(p => match(f, p)).map(p => "#" + p.n).join(" ") || "(none)");

host 198.51.100.20                 -> #1 #2 #6
udp port 53 or icmp                -> #3 #4
tcp[tcpflags] & tcp-syn != 0       -> #1 #2
net 192.0.2.0/24 and not port 22   -> #1 #2 #3 #4 #6
src host 192.0.2.10 or icmp and port 443 -> #1

৫ · tcpdump-এর আউটপুট লাইন ধরে পড়া

প্রতিটি TCP লাইনের গঠন একই: সময় · IP · উৎস.port > গন্তব্য.port · Flags · seq (এই packet-এর ডেটা কোন বাইট থেকে কোন বাইট) · ack (পরের কোন বাইট আশা করছি) · win (আর কত জায়গা আছে) · options · length (ডেটার বাইট)। Flag-এর চিহ্নগুলো: S = SYN, F = FIN, P = PUSH, R = RST, আর . = ACK. তাই [S.] মানে SYN + ACK, [P.] মানে ডেটাসহ ACK.

নিচে একটি client (192.0.2.10) একটি ওয়েব সার্ভার (198.51.100.20, port 80) থেকে একটি ছোট পাতা আনছে — সংযোগ, অনুরোধ, উত্তর আর বন্ধ। Capture client-এর (sudo tcpdump -i eth0 -nn 'host 198.51.100.20 and port 80', উদাহরণ)। সাধারণ HTTP ব্যবহার করা হয়েছে যাতে অনুরোধের লেখা দেখা যায়; HTTPS-এ একই TCP-র ছবি, শুধু ডেটা এনক্রিপ্ট করা।

৬ · Wireshark — display filter, stream আর পরিসংখ্যান

tcpdump সার্ভারে ধরার জন্য, Wireshark বিশ্লেষণের জন্য — প্রতিটি packet স্তর ধরে খুলে দেখায়, আর TCP-র আচরণ নিজেই চিহ্নিত করে। সাধারণ ধারা: সার্ভারে tcpdump -w, ফাইল নিজের যন্ত্রে এনে Wireshark-এ খোলা।

দুই রকম filter — গুলিয়ে ফেলবেন না

সমস্যা খোঁজায় সবচেয়ে কাজের কয়েকটি display filter (উদাহরণ; প্রতিটি Wireshark-এর filter বারে লিখে Enter):

tcp.analysis.retransmission          # Wireshark যেগুলোকে retransmission চিনেছে
tcp.analysis.duplicate_ack           # dup ACK — প্রাপক একটি ফাঁক দেখছে
tcp.analysis.zero_window             # প্রাপকের buffer ভরা
tcp.flags.reset == 1                 # RST — সংযোগ হঠাৎ কাটা
dns.flags.rcode != 0                 # ত্রুটিসহ DNS উত্তর (3 = NXDOMAIN, 2 = SERVFAIL)
http.response.code >= 400            # HTTP-র ত্রুটির উত্তর
tls.handshake.type == 1              # TLS ClientHello
tls.alert_message                    # TLS alert (যেমন handshake_failure)
icmp.type == 3 && icmp.code == 4     # Fragmentation Needed — PMTUD-র বার্তা
tcp.stream eq 7                      # শুধু ৭ নম্বর TCP সংযোগ

তিনটি সবচেয়ে কাজের মেনু

• Follow → TCP Stream: পুরো সংযোগের ডেটা কথোপকথনের মতো দেখায় — client এক রঙে, সার্ভার আরেক রঙে। সাধারণ HTTP বা SMTP-তে অসাধারণ; HTTPS-এ শুধু এনক্রিপ্ট করা বাইট।
• Statistics → Conversations আর IO Graph: Conversations দেখায় কোন দুই ঠিকানার মধ্যে কত বাইট গেছে — “কে bandwidth খাচ্ছে” এক নজরে। IO Graph সময়ের সাথে প্রতি সেকেন্ডের packet বা বাইট আঁকে — হঠাৎ থেমে যাওয়া চোখে পড়ে; retransmission-এর জন্য আলাদা রেখাও আঁকা যায়।
• Analyze → Expert Information: Wireshark-এর নিজের সতর্কবার্তার তালিকা — “Previous segment not captured”, “Dup ACK”, “Fast retransmission”, “Zero window” — শুরু করার ভালো জায়গা, কিন্তু রায় নয়: capture শুরুর আগের packet না থাকলেও “not captured” আসে।

৭ · Capture দেখে চেনা আটটি পরিচিত সমস্যা

অভিজ্ঞ ইঞ্জিনিয়ার capture-এ কয়েকটি “ছাপ” চেনেন — ডাক্তার যেমন এক্স-রে-তে ভাঙা হাড় চেনেন:

প্রথম সারির সময়গুলো কোথা থেকে? Linux-এ SYN-এর প্রথম timeout ১ সেকেন্ড, আর প্রতিবার দ্বিগুণ হয় (পর্ব ৩০-এর exponential backoff) — তাই পুনরায় পাঠানো হয় ১, ৩, ৭, ১৫, ৩১, ৬৩ সেকেন্ডে, আর ডিফল্ট ৬টি চেষ্টার পরে প্রায় ১২৭ সেকেন্ডে connect() হাল ছাড়ে। Capture-এ এই ছন্দ দেখলেই বুঝবেন: উত্তর আসছে না, প্রত্যাখ্যানও নয়।

একটি capture নিজে বিশ্লেষণ করা

Wireshark-এর বিশ্লেষণের মূল যুক্তি সরল: প্রতিটি দিকে পরের কোন বাইট আশা করছেন মনে রাখুন; পুরোনো বাইট আবার এলে retransmission, আরও পরের বাইট এলে ফাঁক; একই ack একই window-সহ বারবার এলে dup ACK; win 0 হলে zero window. নিচের কোড একটি হাতে লেখা, বাস্তবসম্মত tcpdump transcript পড়ে — client-এ নেওয়া capture (বাস্তবে timestamp আর SACK option-ও থাকত; সংক্ষেপের জন্য বাদ):

// Annotate a hand-written tcpdump -nn transcript: S = server 198.51.100.20.443, C = client 192.0.2.10.50412
const raw = `10:20:01.000000 IP 198.51.100.20.443 > 192.0.2.10.50412: Flags [.], seq 1:1449, ack 1, win 509, length 1448
10:20:01.000040 IP 192.0.2.10.50412 > 198.51.100.20.443: Flags [.], ack 1449, win 501, length 0
10:20:01.000300 IP 198.51.100.20.443 > 192.0.2.10.50412: Flags [.], seq 2897:4345, ack 1, win 509, length 1448
10:20:01.000340 IP 192.0.2.10.50412 > 198.51.100.20.443: Flags [.], ack 1449, win 501, length 0
10:20:01.000600 IP 198.51.100.20.443 > 192.0.2.10.50412: Flags [.], seq 4345:5793, ack 1, win 509, length 1448
10:20:01.000640 IP 192.0.2.10.50412 > 198.51.100.20.443: Flags [.], ack 1449, win 501, length 0
10:20:01.000900 IP 198.51.100.20.443 > 192.0.2.10.50412: Flags [.], seq 5793:7241, ack 1, win 509, length 1448
10:20:01.000940 IP 192.0.2.10.50412 > 198.51.100.20.443: Flags [.], ack 1449, win 501, length 0
10:20:01.031000 IP 198.51.100.20.443 > 192.0.2.10.50412: Flags [.], seq 1449:2897, ack 1, win 509, length 1448
10:20:01.031040 IP 192.0.2.10.50412 > 198.51.100.20.443: Flags [.], ack 7241, win 120, length 0
10:20:01.061000 IP 198.51.100.20.443 > 192.0.2.10.50412: Flags [P.], seq 7241:8689, ack 1, win 509, length 1448
10:20:01.061040 IP 192.0.2.10.50412 > 198.51.100.20.443: Flags [.], ack 8689, win 0, length 0
10:20:01.291000 IP 198.51.100.20.443 > 192.0.2.10.50412: Flags [.], ack 1, win 509, length 0
10:20:01.291040 IP 192.0.2.10.50412 > 198.51.100.20.443: Flags [.], ack 8689, win 0, length 0
10:20:01.700000 IP 192.0.2.10.50412 > 198.51.100.20.443: Flags [.], ack 8689, win 501, length 0
10:20:01.730000 IP 198.51.100.20.443 > 192.0.2.10.50412: Flags [P.], seq 8689:10137, ack 1, win 509, length 1448`;
const re = /^(\S+) IP (\S+) > (\S+): Flags \[([^\]]+)\],(?: seq (\d+):(\d+),)? ack (\d+), win (\d+), length (\d+)/;
const next = {}, last = {}; let dups = 0;
for (const line of raw.split("\n")) {
  const [, t, src, , flags, s, e, ack, win, len] = line.match(re);
  const who = src.endsWith(".443") ? "S" : "C", L = +len, W = +win; let note = "";
  if (L > 0) {                                        // a data segment
    const exp = next[who] ?? +s;
    note = +e <= exp ? `RETRANSMISSION of ${s}:${e}` + (dups >= 3 ? " (fast retransmit after 3 dup ACKs)" : "")
         : +s > exp ? `GAP: bytes ${exp}:${s} not seen yet (lost or reordered)` : "new data";
    next[who] = Math.max(exp, +e);
  } else if (who === "S" && last.C && last.C.win === 0) note = "WINDOW PROBE: are you still at win 0?";
  else if (W === 0) note = "ZERO WINDOW: receiver buffer full, sender must stop";
  else if (last[who] && last[who].win === 0) note = `WINDOW UPDATE: win ${W}, sender may continue`;
  else if (last[who] && last[who].ack === +ack && last[who].win === W && flags === ".") note = `DUP ACK #${++dups} (still waiting for byte ${ack})`;
  else { note = `ACK up to ${ack}` + (who === "C" && W < 200 ? `, window shrinking (win ${W})` : ""); if (who === "C") dups = 0; }
  if (L === 0) last[who] = { ack: +ack, win: W };
  console.log(`${t.slice(6)}  ${who === "S" ? "S->C" : "C->S"} [${flags.padEnd(2)}] ${(s ? s + ":" + e : "ack " + ack).padEnd(10)} win ${String(W).padStart(3)}  ${note}`);
}

01.000000  S->C [. ] 1:1449     win 509  new data
01.000040  C->S [. ] ack 1449   win 501  ACK up to 1449
01.000300  S->C [. ] 2897:4345  win 509  GAP: bytes 1449:2897 not seen yet (lost or reordered)
01.000340  C->S [. ] ack 1449   win 501  DUP ACK #1 (still waiting for byte 1449)
01.000600  S->C [. ] 4345:5793  win 509  new data
01.000640  C->S [. ] ack 1449   win 501  DUP ACK #2 (still waiting for byte 1449)
01.000900  S->C [. ] 5793:7241  win 509  new data
01.000940  C->S [. ] ack 1449   win 501  DUP ACK #3 (still waiting for byte 1449)
01.031000  S->C [. ] 1449:2897  win 509  RETRANSMISSION of 1449:2897 (fast retransmit after 3 dup ACKs)
01.031040  C->S [. ] ack 7241   win 120  ACK up to 7241, window shrinking (win 120)
01.061000  S->C [P.] 7241:8689  win 509  new data
01.061040  C->S [. ] ack 8689   win   0  ZERO WINDOW: receiver buffer full, sender must stop
01.291000  S->C [. ] ack 1      win 509  WINDOW PROBE: are you still at win 0?
01.291040  C->S [. ] ack 8689   win   0  ZERO WINDOW: receiver buffer full, sender must stop
01.700000  C->S [. ] ack 8689   win 501  WINDOW UPDATE: win 501, sender may continue
01.730000  S->C [P.] 8689:10137 win 509  new data

প্রমাণ থেকে PMTUD black hole ধরা

পর্ব ২০-এ black hole কীভাবে তৈরি হয় দেখেছেন; এবার দেখুন capture-এর প্রমাণ থেকে কীভাবে তা ধরা যায়। ঘটনা: একটি অফিসের ব্যবহারকারী (192.168.10.25) site-to-site VPN দিয়ে data center-এর একটি অভ্যন্তরীণ রিপোর্ট-সার্ভার (10.20.0.5, port 80) থেকে PDF নামাতে পারছেন না — পাতা খোলে, ডাউনলোড আটকে থাকে। নিচের capture আর কমান্ডগুলো উদাহরণ।

৮ · Capture-এর বাইরে — counter, পথ, নাম আর log

প্রায়ই capture লাগে না — kernel-এর হিসাব বা log-এর একটি লাইনই যথেষ্ট। পর্ব ৬-এর মৌলিক কমান্ডগুলোর পরের ধাপ:

curl-এর -w option একটি অনুরোধের সময়কে ভাগ করে দেখায় — কোন অংশে দেরি, তা এক লাইনে বোঝা যায় (উদাহরণ; সময়গুলো শুরু থেকে জমা হওয়া, সেকেন্ডে):

$ curl -o /dev/null -s -w 'dns %{time_namelookup}\ntcp %{time_connect}\ntls %{time_appconnect}\nttfb %{time_starttransfer}\ntotal %{time_total}\n' https://shop.example.com/
dns 0.004120
tcp 0.042310
tls 0.121877
ttfb 2.684532
total 2.701004

$ curl -sI --resolve shop.example.com:443:203.0.113.81 https://shop.example.com/   # DNS এড়িয়ে দ্বিতীয় সার্ভারটি সরাসরি পরীক্ষা
HTTP/2 200

পড়ুন: DNS ৪ ms; TCP সংযোগ শেষ ৪২ ms-এ (অর্থাৎ handshake প্রায় ৩৮ ms — এক RTT); TLS শেষ ১২২ ms-এ (আরও প্রায় ৮০ ms); কিন্তু প্রথম বাইট এলো ২.৬৮ সেকেন্ডে — TLS-এর পরে সার্ভার প্রায় ২.৫৬ সেকেন্ড “ভেবেছে”। নেটওয়ার্ক দ্রুত, সার্ভার ধীর। --resolve দিয়ে load balancer-এর পেছনের সার্ভারগুলো একটি একটি করে পরীক্ষা করা যায়, নাম আর certificate ঠিক রেখে।

একটি নির্দিষ্ট সংযোগের ভেতরে দেখতে ss -ti (উদাহরণ, কিছু ঘর বাদ দেওয়া):

$ ss -ti dst 203.0.113.80
ESTAB 0 0 192.168.0.105:51514 203.0.113.80:443
	 cubic wscale:7,7 rto:236 rtt:35.2/6.1 mss:1448 pmtu:1500 cwnd:10 ssthresh:7
	 bytes_retrans:4344 send 3.29Mbps retrans:0/3 minrtt:31.8 …

rtt:35.2/6.1 — গড় RTT আর তার ওঠানামা (ms); cwnd:10 — congestion window, segment-এ; ssthresh:7 — আগে loss হয়েছিল বলে নামানো সীমা (পর্ব ৩২); retrans:0/3 — এখন বাকি ০, মোট ৩টি retransmission, আর bytes_retrans:4344 = ৩ × ১৪৪৮. send 3.29Mbps হিসাবটি নিজে মেলান: cwnd × mss × ৮ ÷ rtt = ১০ × ১৪৪৮ × ৮ ÷ ০.০৩৫২ ≈ ৩.২৯ Mb/s — এই সংযোগ এখন এর বেশি পাঠাতে পারে না। (Throughput-এর পূর্ণ হিসাব পর্ব ৫৬-এ।)

এবার এই পাতার রানারেই প্রথম পরীক্ষাগুলো চালাই — একটি rootless container, বাইরের ইন্টারনেট নেই। স্ক্রিপ্টটি শুধু পড়ে, টুল আছে কি না আগে দেখে, private নয় এমন ঠিকানা ঢেকে দেয়; loopback-এ একটি খোলা port (perl-এর listener) আর একটি বন্ধ port-এ সংযোগের চেষ্টা করে, তারপর TCP counter পড়ে:

private() { case "$1" in 127.*|10.*|192.168.*|172.1[6-9].*|172.2[0-9].*|172.3[01].*) return 0;; esac; return 1; }
row() { printf '%-24s %-6s %s\n' "$1" "$2" "$3"; }
row CHECK RESULT DETAIL; row ----- ------ ------
up=""; for d in /sys/class/net/*; do n=${d##*/}; [ "$n" = lo ] && continue
  s=$(cat "$d/operstate"); c=$(cat "$d/carrier" 2>/dev/null || echo 0)
  { [ "$s" = up ] || { [ "$s" = unknown ] && [ "$c" = 1 ]; }; } && up="$up $n($s)"; done
[ -n "$up" ] && row "1 link up" PASS "${up# }" || row "1 link up" FAIL "no interface up"
a=$(ip -4 -o addr show scope global 2>/dev/null | awk '{print $2, $4}' | head -1)
set -- $a; private "${2%/*}" || a="$1 <host-IP>"
[ -n "$a" ] && row "2 IPv4 address" PASS "$a" || row "2 IPv4 address" FAIL "none (DHCP?)"
gw=$(ip route show default 2>/dev/null | awk '{print $3; exit}')
[ -n "$gw" ] && { private "$gw" || gw="<gateway-IP>"; row "3 default route" PASS "via $gw"; } || row "3 default route" FAIL "none"
ns=$(grep -c '^nameserver' /etc/resolv.conf 2>/dev/null)
[ "${ns:-0}" -gt 0 ] && row "4 resolv.conf" PASS "$ns nameserver line(s) (addresses hidden)" || row "4 resolv.conf" FAIL "no nameserver"
l=$(getent hosts localhost | awk '{print $1; exit}')
[ -n "$l" ] && row "5 getent localhost" PASS "$l" || row "5 getent localhost" FAIL "not resolved"
if command -v perl >/dev/null; then
  timeout 5 perl -MIO::Socket::INET -e '$s = IO::Socket::INET->new(LocalAddr => "127.0.0.1", LocalPort => 18080,
    Listen => 1, ReuseAddr => 1) or die; $c = $s->accept; close $c' & sleep 0.5
  timeout 3 bash -c 'exec 3<>/dev/tcp/127.0.0.1/18080' 2>/dev/null && row "6 TCP 127.0.0.1:18080" PASS "connected (listener up)" || row "6 TCP 127.0.0.1:18080" FAIL "no connect"
  wait
else row "6 TCP 127.0.0.1:18080" SKIP "perl নেই"; fi
timeout 3 bash -c 'exec 3<>/dev/tcp/127.0.0.1/9' 2>/dev/null; rc=$?
case $rc in 0) row "7 TCP 127.0.0.1:9" FAIL "unexpectedly open";; 124) row "7 TCP 127.0.0.1:9" FAIL "timeout: dropped/filtered?";;
  *) row "7 TCP 127.0.0.1:9" PASS "refused at once (closed port -> RST)";; esac
rs=$(awk '$1 == "Tcp:" { if (!h) { for (i = 1; i <= NF; i++) if ($i == "RetransSegs") k = i; h = 1 } else print $k }' /proc/net/snmp)
os=$(awk '$1 == "Tcp:" { if (!h) { for (i = 1; i <= NF; i++) if ($i == "OutSegs") k = i; h = 1 } else print $k }' /proc/net/snmp)
row "8 TCP retransmits" INFO "RetransSegs=$rs of OutSegs=$os"
command -v ss >/dev/null && ss -s | sed -n '1,2p' | sed 's/^/   ss -s: /' || echo "   ss নেই"

CHECK                    RESULT DETAIL
-----                    ------ ------
1 link up                PASS   tap0(unknown)
2 IPv4 address           PASS   tap0 10.0.2.100/24
3 default route          PASS   via 10.0.2.2
4 resolv.conf            PASS   5 nameserver line(s) (addresses hidden)
5 getent localhost       PASS   ::1
6 TCP 127.0.0.1:18080    PASS   connected (listener up)
7 TCP 127.0.0.1:9        PASS   refused at once (closed port -> RST)
8 TCP retransmits        INFO   RetransSegs=0 of OutSegs=8
   ss -s: Total: 1
   ss -s: TCP:   45 (estab 0, closed 45, orphaned 0, timewait 1)

৯ · গোপনীয়তা, নৈতিকতা আর একটি ভালো রিপোর্ট

একটি pcap ফাইল একটি খোলা ডায়েরির মতো: কে কখন কোন সার্ভারে গেছে, DNS-এ কোন নাম খুঁজেছে, এনক্রিপ্ট না করা protocol-এ পাসওয়ার্ড, cookie, ইমেইলের লেখা। HTTPS-এর যুগেও ঠিকানা, সময়, আকার আর অনেক সময় নাম (DNS, SNI) খোলা থাকে। তাই packet capture শুধু প্রযুক্তি নয়, দায়িত্বও:

• শুধু নিজের যন্ত্র, নিজের নেটওয়ার্ক, অথবা দায়িত্বপ্রাপ্ত ব্যক্তির লিখিত অনুমতির নেটওয়ার্কে capture করছি
• দরকারের বেশি ধরছি না — সরু filter (নির্দিষ্ট host আর port), ছোট snaplen, নির্দিষ্ট সময়
• ফাইল এনক্রিপ্ট করা জায়গায় রাখছি, কাজ শেষে মুছে ফেলছি; চ্যাট বা ইমেইলে খোলা অবস্থায় পাঠাচ্ছি না
• অন্য দলকে বা vendor-কে দেওয়ার আগে অপ্রাসঙ্গিক সংযোগ বাদ দিয়ে ছোট ফাইল বানিয়েছি
• প্রতিষ্ঠানের নীতি আর দেশের আইন জানি; সন্দেহ থাকলে আগে জিজ্ঞেস করেছি

ক্যাফে, হল বা প্রতিবেশীর Wi-Fi-তে অন্যের traffic দেখা “শেখার জন্য” হলেও অনৈতিক, আর বহু দেশে বেআইনি। শিখতে নিজের ল্যাপটপে দুটি VM বা একটি পুরোনো router দিয়ে ল্যাব বানান।

যে রিপোর্ট পড়ে অন্য দল কাজ শুরু করতে পারে

প্রায়ই অন্য কাউকে জানাতে হয় — ISP, সার্ভার-দল, vendor. “ইন্টারনেট স্লো, দেখুন” লিখলে উত্তর আসে “আমাদের দিকে সব ঠিক”। একটি প্রমাণসহ ছাঁচ (উদাহরণ):

শিরোনাম : shop.example.com — 10:15 থেকে HTTP 502, সব ব্যবহারকারী
প্রভাব   : অফিসের 40 জনের সবাই; মোবাইল ডেটা থেকেও একই
লক্ষণ    : ব্রাউজারে "502 Bad Gateway", server: nginx; 10/10 চেষ্টায়
সময়     : প্রথম অভিযোগ 10:17 (UTC+6); শেষ সফল অর্ডার 10:13
যা ঠিক আছে (প্রমাণসহ): link, DHCP, gateway, public IP, DNS (203.0.113.80),
           TCP 443 (nc), TLS 1.3 (s_client: Verification OK) — আউটপুট সংযুক্ত
পুনরুৎপাদন: curl -sI https://shop.example.com/  ->  HTTP/2 502
কী বদলেছে: আমাদের দিকে কিছু নয়; সার্ভার-দলের 10:14-এর deploy?
সংযুক্ত  : কমান্ডের আউটপুট (সময়সহ), 20 লাইনের ছোট pcap (শুধু এই host)
অনুরোধ  : proxy-র error log-এ 10:14-এর পরের upstream ত্রুটি দেখুন

রিপোর্টটি ব্যাখ্যা চাপিয়ে দেয় না; প্রমাণ দেয়, আর কী বাদ গেছে তা বলে। সার্ভার-দল proxy-র log খুলে হয়তো দেখবে connect() failed (111: Connection refused) while connecting to upstream — অ্যাপ সার্ভারটি deploy-এর পরে চালুই হয়নি। আর সমাধানের পরে একটি ছোট লেখা — কী হয়েছিল, কেন, কীভাবে ধরা পড়ল, আবার না ঘটতে কী করা হলো — দলের ভবিষ্যৎ incident-এর সবচেয়ে বড় সম্পদ।

১০ · AI-এর যুগে সমস্যা খোঁজা — সহকারী, বিচারক নয়

AI-কে tcpdump-এর আউটপুট বা error log দিলে সে দ্রুত সম্ভাব্য কারণের তালিকা দেয় — কাজের জিনিস। কিন্তু AI আপনার নেটওয়ার্ক দেখেনি, শুধু লেখা দেখেছে:

AI-এর পরামর্শ মানার আগে — চেকলিস্ট

• AI-এর রায় capture-এর নির্দিষ্ট লাইন দিয়ে নিজে মিলিয়েছি
• কমান্ড আমার OS-এর, man দেখে নিশ্চিত, আর আগে শুধু দেখার রূপে চালিয়েছি
• Filter কোন ধরনের (capture না display) বুঝে ঠিক টুলে দিয়েছি
• Firewall বা কনফিগ বদলের আগে ফেরার পথ (console, পুরোনো কনফিগের কপি) রেখেছি, আর একবারে একটি পরিবর্তন
• AI-কে দেওয়া লেখায় কারও ব্যক্তিগত তথ্য, পাসওয়ার্ড বা token নেই
• সমাধানের পরে আবার capture বা পরীক্ষা করে নিশ্চিত হয়েছি