ICMP — ping, traceroute আর ত্রুটির বার্তা

১ · IP-র একজন খবরবাহক দরকার কেন

পর্ব ১৫ আর ১৬-তে দেখেছেন, IP একটি “যতটা পারি চেষ্টা করি” (best effort) সেবা। Router packet পাঠায়, কিন্তু কোনো কথা দেয় না — পৌঁছাবে কি না, কবে পৌঁছাবে, কোনো নিশ্চয়তা নেই। পথে গন্তব্যের route না থাকলে, TTL ফুরালে বা packet কোনো link-এর MTU-র চেয়ে বড় হলে router packet ফেলে দেয়। প্রেরক কিছু না জানলে সে একই ভুল বারবার করবে।

ICMP-এর মূল সংজ্ঞা RFC 792, ১৯৮১ সালের সেপ্টেম্বরে Jon Postel-এর সম্পাদনায় প্রকাশিত — IPv4-এর RFC 791-এর সঙ্গী হিসেবে। পরে RFC 1122 (host, ১৯৮৯) আর RFC 1812 (router, ১৯৯৫) এর আচরণ আরও নির্দিষ্ট করে। IPv6-এর সংস্করণ ICMPv6 পর্ব ২১-এ; এই পর্ব IPv4-এর ICMP নিয়ে।

IP-র ভেতরে, অথচ IP-র সহকারী

ICMP-এর অবস্থানটা একটু ধাঁধার মতো। প্রতিটি ICMP বার্তা একটি সাধারণ IP packet-এর ভেতরে যায়, আর IP header-এর Protocol ঘরে লেখা থাকে ১ (TCP-র জন্য ৬, UDP-র জন্য ১৭)। তাহলে কি এটি TCP-UDP-র মতো একটি transport protocol? না। ICMP কোনো অ্যাপের ডেটা বহন করে না, এর কোনো port নেই, আর এর কাজ IP-র নিজের সমস্যার খবর দেওয়া। RFC 792 স্পষ্ট বলে: ICMP হলো IP-র একটি অবিচ্ছেদ্য অংশ, আর প্রতিটি IP বাস্তবায়নে এটি থাকতেই হবে। তাই বইগুলো ICMP-কে network layer-এর অংশ ধরে — শুধু বহনের সুবিধার জন্য সে IP-র খামে চড়ে।

┌──────────────────┬─────────────────────────────────────────┐
│ IP header (20 B) │ ICMP message                            │
│ Protocol = 1     │ Type │ Code │ Checksum │ rest …         │
└──────────────────┴─────────────────────────────────────────┘
  Protocol = 6 → TCP,  17 → UDP,  1 → ICMP  (IPv6: Next Header = 58 → ICMPv6)

তিনটি মৌলিক নিয়ম মনে রাখুন। প্রথমত, ICMP শুধু খবর দেয়, কিছু সারায় না — সিদ্ধান্ত নেয় প্রেরক। দ্বিতীয়ত, ত্রুটির খবর যায় শুধু মূল packet-এর উৎস ঠিকানায় (source IP), কারণ IP header-এ পথের অন্য কারও ঠিকানা থাকে না। তৃতীয়ত, ICMP নিজেও IP-তে চলে, তাই ICMP বার্তাও হারাতে পারে — এর ওপর ভরসা করে কোনো protocol নিশ্চয়তা দিতে পারে না, শুধু দ্রুত শিখতে পারে।

২ · ICMP বার্তার গঠন — type, code, checksum আর উদ্ধৃত header

সব ICMP বার্তার প্রথম ৪ বাইট একই ছাঁচের। Type (১ বাইট) বলে বার্তাটি কোন জাতের — Echo, Unreachable, Time Exceeded. Code (১ বাইট) সেই জাতের ভেতরে নির্দিষ্ট কারণ — যেমন Unreachable-এর ভেতরে “নেটওয়ার্ক নেই” না “port বন্ধ”। Checksum (২ বাইট) পুরো ICMP বার্তার ওপর হিসাব করা Internet checksum — পর্ব ৯-এর সেই ১৬-বিট one's complement যোগফল (RFC 1071). পরের ৪ বাইটের মানে type-ভেদে আলাদা, তারপর থাকে ডেটা।

 byte:  0        1        2        3
       ┌────────┬────────┬─────────────────┐
       │  Type  │  Code  │    Checksum     │  same for every ICMP message
       ├────────┴────────┴─────────────────┤
       │  rest of header (4 bytes)         │  Echo:   Identifier │ Sequence
       │                                   │  Type 3: unused │ next-hop MTU
       │                                   │  Type 12: Pointer │ unused
       │                                   │  Type 5: gateway IP address
       ├───────────────────────────────────┤
       │  data                             │  Echo:  any payload (echoed back)
       │                                   │  Error: original IP header + 8 B
       └───────────────────────────────────┘

Echo বার্তা — identifier আর sequence

Echo Request (type ৮, code ০) পাঠালে গন্তব্য একটি Echo Reply (type ০, code ০) ফেরত দেয়, যেখানে identifier, sequence আর পুরো ডেটা হুবহু একই থাকে — শুধু type বদলায় (আর তাই checksum). Identifier দিয়ে আলাদা করা হয় কোন ping প্রোগ্রামের উত্তর (একই যন্ত্রে দুটি ping একসাথে চললে), আর sequence দিয়ে কোন packet-এর উত্তর — ১, ২, ৩… একটি নম্বর বাদ গেলে সেই packet হারিয়েছে। ডেটা অংশে Linux-এর ping সাধারণত পাঠানোর সময় (timestamp) লিখে দেয়, যাতে উত্তর এলে RTT হিসাব করা যায়; Windows-এর ping ডিফল্টভাবে ৩২ বাইটের বর্ণমালা পাঠায় (abcdefghijklmnopqrstuvwabcdefghi).

ত্রুটির বার্তা — মূল packet-এর “খাম” ফেরত

ত্রুটির বার্তায় ডেটা অংশে router বা গন্তব্য যন্ত্র জুড়ে দেয় যে packet-টি সমস্যায় পড়েছিল তার IP header, আর তার ঠিক পরের অন্তত ৮ বাইট (RFC 792-এর ভাষায় “64 bits of original data”). এই ৮ বাইট কেন? কারণ সেখানেই থাকে transport header-এর শুরু। UDP-র পুরো header ৮ বাইট: source port, destination port, length, checksum. TCP-র প্রথম ৮ বাইটে source port, destination port আর sequence number. অর্থাৎ এই ৮ বাইট পেলেই প্রেরকের kernel বুঝতে পারে খবরটি কোন socket-এর, কোন সংযোগের — আর সেই প্রোগ্রামকে জানাতে পারে।

┌────────────── new IP header (20 B) ───────────────┐
│ src = router or target   dst = original sender    │
│ Protocol = 1 (ICMP)                               │
├────────────── ICMP header (8 B) ──────────────────┤
│ Type = 3 │ Code = 3 │ Checksum │ unused (0)       │
├────── quoted: the original IP header (20 B) ──────┤
│ src = 192.168.0.105  dst = 192.0.2.20  Proto = 17 │
├────── quoted: first 8 bytes of its payload ───────┤
│ src port 50000 │ dst port 9999 │ length │ csum    │  ← the UDP header
└───────────────────────────────────────────────────┘

RFC 1812 পরে router-দের বলেছে, পুরো ICMP packet ৫৭৬ বাইট না ছাড়িয়ে যত বেশি সম্ভব উদ্ধৃত করতে; Linux-ও তাই করে। NAT router উদ্ধৃত header দেখেই ICMP ত্রুটিকে ভেতরের সঠিক যন্ত্রের কাছে ফেরত পাঠায়, আর Echo-র identifier-কে port-এর মতো ব্যবহার করে — NAT-এর translation table-এর মূল কৌশল পর্ব ১৯-এ।

নিজের হাতে একটি Echo Request বানানো — C

এবার হাতে-কলমে। নিচের C প্রোগ্রাম ১৬ বাইটের একটি Echo Request বানায় — identifier 0x1234, sequence ১, ডেটা abcdefgh — checksum হিসাব করে, hex-এ ছাপে, তারপর একটি “ping socket” খুলে আসল বার্তাটি 127.0.0.1-এ পাঠানোর চেষ্টা করে। Ping socket (SOCK_DGRAM, IPPROTO_ICMP) দিয়ে root ছাড়াই Echo পাঠানো যায়, যদি সিস্টেম অনুমতি দেয় (অংশ ৮)। অনুমতি না পেলে প্রোগ্রাম কারণটি ছাপে, আর উত্তরটি (Echo Reply) নিজেই বানিয়ে দেখায় — সেটি যে নিজের বানানো, তা তারকা চিহ্ন দিয়ে আলাদা করে।

#include <stdio.h>
#include <string.h>
#include <errno.h>
#include <unistd.h>
#include <arpa/inet.h>
#include <sys/socket.h>
static unsigned short csum(const unsigned char *p, int n) {     /* RFC 1071 Internet checksum */
    unsigned long s = 0; for (int i = 0; i < n; i += 2) s += (unsigned)(p[i] << 8 | (i + 1 < n ? p[i + 1] : 0));
    while (s >> 16) s = (s & 0xFFFF) + (s >> 16);                /* end-around carry */
    return (unsigned short)~s;                                    /* one's complement */
}
static void put(unsigned char *p, int n) { unsigned short c; p[2] = p[3] = 0; c = csum(p, n); p[2] = c >> 8; p[3] = c & 0xFF; }
static void hex(const char *tag, const unsigned char *p, int n) {
    printf("%-8s", tag); for (int i = 0; i < n; i++) printf("%02x%s", p[i], i == 3 || i == 7 ? " | " : " ");
    printf("\n         type=%u code=%u csum=0x%02x%02x id=0x%02x%02x seq=%u  verify=%s\n",
           p[0], p[1], p[2], p[3], p[4], p[5], p[6] << 8 | p[7], csum(p, n) == 0 ? "OK" : "BAD");
}
int main(void) {
    unsigned char req[16] = {8, 0, 0, 0, 0x12, 0x34, 0x00, 0x01, 'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h'}, rep[64];
    put(req, 16); hex("request", req, 16);                       /* type 8 = Echo Request */
    int s = socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP);           /* unprivileged "ping socket" */
    if (s < 0) {
        int e = errno; char r[64] = "?"; FILE *f = fopen("/proc/sys/net/ipv4/ping_group_range", "r");
        if (f) { if (!fgets(r, sizeof r, f)) r[0] = 0; fclose(f); r[strcspn(r, "\n")] = 0; r[strcspn(r, "\t")] = ' '; }
        printf("socket() failed: %s (%s); my gid=%u, ping_group_range=\"%s\"\n",
               e == EACCES ? "EACCES" : e == EPERM ? "EPERM" : "other", strerror(e), (unsigned)getgid(), r);
        memcpy(rep, req, 16); rep[0] = 0; put(rep, 16);          /* fallback: build the reply locally */
        hex("reply*", rep, 16); printf("(* built locally, not received)\n"); return 0;
    }
    struct sockaddr_in to = {.sin_family = AF_INET, .sin_addr.s_addr = htonl(INADDR_LOOPBACK)};
    sendto(s, req, 16, 0, (struct sockaddr *)&to, sizeof to);   /* kernel sets id and checksum */
    long n = recv(s, rep, sizeof rep, 0);                       /* reply = ICMP header + data, no IP header */
    if (n >= 8) hex("reply", rep, (int)n); else printf("no reply\n");
    close(s); return 0;
}

request 08 00 54 35 | 12 34 00 01 | 61 62 63 64 65 66 67 68
         type=8 code=0 csum=0x5435 id=0x1234 seq=1  verify=OK
socket() failed: EACCES (Permission denied); my gid=999, ping_group_range="0 0"
reply*  00 00 5c 35 | 12 34 00 01 | 61 62 63 64 65 66 67 68
         type=0 code=0 csum=0x5c35 id=0x1234 seq=1  verify=OK
(* built locally, not received)

৩ · প্রধান বার্তাগুলো — type, code আর “কখন পাঠানো নিষেধ”

ICMP-এ অনেক type সংজ্ঞায়িত, কিন্তু রোজকার নেটওয়ার্কে কয়েকটিই বারবার দেখবেন। পুরো তালিকা রাখে IANA; নিচের টেবিলে সেগুলোই, যা পরীক্ষা, ইন্টারভিউ আর বাস্তব সমস্যায় আসে:

Type ৩ (Destination Unreachable)-এর code দেখেই বোঝা যায় packet কত দূর গিয়েছিল: code ০ — পথের মাঝে, ১ — গন্তব্যের LAN পর্যন্ত, ২ ও ৩ — যন্ত্রটি পর্যন্ত।

পুরোনো আর বাতিল বার্তা

কয়েকটি type ইতিহাসে আছে, কিন্তু আজ ব্যবহার করা উচিত নয়। Source Quench (type ৪) দিয়ে ব্যস্ত router প্রেরককে “ধীরে” বলত; এটি অকার্যকর আর জাল বার্তায় অপব্যবহারযোগ্য ছিল, TCP-র congestion control (পর্ব ৩২) কাজটি অনেক ভালো করে, তাই RFC 6633 (২০১২) একে বাতিল করেছে। Information Request/Reply (১৫/১৬) আর Address Mask Request/Reply (১৭/১৮) বহু আগেই DHCP-র মতো ব্যবস্থার কাছে জায়গা হারিয়েছে, আর RFC 6918 (২০১৩) সেগুলোসহ আরও কিছু type বাতিল ঘোষণা করেছে। Timestamp Request/Reply (১৩/১৪) RFC 6918-এর তালিকায় নেই, তাই এখনো আনুষ্ঠানিকভাবে বাতিল নয়, কিন্তু খুব কম ব্যবহৃত, আর ঘড়ির তথ্য ফাঁস করে বলে সাধারণত বাইরের দিকে বন্ধ রাখা হয়।

কখন ICMP ত্রুটির বার্তা পাঠানো নিষেধ

একটি ত্রুটি থেকে যদি আরেকটি ত্রুটির খবর, তা থেকে আরেকটি — এভাবে চলতে থাকে, তবে নেটওয়ার্ক বার্তার বন্যায় ডুবে যাবে। তাই RFC 1122 আর RFC 1812 কয়েকটি কড়া নিয়ম দিয়েছে। ICMP ত্রুটির বার্তা পাঠানো হবে না, যদি সমস্যার packet-টি:

• নিজেই একটি ICMP ত্রুটির বার্তা হয় — ত্রুটির খবরের ত্রুটি নেই, নইলে অসীম চক্র। (তবে Echo-র মতো query-র ক্ষেত্রে ত্রুটির খবর যায় — এজন্যই tracert-এর ICMP Echo probe-এর জন্য Time Exceeded আসে।)
• Broadcast বা multicast ঠিকানায় (বা link স্তরের broadcast হিসেবে) এসেছে — নইলে একটি packet-এর জবাবে শত শত যন্ত্র একসাথে ত্রুটি পাঠাত।
• একটি fragment, যা প্রথম টুকরো নয় — শুধু প্রথম টুকরোতেই transport header (port) থাকে, তাই পরের টুকরোর জন্য খবর পাঠালে প্রেরক চিনতেই পারত না, আর একটি packet-এর জন্য অনেক খবর যেত। (Fragmentation পর্ব ১৬-তে।)
• এমন উৎস-ঠিকানা থেকে আসে, যা একটি নির্দিষ্ট host নয় — যেমন 0.0.0.0, loopback, broadcast বা multicast ঠিকানা।

এর ওপর আধুনিক router আর OS ICMP পাঠানোর হার সীমিত রাখে (rate limiting) — RFC 1812 এটি অনুমোদন করে, আর ICMPv6-এর RFC 4443 তো বাধ্যতামূলক করেছে। এই হার-সীমা traceroute পড়ার সময় বড় ভূমিকা রাখে (অংশ ৫)।

এবার একটি সম্পূর্ণ ঘটনা ধাপে ধাপে দেখুন: একটি ল্যাপটপ একটি সার্ভারের এমন UDP port-এ ডেটা পাঠাল, যেখানে কেউ শুনছে না।

৪ · ping ভেতর থেকে — RTT, loss, mdev আর TTL-এর ইঙ্গিত

পর্ব ৬-এ ping চালানো আর তার আউটপুট পড়া শিখেছেন, আর পর্ব ৫-এ দেখেছেন RTT-এর ভেতরে কোন কোন delay লুকিয়ে থাকে। এখানে দেখব ping আসলে কী করে। প্রতি সেকেন্ডে একটি Echo Request, sequence প্রতিবার ১ বেশি; উত্তর এলে identifier আর sequence মিলিয়ে “এখনের সময় − পাঠানোর সময়” = RTT; শেষে পরিসংখ্যান।

শেষ লাইনের চারটি সংখ্যা

Linux-এর ping (iputils) শেষে ছাপে rtt min/avg/max/mdev. প্রথম তিনটি সোজা — সবচেয়ে কম, গড়, সবচেয়ে বেশি। চতুর্থটি mdev: নাম “mean deviation” শোনালেও iputils আসলে হিসাব করে population standard deviation:

অর্থাৎ RTT-গুলো গড়ের চারপাশে কতটা ছড়িয়ে আছে — jitter-এর একটি মাপ। মাত্র একটি দেরিতে আসা উত্তর mdev অনেক বাড়িয়ে দিতে পারে, কারণ বিচ্যুতি বর্গ করা হয়। আর packet loss-এর হিসাব: (পাঠানো − পাওয়া) ÷ পাঠানো × ১০০. খেয়াল করুন, Linux-এর ping হারানো packet-এর জন্য কোনো লাইন ছাপে না — শুধু icmp_seq-এ একটি ফাঁক থাকে। নিচের simulator ঠিক iputils-এর মতো করে হিসাব করে — microsecond-এর পূর্ণসংখ্যায়, যেভাবে আসল প্রোগ্রাম করে। “চালান” চাপুন, তারপর rtt তালিকায় সংখ্যা বদলে বা null যোগ করে দেখুন:

// ping statistics, computed the way Linux iputils ping does (integer microseconds)
const target = "192.0.2.10", ttl = 56;
const rtt = [38.204, 37.912, null, 39.871, 51.204, 38.533, null, 38.090, 41.577, 39.012]; // ms, null = lost
function fmt(ms) {                    // iputils prints fewer decimals for bigger times
  return ms >= 100 ? ms.toFixed(0) : ms >= 10 ? ms.toFixed(1) : ms >= 1 ? ms.toFixed(2) : ms.toFixed(3);
}
const us = [];                        // received RTTs in microseconds
console.log(`PING ${target} (${target}) 56(84) bytes of data.`);
rtt.forEach((t, i) => {
  if (t === null) return;             // a lost reply prints nothing: look for the gap in icmp_seq
  us.push(Math.round(t * 1000));
  console.log(`64 bytes from ${target}: icmp_seq=${i + 1} ttl=${ttl} time=${fmt(t)} ms`);
});
const n = us.length, sent = rtt.length;
const sum = us.reduce((a, b) => a + b, 0), sum2 = us.reduce((a, b) => a + b * b, 0);
const avg = Math.floor(sum / n);
const variance = Math.floor((sum2 - Math.floor(sum * sum / n)) / n);   // E[x^2] - E[x]^2
const mdev = Math.floor(Math.sqrt(variance));
const ms3 = x => (x / 1000).toFixed(3);
console.log(`\n--- ${target} ping statistics ---`);
console.log(`${sent} packets transmitted, ${n} received, ${+((sent - n) * 100 / sent).toPrecision(6)}% packet loss, time ${(sent - 1) * 1000 + 9}ms`);
console.log(`rtt min/avg/max/mdev = ${ms3(Math.min(...us))}/${ms3(avg)}/${ms3(Math.max(...us))}/${ms3(mdev)} ms`);
console.log(`\ncheck: sum=${sum} us, mean=${(sum / n).toFixed(1)} us, mdev=${mdev} us (population std. dev.)`);
console.log(`Windows ping would say: Lost = ${sent - n} (${Math.floor((sent - n) * 100 / sent)}% loss), ` +
  `Minimum = ${Math.round(Math.min(...us) / 1000)}ms, Maximum = ${Math.round(Math.max(...us) / 1000)}ms, Average = ${Math.round(sum / n / 1000)}ms`);

PING 192.0.2.10 (192.0.2.10) 56(84) bytes of data.
64 bytes from 192.0.2.10: icmp_seq=1 ttl=56 time=38.2 ms
64 bytes from 192.0.2.10: icmp_seq=2 ttl=56 time=37.9 ms
64 bytes from 192.0.2.10: icmp_seq=4 ttl=56 time=39.9 ms
64 bytes from 192.0.2.10: icmp_seq=5 ttl=56 time=51.2 ms
64 bytes from 192.0.2.10: icmp_seq=6 ttl=56 time=38.5 ms
64 bytes from 192.0.2.10: icmp_seq=8 ttl=56 time=38.1 ms
64 bytes from 192.0.2.10: icmp_seq=9 ttl=56 time=41.6 ms
64 bytes from 192.0.2.10: icmp_seq=10 ttl=56 time=39.0 ms

--- 192.0.2.10 ping statistics ---
10 packets transmitted, 8 received, 20% packet loss, time 9009ms
rtt min/avg/max/mdev = 37.912/40.550/51.204/4.182 ms

check: sum=324403 us, mean=40550.4 us, mdev=4182 us (population std. dev.)
Windows ping would say: Lost = 2 (20% loss), Minimum = 38ms, Maximum = 51ms, Average = 41ms

উত্তরের TTL থেকে অনুমান — সাবধানে

উত্তরের ttl=56 দেখে পর্ব ৬-এ hop গুনেছিলেন: প্রচলিত শুরুর মান ৬৪ (Linux, macOS, Android), ১২৮ (Windows), ২৫৫ (অনেক router আর নেটওয়ার্ক যন্ত্র) — উত্তরের TTL-এর ঠিক ওপরের মানটিকে শুরু ধরে বিয়োগ করলে ফেরার পথের router-সংখ্যার অনুমান মেলে, আর শুরুর মানটি OS-এর একটি দুর্বল ইঙ্গিত দেয়। দুর্বল, কারণ শুরুর মান বদলানো যায় (net.ipv4.ip_default_ttl), পথের load balancer বা firewall নিজেই উত্তর দিতে পারে, আর ফেরার পথ আলাদা হতে পারে — এটি সূত্র, প্রমাণ নয়।

“Request timed out” বনাম “Destination host unreachable”

এই দুটি বার্তা দেখতে কাছাকাছি, কিন্তু মানে সম্পূর্ণ আলাদা — আর নতুনরা প্রায়ই গুলিয়ে ফেলেন। নিচের উদাহরণগুলো একটি বাসার LAN-এর (Windows আর Linux; চালানো নয়, উদাহরণ):

PS> ping 192.0.2.99                    # দূরের ঠিকানা, উত্তর আসে না
Pinging 192.0.2.99 with 32 bytes of data:
Request timed out.
Request timed out.
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

PS> ping 192.168.0.77                  # নিজের LAN-এ, কিন্তু ওই ঠিকানায় কোনো যন্ত্র নেই
Pinging 192.168.0.77 with 32 bytes of data:
Reply from 192.168.0.105: Destination host unreachable.
Reply from 192.168.0.105: Destination host unreachable.
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

$ ping -c 3 192.168.0.77
PING 192.168.0.77 (192.168.0.77) 56(84) bytes of data.
From 192.168.0.105 icmp_seq=1 Destination Host Unreachable
From 192.168.0.105 icmp_seq=2 Destination Host Unreachable
From 192.168.0.105 icmp_seq=3 Destination Host Unreachable

--- 192.168.0.77 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2030ms

$ ping -c 2 192.0.2.200
PING 192.0.2.200 (192.0.2.200) 56(84) bytes of data.
From 198.51.100.1 icmp_seq=1 Destination Net Unreachable

• Request timed out (Linux-এ কোনো লাইনই আসে না) — Echo গেছে, কিন্তু নির্দিষ্ট সময়ে (Windows-এ ডিফল্ট ৪ সেকেন্ড) কোনো উত্তর বা ত্রুটির খবর আসেনি। গন্তব্য বন্ধ, firewall, না পথে হারানো — নিশ্চিত নয়।
• Destination host unreachable — নিজের ঠিকানা থেকে (192.168.0.105) — খবরটি দিয়েছে আপনার নিজের কম্পিউটার! গন্তব্য একই LAN-এ, তাই আপনার যন্ত্র ARP দিয়ে তার MAC খুঁজেছিল, কয়েকবার চেষ্টায় কোনো উত্তর পায়নি, তাই packet পাঠাতেই পারেনি (ARP পর্ব ১৮-তে)। মানে: ওই ঠিকানায় এখন কোনো যন্ত্র চালু নেই বা LAN-এ যুক্ত নেই। লক্ষ করুন, Windows এই “Reply”-গুলোকে পাওয়া উত্তর গুনে 0% loss দেখায় — একটি বিখ্যাত বিভ্রান্তি।
• অন্য কারও ঠিকানা থেকে Unreachable (From 198.51.100.1 … Net Unreachable) — পথের একটি router জানাচ্ছে তার কাছে ওই নেটওয়ার্কের কোনো route নেই। এবার সমস্যা আপনার যন্ত্রে নয়, ওই router-এর routing-এ; আর খবরদাতার ঠিকানাই বলে দেয় কোথায় খুঁজতে হবে।

৫ · traceroute ভেতর থেকে — TTL, তিনটি probe আর তিন রকম পদ্ধতি

traceroute-এর মূল কৌশল পর্ব ৬-এ দেখেছেন: TTL ১ দিয়ে শুরু, প্রতিবার ১ বাড়ানো, আর যে router-এ TTL ০ হয় সে ICMP Time Exceeded পাঠায় — তার উৎস-ঠিকানাই সেই hop. Linux-এর traceroute ডিফল্টভাবে UDP probe পাঠায়, গন্তব্য port ৩৩৪৩৪ থেকে শুরু করে প্রতিটি probe-এ ১ বাড়িয়ে, আর প্রতি TTL-এ তিনটি probe. ধাপে ধাপে দেখুন — পথে দুটি router, তারপর গন্তব্য:

তিন রকম probe — UDP, ICMP আর TCP

তিন পদ্ধতিতেই মাঝের router-দের উত্তর একই — Time Exceeded; আলাদা শুধু শেষের সংকেত। আরেকটি সূক্ষ্মতা: Linux-এ ছোট একটি বিকল্প tracepath (iputils), যা root ছাড়াই UDP দিয়ে পথ খোঁজে আর সাথে path MTU-ও জানায় (অংশ ৬)।

traceroute পড়ার চারটি ফাঁদ

• * * * মানেই ভাঙা নয়। কোনো router Time Exceeded পাঠায় না (নীতি বা firewall), তবু packet ঠিকই forward করে। পরের hop-গুলো উত্তর দিলে সেটিই প্রমাণ যে পথ চালু।
• Asymmetric পথ। traceroute শুধু যাওয়ার পথ দেখায়। কিন্তু প্রতিটি RTT-তে ফেরার পথও ঢোকে, আর ইন্টারনেটে ফেরার পথ প্রায়ই আলাদা (asymmetric routing) — প্রতিটি নেটওয়ার্ক নিজের নীতিতে পথ বাছে (BGP, পর্ব ২৫)। ফলে কোনো hop-এর RTT এমন একটি ফেরার পথের প্রভাব বহন করতে পারে, যা তালিকায় নেই-ই।
• MPLS-এ লুকানো hop. অনেক ISP-এর ভেতরের নেটওয়ার্ক MPLS-এ চলে। প্রবেশের router যদি IP-র TTL MPLS label-এ না বসায় (TTL propagation বন্ধ), তবে ভেতরের router-রা traceroute-এ অদৃশ্য — কয়েকটি hop মিলে একটি মনে হয়।
• মাঝের hop ধীর, অথচ শেষটা দ্রুত — rate limiting. এটিই সবচেয়ে প্রচলিত ভুল ব্যাখ্যা। নিচের simulator-এ দেখুন।

Router packet forward করে বিশেষ হার্ডওয়্যারে (data plane), কিন্তু ICMP বানায় সাধারণ CPU-তে — control plane-এ, কম অগ্রাধিকারে আর হার সীমিত রেখে (rate limiting), যাতে কেউ TTL-ফুরানো packet-এর বন্যায় CPU দখল করতে না পারে। ফল: hop-এর নিজের উত্তর ধীর, অথচ তাকে পার হওয়া packet দ্রুত। নিচের simulator একটি নির্দিষ্ট পথে traceroute চালায় — একটি hop নীরব, একটি hop ধীর আর হার-সীমিত — আর শেষে প্রতিটি লাইনের ব্যাখ্যা ছাপে:

// traceroute simulator: UDP probes with TTL 1, 2, 3 ..., three probes per TTL
const path = [   // ms = one-way delay to this router; cpu = extra time its CPU takes to reply
  { ip: "192.168.0.1",  ms: 0.6 },
  { ip: "198.51.100.1", ms: 2.1 },
  { ip: "198.51.100.9", ms: 3.0, silent: true },            // never sends Time Exceeded
  { ip: "203.0.113.5",  ms: 17.4, cpu: 45, limit: 2 },      // slow, max 2 ICMP per burst
  { ip: "203.0.113.77", ms: 18.6 },
  { ip: "192.0.2.10",   ms: 18.9, dest: true },             // the target host
];
const wobble = [0.12, -0.08, 0.21, 0.03, -0.15, 0.09];     // fixed jitter: repeatable output
let port = 33434, k = 0;
const notes = [];
console.log("traceroute to 192.0.2.10 (192.0.2.10), 30 hops max, 60 byte packets");
for (let ttl = 1; ttl <= 30; ttl++) {
  const r = path[ttl - 1];             // a probe sent with TTL = n dies (or arrives) at hop n
  const parts = []; let sent = 0;
  for (let p = 0; p < 3; p++, port++) {
    if (r.silent || (r.limit && sent >= r.limit)) { parts.push("*"); continue; }
    if (sent++ === 0) parts.push(r.ip);
    parts.push((2 * r.ms + (r.cpu || 0) + wobble[k++ % 6] + 0.3 * p).toFixed(3) + " ms");
  }
  console.log(String(ttl).padStart(2) + "  " + (sent ? parts.join("  ") : "* * *"));
  notes.push(ttl + ": " + (r.silent ? "no reply at all (ICMP filtered/disabled); later hops answer, so packets DO pass"
    : r.dest ? "ICMP 3/3 Port Unreachable from the target itself (dst ports 33434.." + (port - 1) + ") -> stop"
    : r.limit ? "ICMP 11/0, slow + one probe unanswered: rate limit on the router CPU, later hops fine"
    : "ICMP 11/0 Time Exceeded from " + r.ip));
  if (r.dest) break;
}
console.log("--- explanation ---\n" + notes.join("\n"));

traceroute to 192.0.2.10 (192.0.2.10), 30 hops max, 60 byte packets
 1  192.168.0.1  1.320 ms  1.420 ms  2.010 ms
 2  198.51.100.1  4.230 ms  4.350 ms  4.890 ms
 3  * * *
 4  203.0.113.5  79.920 ms  80.020 ms  *
 5  203.0.113.77  37.410 ms  37.530 ms  37.650 ms
 6  192.0.2.10  37.890 ms  38.220 ms  38.320 ms
--- explanation ---
1: ICMP 11/0 Time Exceeded from 192.168.0.1
2: ICMP 11/0 Time Exceeded from 198.51.100.1
3: no reply at all (ICMP filtered/disabled); later hops answer, so packets DO pass
4: ICMP 11/0, slow + one probe unanswered: rate limit on the router CPU, later hops fine
5: ICMP 11/0 Time Exceeded from 203.0.113.77
6: ICMP 3/3 Port Unreachable from the target itself (dst ports 33434..33451) -> stop

বিরতিহীন সমস্যা খুঁজতে একবারের traceroute যথেষ্ট নয়। mtr (Linux, macOS) পথের প্রতিটি hop-এ বারবার probe পাঠিয়ে প্রতি hop-এর loss % আর RTT-এর হিসাব জীবন্ত দেখায়; Windows-এর pathping প্রথমে পথ খুঁজে তারপর প্রতিটি hop-এ কিছুক্ষণ ধরে মেপে একই রকম সারাংশ দেয়। পড়ার নিয়ম একই — নিচের উদাহরণে hop ৪-এর ৩৮% loss পরের কোনো hop-এ নেই, তাই সেটি আসল loss নয়:

$ mtr -rwnc 100 192.0.2.10
HOST: laptop               Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.0.1          0.0%   100    1.4   1.5   1.1   3.2   0.3
  2.|-- 198.51.100.1         0.0%   100    4.3   4.6   4.0   9.8   0.7
  3.|-- ???                100.0%   100    0.0   0.0   0.0   0.0   0.0
  4.|-- 203.0.113.5         38.0%   100   80.1  81.0  79.6  95.2   2.1
  5.|-- 203.0.113.77         0.0%   100   37.5  37.7  37.2  40.1   0.4
  6.|-- 192.0.2.10           0.0%   100   38.0  38.3  37.8  41.0   0.5

PS> tracert -d 192.0.2.10              # Windows: ICMP Echo probe, সময় পূর্ণ ms-এ
  1     1 ms     1 ms     2 ms  192.168.0.1
  2     4 ms     4 ms     5 ms  198.51.100.1
  3     *        *        *     Request timed out.
  4    80 ms    80 ms     *     203.0.113.5
  5    37 ms    37 ms    38 ms  203.0.113.77
  6    38 ms    38 ms    38 ms  192.0.2.10
Trace complete.

৬ · Path MTU Discovery — “Fragmentation Needed” আর black hole

পথের প্রতিটি link-এর MTU আলাদা হতে পারে: সাধারণ Ethernet-এ ১৫০০ বাইট, PPPoE সংযোগে প্রায়ই ১৪৯২, VPN বা অন্য tunnel-এ আরও কম (header-এর জায়গা ছাড়তে হয়)। পথের সবচেয়ে ছোট MTU-ই path MTU. বড় packet ছোট link-এ ঢোকাতে IPv4 router packet টুকরো করতে পারে (fragmentation — বিস্তারিত পর্ব ১৬-তে), কিন্তু টুকরো করা ব্যয়বহুল আর একটি টুকরো হারালে পুরো packet নষ্ট। তাই আধুনিক host, বিশেষ করে TCP, packet-এ DF (Don't Fragment) বিট দিয়ে পাঠায় আর নিজেই পথের MTU শিখে নেয়। এই কৌশলের নাম Path MTU Discovery (PMTUD), RFC 1191 (১৯৯০)। আর শেখার একমাত্র উৎস — ICMP type ৩, code ৪.

RFC 1191 type ৩-এর অব্যবহৃত ৪ বাইটের শেষ ২ বাইটে একটি নতুন ঘর যোগ করেছে: Next-Hop MTU — router জানিয়ে দেয় পরের link কত বড় packet নিতে পারে। নিচে একটি ওয়েব সার্ভার একজন ব্যবহারকারীকে বড় একটি পাতা পাঠাচ্ছে, আর মাঝে একটি ১৪০০ বাইটের tunnel link:

PMTUD black hole বাস্তবে এত প্রচলিত যে ২০০০ সালেই RFC 2923 TCP-র PMTUD সমস্যাগুলোর তালিকায় একে শীর্ষে রেখেছিল। Linux-এ tracepath দিয়ে নিজের পথের MTU দেখা যায় — উদাহরণ (চালানো নয়):

$ tracepath -n 192.0.2.55
 1?: [LOCALHOST]                      pmtu 1500
 1:  198.51.100.1                                          1.102ms
 1:  198.51.100.1                                          1.054ms
 2:  198.51.100.1                                          1.210ms pmtu 1400
 2:  198.51.100.200                                        6.871ms
 3:  192.0.2.55                                            7.305ms reached
     Resume: pmtu 1400 hops 3 back 3

IPv6-এ router কখনো packet টুকরো করে না; সেখানে একই কাজ করে ICMPv6-এর “Packet Too Big” বার্তা, আর সেটি আটকালে IPv6 ব্যবহারই অচল হয়ে পড়ে — পর্ব ২১-এ দেখবেন।

৭ · ICMP আর নিরাপত্তা — কোনটি রাখবেন, কোনটি নয়

ICMP-এর অপব্যবহারের ইতিহাস আছে, আর সেই ইতিহাস থেকেই আজকের নিয়মগুলো এসেছে। এখানে আক্রমণগুলো শুধু ধারণা হিসেবে — কীভাবে কাজ করত আর কীভাবে ঠেকানো হয়েছে।

যেভাবে ঠেকানো হয়েছে: RFC 2644 (১৯৯৯) router-দের ডিফল্টভাবে directed broadcast forward না করতে বলেছে — smurf-এর “বর্ধক” নেটওয়ার্কই আর পাওয়া যায় না। Host-রাও broadcast ঠিকানার Echo-র উত্তর দেয় না (Linux-এ icmp_echo_ignore_broadcasts = 1, ডিফল্ট)। জাল উৎস-ঠিকানা ঠেকাতে ISP-রা নিজেদের গ্রাহকের দিক থেকে আসা packet-এর উৎস যাচাই করে (ingress filtering, BCP 38 / RFC 2827). আর প্রতিটি যন্ত্র ICMP-র হার সীমিত রাখে, ISP-র প্রান্তে বন্যা-traffic ছেঁকে ফেলা হয়। বড় আকারের DDoS আর তার প্রতিরক্ষা পর্ব ৫০-এ।

Redirect — সুবিধা, কিন্তু ঝুঁকিও

Redirect (type ৫)-এর উদ্দেশ্য সৎ: এক LAN-এ দুটি router থাকলে ভুল router host-কে ঠিক router দেখিয়ে দেয়। কিন্তু একই LAN-এর কোনো দুষ্ট যন্ত্র জাল Redirect পাঠিয়ে host-এর traffic নিজের দিকে ঘুরিয়ে নিতে পারে — মাঝখানে বসে আড়ি পাতার (MITM) একটি পথ। তাই আজকের পরামর্শ: সাধারণ host-এ Redirect গ্রহণ বন্ধ, router নয় এমন যন্ত্রে পাঠানোও বন্ধ, আর নেটওয়ার্কের সীমানায় বাইরের Redirect ফেলে দেওয়া। Linux-এ এগুলো sysctl দিয়ে নিয়ন্ত্রিত হয় (উদাহরণ, নিজের যন্ত্রে root হিসেবে):

net.ipv4.conf.all.accept_redirects = 0      # Redirect মেনে route বদলাবে না
net.ipv4.conf.all.send_redirects = 0        # router না হলে Redirect পাঠাবে না
net.ipv4.icmp_echo_ignore_broadcasts = 1    # broadcast-এ পাঠানো Echo-র উত্তর নয় (ডিফল্ট)
net.ipv4.icmp_ignore_bogus_error_responses = 1

“সব ICMP বন্ধ” কেন খারাপ নীতি

অনেক প্রতিষ্ঠানের firewall-এ এখনো দেখা যায় “ICMP: deny all”. “ping বন্ধ থাকলে কেউ খুঁজে পাবে না” — দুর্বল যুক্তি, কারণ খোলা TCP port (যেমন ৪৪৩) থেকেই সার্ভার চেনা যায়। অথচ দাম অনেক: PMTUD ভাঙে, নিজের দলের সমস্যা খোঁজা কঠিন হয়, UDP অ্যাপ অকারণে অপেক্ষা করে। তাই নির্দেশিকাগুলো (যেমন ICMPv6-এর জন্য RFC 4890) বেছে বেছে নিয়মের কথা বলে:

Stateful firewall (পর্ব ৪৯) এ কাজ আরও সহজ করে: চলমান কোনো সংযোগের সাথে সম্পর্কিত ICMP ত্রুটিকে সে উদ্ধৃত header দেখে চেনে আর “related” হিসেবে ঢুকতে দেয় — অর্থাৎ অংশ ২-এর সেই ৮ বাইট firewall-এর কাছেও প্রমাণপত্র।

৮ · Linux-এ ICMP — ping socket, kernel-এর হিসাব আর সেটিং

ICMP-এর কোনো port নেই, তাই সাধারণ TCP/UDP socket দিয়ে Echo পাঠানো যায় না। ঐতিহ্যগতভাবে ping ব্যবহার করত raw socket — যেখানে প্রোগ্রাম নিজেই পুরো ICMP বার্তা বানায়, আর যে কোনো packet পাঠাতে ও দেখতে পারে। এত ক্ষমতা বলে raw socket-এ root লাগে (বা CAP_NET_RAW নামের capability). তাই বহু বছর ping ছিল setuid root; পরে অনেক distribution শুধু cap_net_raw দেয় (প্র ০৫-এ ইতিহাস)।

Linux 3.0 (২০১১) একটি পরিচ্ছন্ন সমাধান আনে — ping socket: socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP). এটি শুধু Echo পাঠাতে আর তার উত্তর পেতে দেয়; identifier kernel বসায়, যাতে একজন অন্যের ping-এর উত্তর পড়তে না পারে। কে এটি খুলতে পারবে, তা ঠিক করে net.ipv4.ping_group_range — দুটি সংখ্যা, group id-র একটি পরিসর। Kernel-এর ডিফল্ট 1 0 (খালি পরিসর — কেউ নয়), কিন্তু systemd-এর একটি সংস্করণ থেকে অনেক distribution এটি 0 2147483647 (সবাই) করে দেয় — আপনার যন্ত্রে কী আছে তা নিজে দেখে নিন। আধুনিক iputils-এর ping অনুমতি থাকলে ping socket ব্যবহার করে, নইলে raw socket. (macOS-এও এমন socket আছে।)

অংশ ২-এর C প্রোগ্রাম ঠিক এই কারণে EACCES পেয়েছিল। এবার bash দিয়ে একই container-এ দেখি: কোন ICMP টুল আছে, ping socket-এর অনুমতি কার, আর kernel-এর ICMP হিসাব /proc/net/snmp-এ কীভাবে বদলায়। ওই ফাইলে প্রতিটি protocol-এর দুটি লাইন — প্রথমটিতে counter-এর নাম, দ্বিতীয়টিতে মান, একই ক্রমে; স্ক্রিপ্ট দুটি লাইন জোড়া লাগিয়ে শুধু শূন্য নয় এমন counter ছাপে। মাঝখানে bash-এর নিজস্ব /dev/udp সুবিধা দিয়ে 127.0.0.1-এর ৯ নম্বর port-এ তিনটি UDP datagram পাঠানো হয় — যেখানে কেউ শোনে না। অংশ ৩-এর স্টেপার মনে আছে?

echo "== 1. tools =="
for t in ping traceroute tracepath mtr; do
  command -v "$t" >/dev/null && echo "  $t: আছে ($(command -v "$t"))" || echo "  $t: নেই"
done
echo "== 2. ping socket permission =="
read -r lo hi < /proc/sys/net/ipv4/ping_group_range
echo "  ping_group_range = $lo $hi ; my gid = $(id -g)"
if [ "$(id -g)" -ge "$lo" ] && [ "$(id -g)" -le "$hi" ]; then echo "  -> ICMP datagram socket allowed"
else echo "  -> ICMP datagram socket NOT allowed for this group"; fi
show() {   # print only the non-zero Icmp / IcmpMsg counters (header line + value line)
  awk -v want="$1" '$1 == want":" { if (!h) { split($0, n); h = 1 } else { for (i = 2; i <= NF; i++)
    if ($i != 0) printf "  %s %s = %s\n", want, n[i], $i } }' /proc/net/snmp
}
echo "== 3. counters before =="
show Icmp; show IcmpMsg; echo "  (anything not listed is 0)"
echo "== 4. three UDP datagrams to 127.0.0.1:9 (nobody listens there) =="
for i in 1 2 3; do echo "probe $i" > /dev/udp/127.0.0.1/9; done
sleep 0.2
echo "== 5. counters after =="
show Icmp; show IcmpMsg
echo "== 6. related settings =="
for f in icmp_echo_ignore_broadcasts icmp_ratelimit icmp_ratemask ip_default_ttl; do
  echo "  $f = $(cat /proc/sys/net/ipv4/$f)"
done

== 1. tools ==
  ping: নেই
  traceroute: নেই
  tracepath: নেই
  mtr: নেই
== 2. ping socket permission ==
  ping_group_range = 0 0 ; my gid = 999
  -> ICMP datagram socket NOT allowed for this group
== 3. counters before ==
  (anything not listed is 0)
== 4. three UDP datagrams to 127.0.0.1:9 (nobody listens there) ==
== 5. counters after ==
  Icmp InMsgs = 3
  Icmp InDestUnreachs = 3
  Icmp OutMsgs = 3
  Icmp OutDestUnreachs = 3
  IcmpMsg InType3 = 3
  IcmpMsg OutType3 = 3
== 6. related settings ==
  icmp_echo_ignore_broadcasts = 1
  icmp_ratelimit = 1000
  icmp_ratemask = 6168
  ip_default_ttl = 64

৯ · AI-এর যুগে ICMP — উত্তর মিলিয়ে নেওয়া

“traceroute-এ hop ৭-এ ২০০ ms, ISP-কে কী বলব?” — এমন প্রশ্নে AI প্রায়ই আত্মবিশ্বাসী ভুল করে: মাঝের hop-এর delay-কে সমস্যা ধরে নেয়, “নিরাপত্তার জন্য সব ICMP বন্ধ করুন” পরামর্শ দেয়, বা ভুল type/code বলে।

AI-এর ICMP-বিষয়ক উত্তর মানার আগে — চেকলিস্ট

• Type আর code IANA-র তালিকা বা RFC 792/1191-এর সাথে মিলিয়েছি
• traceroute-এর রায় দেওয়ার আগে দেখেছি delay/loss গন্তব্য পর্যন্ত টিকে থাকে কি না
• Firewall পরামর্শে type ৩ (code ৪), ১১, ১২ বাদ পড়েনি, আর Echo-তে হার-সীমা আছে
• Checksum, MTU বা mdev-এর হিসাব নিজে বা কোড দিয়ে আবার করেছি
• কমান্ডটি আমার OS-এর, command -v আর man দিয়ে যাচাই করেছি, আর আগে শুধু দেখার রূপে চালিয়েছি
• কোনো পরীক্ষা অন্যের যন্ত্র বা নেটওয়ার্ককে লক্ষ্য করছে না; সন্দেহ থাকলে নিজের ল্যাবে বা VM-এ packet capture করে দেখেছি