Cloud আর container নেটওয়ার্কিং — VPC, Docker আর Kubernetes

১ · Cloud-এ নিজের নেটওয়ার্ক — VPC আসলে কী

ধরুন আপনার প্রতিষ্ঠান একটি অনলাইন দোকান চালায়। আগে নিজের অফিসে সার্ভার রাখতে হতো: switch কেনা, তার টানা, router বসানো, firewall কেনা। এখন একটি cloud প্রদানকারীর (AWS, Microsoft Azure, Google Cloud…) পাতায় কয়েকটি ক্লিক বা কয়েক লাইন কনফিগারেশন — আর মিনিটের মধ্যে আপনার নিজের একটি নেটওয়ার্ক তৈরি। এর নাম VPC (Virtual Private Cloud; Azure-এ বলে VNet).

VPC-তে তিনটি জিনিস পুরোপুরি আপনার হাতে: ঠিকানার পরিসর (সাধারণত একটি private CIDR ব্লক, যেমন 10.20.0.0/16), সেই পরিসরকে কীভাবে subnet-এ ভাগ করবেন, আর কোন ট্রাফিক কোন পথে যাবে (route table). অথচ আসল তার, switch আর router আপনি কখনো দেখেন না। একই ভবনে, একই rack-এ হয়তো আরেকটি প্রতিষ্ঠানের VPC-ও চলছে — একই 10.20.0.0/16 ঠিকানা নিয়ে! তবু কেউ কারও packet দেখে না।

নিচে কী চলছে — overlay আর SDN

একই ঠিকানা দুটি গ্রাহকের দুটি VPC-তে থাকতে পারে কারণ VPC একটি overlay network. আপনার VM যে packet পাঠায় (উৎস 10.20.0.10), hypervisor-এর ভেতরের একটি সফটওয়্যার switch সেটিকে ধরে, দেখে এটি কোন গ্রাহকের কোন VPC-র, তারপর পুরো packet-টি আরেকটি বাইরের header-এ মুড়ে (encapsulation) প্রদানকারীর নিজস্ব underlay নেটওয়ার্কে গন্তব্য VM-এর আসল সার্ভারে পাঠায়। মোড়কের ভেতরে একটি গ্রাহক-চিহ্ন থাকে — অনেকটা পর্ব ১৩-এ দেখা VXLAN-এর ২৪ bit-এর VNI-র মতো। কোন VM কোন সার্ভারে, কোন VPC-র route কী — এই তথ্য সব hypervisor-এ বসিয়ে দেয় একটি কেন্দ্রীয় controller. এটাই SDN-এর ধারণা (পর্ব ৫৩)।

এই পর্বে নামগুলো AWS-এর রাখা হলো, কারণ সেগুলো সবচেয়ে প্রচলিত। কিন্তু ধারণা প্রায় সব প্রদানকারীতে এক — শুধু নাম, সীমা আর ডিফল্ট আচরণ আলাদা। কাজে নামার আগে সবসময় নিজের প্রদানকারীর ডকুমেন্টেশন দেখবেন।

২ · Subnet, route table আর gateway — public আর private subnet

একটি cloud region (যেমন সিঙ্গাপুর বা মুম্বাই) কয়েকটি availability zone (AZ)-এ ভাগ করা — প্রতিটি AZ এক বা একাধিক আলাদা data center, আলাদা বিদ্যুৎ আর ঠান্ডা করার ব্যবস্থা, কিন্তু নিজেদের মধ্যে দ্রুত সংযোগ। একটি AZ-এ আগুন লাগলে বা বিদ্যুৎ গেলে অন্যগুলো চলে। তাই ভালো নকশায় একই কাজের সার্ভার অন্তত দুটি, সাধারণত তিনটি AZ-এ ছড়িয়ে রাখা হয়। AWS-এ প্রতিটি subnet ঠিক একটি AZ-এর ভেতরে থাকে, তাই “তিন AZ × দুই স্তর = ছয়টি subnet” খুব চেনা নকশা।

চারটি জিনিস, একটি নিয়ম

AWS প্রতিটি subnet-এর পাঁচটি ঠিকানা নিজের কাজে রেখে দেয়: প্রথম চারটি (network ঠিকানা, VPC router, DNS, ভবিষ্যতের জন্য একটি) আর শেষটি। তাই একটি /24 subnet-এ ব্যবহারযোগ্য ২৫৬ − ৫ = ২৫১টি ঠিকানা। অন্য প্রদানকারীর সংখ্যা আলাদা হতে পারে (Google Cloud সাধারণত চারটি রাখে)। এবার private subnet-এর একটি ডেটাবেস সার্ভার কীভাবে আপডেট নামায়, আর কেন বাইরের কেউ তাকে ছুঁতে পারে না — ধাপে ধাপে দেখুন।

৩ · Security group আর network ACL — দুই স্তরের পাহারা

পর্ব ৪৯-এ firewall-এর দুই রূপ দেখেছেন — stateful আর stateless. Cloud-এ দুটিই আছে, দুই জায়গায়:

SG-র সবচেয়ে কাজের বৈশিষ্ট্য হলো আরেকটি SG-কে উৎস হিসেবে লেখা: “db-তে port 5432 খোলা শুধু sg-web-এর সদস্যদের জন্য”. ওয়েব সার্ভার বাড়ুক-কমুক, ঠিকানা বদলাক — নিয়ম একই থাকে। এটি ঠিকানা-ভিত্তিক থেকে পরিচয়-ভিত্তিক নিয়মের দিকে একটি পদক্ষেপ, যা Kubernetes-এর NetworkPolicy-তে (অংশ ৮) আরও এগিয়েছে।

একটি VPC-র সিদ্ধান্ত নিজে যাচাই

নিচের simulator অংশ ২-এর VPC: web (10.20.0.10, public-a, public IP 203.0.113.10, SG: 443 সবার জন্য) আর db (10.20.48.20, private-a, SG: 5432 শুধু sg-web থেকে)। Public subnet-এর NACL সব খোলা; private subnet-এর NACL কড়া: inbound-এ 5432 শুধু VPC থেকে আর ফিরতি ephemeral port, outbound-এ 443 আর VPC-র দিকে ফিরতি port. পাঁচটি flow-এর প্রতিটি ধাপের সিদ্ধান্ত আর কারণ ছাপা হয়।

// AWS-style VPC 10.20.0.0/16: route tables, stateful security groups, stateless ordered NACLs.
const n = s => s.split(".").reduce((a, o) => a * 256 + +o, 0);
const inC = (ip, c) => { const [b, l] = c.split("/"), m = 2 ** (32 - l); return Math.floor(n(ip) / m) === Math.floor(n(b) / m); };
const RT = { pub: [["10.20.0.0/16", "local"], ["0.0.0.0/0", "igw"]], priv: [["10.20.0.0/16", "local"], ["0.0.0.0/0", "nat-gw"]] };
const HOST = { "10.20.0.10": { name: "web", sub: "pub", sg: "web", eip: "203.0.113.10" },
               "10.20.48.20": { name: "db", sub: "priv", sg: "db" } };
const SG = { web: [[443, "0.0.0.0/0"]], db: [[5432, "sg-web"]] };          // inbound allows; outbound: all
const NACL = { pub: { in: [[100, 0, 65535, "0.0.0.0/0"]], out: [[100, 0, 65535, "0.0.0.0/0"]] },
  priv: { in: [[100, 5432, 5432, "10.20.0.0/16"], [110, 1024, 65535, "0.0.0.0/0"]], out: [[100, 443, 443, "0.0.0.0/0"], [110, 1024, 65535, "10.20.0.0/16"]] } };
const route = (sub, dst) => RT[sub].filter(r => inC(dst, r[0])).sort((a, b) => b[0].split("/")[1] - a[0].split("/")[1])[0]; // longest prefix
const nacl = (sub, dir, port, peer) => { const r = NACL[sub][dir].find(([, lo, hi, c]) => port >= lo && port <= hi && inC(peer, c));
  return r ? [true, `NACL ${sub}/${dir} rule ${r[0]} allow`] : [false, `NACL ${sub}/${dir} rule * DENY`]; };
const sg = (h, port, src) => { const r = SG[h.sg].find(([p, s]) => p === port && (s === "sg-" + HOST[src]?.sg || (!s.startsWith("sg") && inC(src, s))));
  return r ? [true, `SG ${h.sg} allows ${port} from ${r[1]}`] : [false, `SG ${h.sg}: no rule -> DROP`]; };
function flow(title, src, sp, dst, dp) {
  console.log(`\n# ${title}: ${src}:${sp} -> ${dst}:${dp}`); let S = HOST[src], D = Object.entries(HOST).find(([ip, h]) => ip === dst || h.eip === dst), checks = [];
  if (!S) {                                                    // from the internet
    if (dst === "203.0.113.50") return console.log("  NAT GW 203.0.113.50: no entry for this flow (it only answers flows started inside) -> DROP");
    const [ip, h] = D; console.log(`  IGW: public ${dst} -> private ${ip} (${h.name})`);
    checks = [nacl(h.sub, "in", dp, src), sg(h, dp, src), nacl(h.sub, "out", sp, src)];
  } else {
    const r = route(S.sub, dst); console.log(`  route table ${S.sub}: ${dst} matches ${r[0]} -> ${r[1]}`);
    checks.push(nacl(S.sub, "out", dp, dst), [true, `SG ${S.sg} outbound: allow all`]);
    if (r[1] === "local") { const h = HOST[dst];
      checks.push(nacl(h.sub, "in", dp, src), sg(h, dp, src), nacl(h.sub, "out", sp, src), nacl(S.sub, "in", sp, dst));
    } else if (r[1] === "nat-gw") checks.push([true, "NAT GW: SNAT src -> 203.0.113.50 (+ its own port), remembers the flow"], nacl(S.sub, "in", sp, dst));
  }
  for (const [ok, why] of checks) { console.log("  " + (ok ? "ok   " : "FAIL ") + why); if (!ok) return console.log("  => BLOCKED"); }
  console.log("  => ALLOWED (reply: SG remembers the flow; NACL return rules checked above)");
}
flow("internet -> web", "198.51.100.7", 50123, "203.0.113.10", 443);
flow("web -> db", "10.20.0.10", 41000, "10.20.48.20", 5432);
flow("db -> internet (OS updates)", "10.20.48.20", 43210, "198.51.100.80", 443);
flow("internet -> web on 22", "198.51.100.7", 50124, "203.0.113.10", 22);
flow("internet -> db via NAT GW IP", "198.51.100.7", 50125, "203.0.113.50", 5432);

# internet -> web: 198.51.100.7:50123 -> 203.0.113.10:443
  IGW: public 203.0.113.10 -> private 10.20.0.10 (web)
  ok   NACL pub/in rule 100 allow
  ok   SG web allows 443 from 0.0.0.0/0
  ok   NACL pub/out rule 100 allow
  => ALLOWED (reply: SG remembers the flow; NACL return rules checked above)

# web -> db: 10.20.0.10:41000 -> 10.20.48.20:5432
  route table pub: 10.20.48.20 matches 10.20.0.0/16 -> local
  ok   NACL pub/out rule 100 allow
  ok   SG web outbound: allow all
  ok   NACL priv/in rule 100 allow
  ok   SG db allows 5432 from sg-web
  ok   NACL priv/out rule 110 allow
  ok   NACL pub/in rule 100 allow
  => ALLOWED (reply: SG remembers the flow; NACL return rules checked above)

# db -> internet (OS updates): 10.20.48.20:43210 -> 198.51.100.80:443
  route table priv: 198.51.100.80 matches 0.0.0.0/0 -> nat-gw
  ok   NACL priv/out rule 100 allow
  ok   SG db outbound: allow all
  ok   NAT GW: SNAT src -> 203.0.113.50 (+ its own port), remembers the flow
  ok   NACL priv/in rule 110 allow
  => ALLOWED (reply: SG remembers the flow; NACL return rules checked above)

# internet -> web on 22: 198.51.100.7:50124 -> 203.0.113.10:22
  IGW: public 203.0.113.10 -> private 10.20.0.10 (web)
  ok   NACL pub/in rule 100 allow
  FAIL SG web: no rule -> DROP
  => BLOCKED

# internet -> db via NAT GW IP: 198.51.100.7:50125 -> 203.0.113.50:5432
  NAT GW 203.0.113.50: no entry for this flow (it only answers flows started inside) -> DROP

৪ · VPC-কে বাইরের সাথে জোড়া — আর CIDR পরিকল্পনা

একটি VPC একা থাকে না। একই প্রতিষ্ঠানের আরেকটি VPC, ঢাকার অফিস, চট্টগ্রামের শাখা, প্রদানকারীর নিজস্ব সেবা (storage, ডেটাবেস) — সবার সাথে যোগ লাগে। প্রধান উপায়গুলো:

• VPC peering: দুটি VPC-র মধ্যে সরাসরি private সংযোগ; দুই পাশের route table-এ অপর পাশের CIDR যোগ করতে হয়। এটি transitive নয়: A–B আর B–C peering থাকলেও A থেকে C-তে যাওয়া যায় না। দুটি VPC-র CIDR মিলে গেলে (overlap) peering-ই করা যায় না।
• Transit gateway: অনেক VPC আর অফিসের সংযোগের কেন্দ্রীয় hub — বাসের রুটের একটি বড় টার্মিনালের মতো, যেখানে সব রুট এসে মেলে। দশটি VPC-কে জোড়ায় জোড়ায় peering করলে ১০ × ৯ ÷ ২ = ৪৫টি সংযোগ লাগত; hub-এ লাগে ১০টি।
• Private endpoint: প্রদানকারীর সেবা (যেমন object storage) বা অন্য প্রতিষ্ঠানের সেবায় ইন্টারনেট বা NAT gateway ছাড়াই, VPC-র ভেতরের একটি private ঠিকানা দিয়ে পৌঁছানো (AWS-এ PrivateLink/VPC endpoint, Azure-এ Private Endpoint, Google-এ Private Service Connect).
• Site-to-site VPN আর ডেডিকেটেড সংযোগ: অফিসের router আর cloud-এর VPN gateway-এর মধ্যে IPsec tunnel (পর্ব ৪৯) — ইন্টারনেটের ওপর দিয়ে, এনক্রিপ্টেড। আরও স্থির গতি আর latency চাইলে ভাড়া করা ব্যক্তিগত লাইন: AWS Direct Connect, Azure ExpressRoute, Google Cloud Interconnect.
• Cloud load balancer: public subnet-এ বসে বাইরের ট্রাফিক নেয়, private subnet-এর সার্ভারগুলোতে ভাগ করে দেয় — L4 (TCP/UDP) বা L7 (HTTP) স্তরে। Load balancing-এর algorithm আর L4/L7-এর পার্থক্য পর্ব ৫২-এ।

CIDR পরিকল্পনা — আগে ভাবলে পরে কাঁদতে হয় না

VPC-র CIDR একবার বাছলে পরে বদলানো কঠিন (কিছু প্রদানকারী অতিরিক্ত CIDR যোগ করতে দেয়, কিন্তু পুরোনোটা সরানো ঝামেলার)। সবচেয়ে বড় ভুল হলো সবাই মিলে একই চেনা পরিসর বাছা — 10.0.0.0/16 বা 192.168.0.0/16. পরে যখন অফিসের নেটওয়ার্ক বা আরেকটি প্রতিষ্ঠানের VPC-র সাথে জুড়তে হয়, ঠিকানা মিলে যায় আর routing অসম্ভব হয়ে পড়ে: একই ঠিকানা দুই জায়গায় থাকলে router কোন দিকে পাঠাবে? পর্ব ১৭-এর subnetting এখানে সরাসরি কাজে লাগে।

উদাহরণ: একটি 10.20.0.0/16 VPC, তিনটি AZ, প্রতিটিতে একটি public আর একটি private subnet, প্রত্যেকটি /20. হিসাব: /16 থেকে /20 মানে ৪ bit ধার, তাই ২^৪ = ১৬টি /20 হতে পারে, প্রতিটিতে ২^১২ = ৪,০৯৬ ঠিকানা। তৃতীয় octet-এ block size ১৬, তাই subnet-গুলো শুরু হয় 10.20.0.0, 10.20.16.0, 10.20.32.0… থেকে। ছয়টি নিলে দশটি ফাঁকা থাকে ভবিষ্যতের জন্য। নিচের planner এটি করে, আর তিনটি নেটওয়ার্কের সাথে overlap পরীক্ষা করে।

// Plan /20 subnets for a 10.20.0.0/16 VPC across 3 AZs, then check overlaps with other networks.
const n = s => s.split(".").reduce((a, o) => a * 256 + +o, 0);
const ip = x => [24, 16, 8, 0].map(b => Math.floor(x / 2 ** b) % 256).join(".");
const range = c => { const [b, l] = c.split("/"), size = 2 ** (32 - l); return [n(b), n(b) + size - 1, size]; };
const VPC = "10.20.0.0/16", NEW = 20, AZS = ["a", "b", "c"];
let [next, vpcEnd] = range(VPC); const plan = [];
for (const tier of ["public", "private"]) for (const az of AZS) {
  const cidr = `${ip(next)}/${NEW}`, [lo, hi, size] = range(cidr);
  plan.push({ name: `${tier}-${az}`, cidr, lo, hi, size }); next = hi + 1;
}
console.log("subnet     cidr            first .. last                   usable*");
for (const s of plan)
  console.log(`${s.name.padEnd(10)} ${s.cidr.padEnd(15)} ${(ip(s.lo) + " .. " + ip(s.hi)).padEnd(31)} ${s.size - 5}`);
const left = vpcEnd - next + 1;
console.log(`used ${plan.length} x /${NEW} = ${plan.length * 2 ** (32 - NEW)} addrs; free: ${ip(next)} .. ${ip(vpcEnd)} = ${left} (${left / 2 ** (32 - NEW)} more /${NEW})`);
const overlap = (a, b) => { const [a1, a2] = range(a), [b1, b2] = range(b); return a1 <= b2 && b1 <= a2; };
const others = { "Dhaka office": "10.10.0.0/16", "Ctg branch": "10.20.200.0/22", "partner VPC": "10.0.0.0/8" };
console.log("\noverlap check against " + VPC);
for (const [who, c] of Object.entries(others)) {
  const hits = plan.filter(s => overlap(s.cidr, c)).map(s => s.name);
  const v = overlap(VPC, c) ? "OVERLAP" + (hits.length ? " with " + hits.join(",") : " (inside VPC range, no subnet yet)") : "ok";
  console.log(`  ${who.padEnd(13)} ${c.padEnd(15)} ${v}`);
}
console.log("* usable = size - 5 (AWS reserves 5 per subnet; other clouds differ)");

subnet     cidr            first .. last                   usable*
public-a   10.20.0.0/20    10.20.0.0 .. 10.20.15.255       4091
public-b   10.20.16.0/20   10.20.16.0 .. 10.20.31.255      4091
public-c   10.20.32.0/20   10.20.32.0 .. 10.20.47.255      4091
private-a  10.20.48.0/20   10.20.48.0 .. 10.20.63.255      4091
private-b  10.20.64.0/20   10.20.64.0 .. 10.20.79.255      4091
private-c  10.20.80.0/20   10.20.80.0 .. 10.20.95.255      4091
used 6 x /20 = 24576 addrs; free: 10.20.96.0 .. 10.20.255.255 = 40960 (10 more /20)

overlap check against 10.20.0.0/16
  Dhaka office  10.10.0.0/16    ok
  Ctg branch    10.20.200.0/22  OVERLAP (inside VPC range, no subnet yet)
  partner VPC   10.0.0.0/8      OVERLAP with public-a,public-b,public-c,private-a,private-b,private-c
* usable = size - 5 (AWS reserves 5 per subnet; other clouds differ)

৫ · Container-এর নেটওয়ার্ক — namespace, veth আর bridge

এবার এক যন্ত্রের ভেতরে নামি। একটি container আসলে একটি সাধারণ Linux প্রসেস, যাকে kernel আলাদা “চশমা” পরিয়ে দিয়েছে — নিজের প্রসেস-তালিকা, নিজের ফাইল-সিস্টেম, আর নেটওয়ার্কের জন্য নিজের network namespace: নিজের interface, নিজের IP, নিজের route table, নিজের firewall নিয়ম আর socket. Namespace আর cgroup-এর পুরো গল্প অপারেটিং সিস্টেম কোর্সের Container — namespace আর cgroup পর্বে; এখানে শুধু নেটওয়ার্কের দিকটা।

নতুন network namespace জন্মায় শুধু একটি বন্ধ lo নিয়ে — বাইরের সাথে কোনো যোগ নেই। যোগ দিতে তিনটি ইট:

1. veth জোড়া: একটি ভার্চুয়াল তারের দুই মাথা। এক মাথা container-এর namespace-এ (ভেতরে নাম eth0), অন্য মাথা host-এ (নাম vethXXXX). এক মাথায় যে frame ঢোকে, অন্য মাথা দিয়ে বেরোয়।
2. Linux bridge: host-এর ভেতরে একটি সফটওয়্যার switch (Docker-এ নাম docker0). সব container-এর host-পাশের veth মাথা এতে লাগানো, তাই একই bridge-এর container-রা পর্ব ১২-এর switch-এর মতো MAC শিখে একে অপরের সাথে কথা বলে। Bridge-এর নিজেরও একটি IP (172.17.0.1) — container-দের default gateway.
3. Routing আর NAT: host-এর kernel 172.17.0.0/16-এর packet বাইরের interface-এ forward করে, আর বেরোনোর সময় masquerade করে উৎস বদলে host-এর ঠিকানা বসায় — ঠিক বাসার router-এর মতো (পর্ব ১৯)।

এই কোর্সের কোড যে container-এ চলে, তার নেটওয়ার্ক

এই পাতার bash কোড যে সার্ভারে চলে, সেটি নিজেই একটি rootless container. নিচের স্ক্রিপ্ট শুধু পড়ে: আমরা কোন network namespace-এ, কী interface আছে, সেগুলো কোন ধরনের, আর একজন সাধারণ ব্যবহারকারী নতুন network namespace বানাতে পারে কি না। শেষ ধাপে একটি ফেলে-দেওয়া নতুন namespace-এর ভেতরে একটি veth জোড়া বানিয়ে দেখা হয় — host-এর কিছুই বদলায় না।

echo "== 1. which network namespace am I in? =="
echo "  net : $(readlink /proc/self/ns/net)   user: $(readlink /proc/self/ns/user)   uid=$(id -u)"
echo "== 2. interfaces and addresses =="
if command -v ip >/dev/null; then ip -br link; ip -br -4 addr
else for d in /sys/class/net/*; do echo "  ${d##*/} $(cat "$d/address")"; done; fi
echo "== 3. routing table =="
command -v ip >/dev/null && ip route || tail -n +2 /proc/net/route
echo "== 4. what kind of interface is each one? =="
for d in /sys/class/net/*; do
  n=${d##*/}; kind=other
  [ "$n" = lo ] && kind=loopback
  [ -e "$d/tun_flags" ] && kind="tun/tap: a program on the host holds the other end"
  [ -d "$d/bridge" ] && kind=bridge
  [ "$(cat "$d/iflink")" != "$(cat "$d/ifindex")" ] && kind="$kind, peer ifindex=$(cat "$d/iflink") (veth-like)"
  echo "  $n: $kind  mtu=$(cat "$d/mtu")"
done
echo "== 5. packet counters (/proc/net/dev) =="
tail -n +3 /proc/net/dev | while read -r line; do
  set -- ${line/:/ }; echo "  $1 rx_packets=$3 tx_packets=${11}"
done
echo "== 6. may an ordinary user create a NEW network namespace? =="
command -v unshare >/dev/null || { echo "  unshare নেই"; exit 0; }
out=$(unshare -n true 2>&1) && echo "  unshare -n : allowed" || echo "  unshare -n : denied -> ${out#unshare: }"
inner='echo "  inside: $(readlink /proc/self/ns/net)"; ip -br link
  ip link add v-host type veth peer name v-ctr 2>&1 && echo "  veth pair created:" && ip -br link | grep v-'
out=$(unshare -rn sh -c "$inner" 2>&1) && echo "  unshare -rn: allowed (via a user namespace)" || echo "  unshare -rn: denied"
echo "$out"

== 1. which network namespace am I in? ==
  net : net:[4026532747]   user: user:[4026532740]   uid=999
== 2. interfaces and addresses ==
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
tap0             UNKNOWN        52:6d:2f:a4:1c:c0 <BROADCAST,UP,LOWER_UP>
lo               UNKNOWN        127.0.0.1/8
tap0             UNKNOWN        10.0.2.100/24
== 3. routing table ==
default via 10.0.2.2 dev tap0
10.0.2.0/24 dev tap0 proto kernel scope link src 10.0.2.100
== 4. what kind of interface is each one? ==
  lo: loopback  mtu=65536
  tap0: tun/tap: a program on the host holds the other end  mtu=65520
== 5. packet counters (/proc/net/dev) ==
  lo rx_packets=0 tx_packets=0
  tap0 rx_packets=1 tx_packets=3
== 6. may an ordinary user create a NEW network namespace? ==
  unshare -n : denied -> unshare failed: Operation not permitted
  unshare -rn: allowed (via a user namespace)
  inside: net:[4026532824]
lo               DOWN           00:00:00:00:00:00 <LOOPBACK>
  veth pair created:
v-ctr@v-host     DOWN           fa:26:ae:36:0e:50 <BROADCAST,MULTICAST,M-DOWN>
v-host@v-ctr     DOWN           8e:f2:37:17:c4:32 <BROADCAST,MULTICAST,M-DOWN>

৬ · Docker-এর নেটওয়ার্ক mode আর -p 8080:80-এর আসল পথ

Docker একটি container চালানোর সময় তার নেটওয়ার্ক কয়েক রকম হতে পারে (--network দিয়ে বাছা হয়):

ডিফল্ট bridge-এ container পায় 172.17.0.0/16-এর একটি ঠিকানা — যা বাইরের কেউ দেখে না। তাহলে container-এর ভেতরের ওয়েব সার্ভারে পৌঁছানো যায় কীভাবে? docker run -p 8080:80 nginx লিখলে Docker host-এর netfilter-এ (iptables বা নতুন সংস্করণে কখনো nftables) একটি DNAT নিয়ম বসায়: “host-এর TCP 8080-এ যা আসবে, গন্তব্য বদলে 172.17.0.2:80”. এটি পর্ব ১৯-এর port forwarding, শুধু router-এর জায়গায় আপনার নিজের যন্ত্র। একে Docker-এর ভাষায় বলে port publishing.

$ docker run -d --name web -p 8080:80 nginx
$ sudo iptables -t nat -S DOCKER
-N DOCKER
-A DOCKER -i docker0 -j RETURN
-A DOCKER ! -i docker0 -p tcp -m tcp --dport 8080 -j DNAT --to-destination 172.17.0.2:80
$ sudo iptables -t nat -S POSTROUTING | grep 172.17
-A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE
$ ip -br link | grep -E 'docker0|veth'
docker0          UP             02:42:5e:1a:7c:01 <BROADCAST,MULTICAST,UP,LOWER_UP>
veth3f2a1b9@if2  UP             9a:51:0c:3e:22:7d <BROADCAST,MULTICAST,UP,LOWER_UP>

নাম দিয়ে খোঁজা — user-defined bridge আর embedded DNS

ডিফল্ট docker0-এ container-রা একে অপরকে শুধু IP দিয়ে চেনে। কিন্তু নিজে একটি নেটওয়ার্ক বানালে (docker network create shop) আর দুটি container তাতে রাখলে, একটি অন্যটিকে নাম দিয়ে ডাকতে পারে — db:5432. কারণ user-defined নেটওয়ার্কে Docker প্রতিটি container-এ একটি ছোট embedded DNS সার্ভার দেয় (সাধারণত 127.0.0.11-এ), যা container-এর নামকে তার বর্তমান IP-তে রূপান্তর করে, আর বাকি নাম বাইরের resolver-এ পাঠায়। এই নেটওয়ার্কের container-রা নিজেদের মধ্যে সরাসরি bridge দিয়ে কথা বলে — NAT ছাড়া, port publish ছাড়া; বাইরের দুনিয়া থেকে শুধু publish করা port দেখা যায়। আলাদা দুটি user-defined নেটওয়ার্কের container-রা ডিফল্টভাবে একে অপরকে দেখে না — একটি সহজ বিভাজন। (খুঁটিনাটি Docker সংস্করণ ভেদে বদলায়; DNS নিয়ে বিস্তারিত পর্ব ৩৫-এ।)

৭ · Kubernetes-এর নেটওয়ার্ক মডেল — Pod, CNI আর Service

একটি যন্ত্রে Docker যথেষ্ট। কিন্তু শত শত যন্ত্রে হাজারো container চালাতে, নষ্ট হলে আবার চালু করতে, চাপ বাড়লে সংখ্যা বাড়াতে লাগে একটি orchestrator — আজ সবচেয়ে প্রচলিত Kubernetes (Google-এর ভেতরের Borg ব্যবস্থার অভিজ্ঞতা থেকে, ২০১৪ সালে উন্মুক্ত হয়)। এর ক্ষুদ্রতম একক Pod: এক বা একাধিক container, যারা একটি network namespace ভাগ করে — তাই একই Pod-এর container-রা একে অপরকে localhost-এ পায়।

তিনটি নিয়ম

Kubernetes নিজে নেটওয়ার্ক বানায় না; সে শুধু একটি মডেল দাবি করে:

1. প্রতিটি Pod-এর নিজের IP — Docker-এর মতো host-এর port ভাগাভাগি নয়। দুটি Pod একই port 8080 ব্যবহার করলেও কোনো সংঘাত নেই।
2. যেকোনো node-এর যেকোনো Pod অন্য যেকোনো Pod-এর সাথে NAT ছাড়া কথা বলে — প্রাপক যে উৎস-ঠিকানা দেখে, সেটি প্রেরক Pod-এর আসল ঠিকানা।
3. একটি node-এর এজেন্টরা (যেমন kubelet) সেই node-এর সব Pod-এ পৌঁছাতে পারে।

এই মডেল বাস্তবায়ন করে CNI (Container Network Interface) plugin: Pod তৈরির সময় kubelet-এর নির্দেশে container runtime plugin-কে ডাকে, plugin namespace-এ interface বসায়, ঠিকানা দেয়, route লেখে। প্রচলিত কয়েকটি (প্রতিটি অনেক mode-এ চলে; নিচে সবচেয়ে চেনা রূপ):

• Flannel: প্রতিটি node একটি Pod-subnet পায় (যেমন 10.244.1.0/24); অন্য node-এর Pod-এ যাওয়া packet VXLAN-এ মুড়ে node-এর ঠিকানায় পাঠানো হয় — সরল overlay.
• Calico: প্রায়ই overlay ছাড়াই — প্রতিটি node BGP দিয়ে অন্যদের জানায় “10.244.2.0/24 আমার কাছে”, আর underlay router-রা সরাসরি route করে। Underlay সেটা না মানলে IP-in-IP বা VXLAN-ও চালাতে পারে। NetworkPolicy প্রয়োগে বিশেষ জোর।
• Cilium: Linux kernel-এর eBPF দিয়ে packet-এর পথে ছোট প্রোগ্রাম বসিয়ে forwarding, load balancing আর নীতি প্রয়োগ — অনেক ক্ষেত্রে iptables-এর লম্বা নিয়ম-তালিকা এড়িয়ে।
• Cloud-এর নিজস্ব CNI: যেমন AWS-এর VPC CNI — Pod সরাসরি VPC-র ঠিকানা পায়, overlay লাগে না, তবে VPC-র ঠিকানা দ্রুত ফুরাতে পারে (অংশ ৪-এর পরিকল্পনা তখন আরও জরুরি)।

Service — বদলাতে থাকা Pod-এর সামনে একটি স্থির ঠিকানা

Pod মরে, নতুন জন্মায়, ঠিকানা বদলায়। তাই অন্যরা সরাসরি Pod-এর IP-তে নির্ভর করতে পারে না। Service একটি স্থির নাম আর ঠিকানা দেয়, আর label দিয়ে ঠিক করে পেছনের কোন Pod-গুলো এর “endpoint”. তিন ধরন:

• ClusterIP (ডিফল্ট): cluster-এর ভেতরে একটি virtual ঠিকানা, যেমন 10.96.0.20. প্রচলিত iptables mode-এ কোনো interface-এ এই ঠিকানা বসানো নেই, কেউ ping-এর উত্তর দেয় না — এটি শুধু নিয়মে আছে (IPVS mode-এ ঠিকানাটি একটি dummy interface-এ বসানো থাকে, তাই সেখানে ping-এর উত্তর আসতে পারে)।
• NodePort: প্রতিটি node-এর একটি port (ডিফল্ট পরিসর 30000–32767) খুলে দেয়, যা ClusterIP-তে পৌঁছায়।
• LoadBalancer: cloud-এ চললে প্রদানকারীর একটি load balancer চেয়ে নেয়, যা NodePort বা সরাসরি Pod-এ ট্রাফিক পাঠায়।

ClusterIP-কে “জীবন্ত” করে kube-proxy — প্রতিটি node-এ চলে, Service আর endpoint-এর তালিকা দেখে, আর node-এর netfilter-এ নিয়ম লেখে: “গন্তব্য 10.96.0.20:80 হলে এই endpoint-গুলোর যেকোনো একটিতে DNAT হবে”. প্রচলিত iptables mode-এ বাছাই হয় এলোমেলোভাবে (random); IPVS mode-এ round robin-সহ কয়েকটি algorithm থাকে; নতুন সংস্করণে nftables mode-ও এসেছে। Cilium-এর মতো plugin kube-proxy-কে পুরো বাদ দিয়ে eBPF দিয়ে একই কাজ করতে পারে। নিচের stepper দেখায় এক node-এর Pod থেকে আরেক node-এর Pod-এ Service-এর মাধ্যমে একটি packet-এর যাত্রা (Flannel-ধাঁচের VXLAN overlay ধরে)।

এলোমেলো বাছাই আসলে সমান ভাগ — একটি ছোট প্রমাণ

iptables-এ “n-টির যেকোনো একটি সমান সম্ভাবনায় বাছাই” সরাসরি লেখা যায় না; লেখা যায় শুধু “এই নিয়ম p সম্ভাবনায় মেলে”. তাই kube-proxy n-টি endpoint-এর জন্য ক্রমানুসারে নিয়ম লেখে, যেখানে i-তম নিয়ম (i = ০, ১, …, n − ১) মেলে সম্ভাবনা 1/(n − i)-তে, আর শেষটি নিশ্চিতভাবে (1/1). Endpoint k বাছাই হতে হলে আগের k-টি নিয়ম না মিলে k-তমটি মিলতে হবে:

তিনটি endpoint-এ তাই নিয়ম তিনটির সম্ভাবনা ০.৩৩৩, ০.৫, ১. খেয়াল করুন এই বাছাই হয় প্রতিটি নতুন সংযোগের প্রথম packet-এ; পরের packet-গুলো conntrack-এর সারি অনুসরণ করে। তাই একটি দীর্ঘ HTTP/2 বা gRPC সংযোগ সবসময় একটি Pod-এই আটকে থাকে — L4 load balancing-এর একটি পরিচিত সীমা।

৮ · নাম, L7 আর নিয়ম — CoreDNS, Ingress আর NetworkPolicy

CoreDNS আর Service-এর নাম

Cluster-এর ভেতরে DNS চালায় CoreDNS (নিজেও একটি Service-এর পেছনে কয়েকটি Pod). প্রতিটি Service একটি নাম পায়: <service>.<namespace>.svc.cluster.local — যেমন api.shop.svc.cluster.local (শেষের cluster.local ডিফল্ট, বদলানো যায়)। Pod-এর /etc/resolv.conf-এ CoreDNS-এর ClusterIP আর কয়েকটি search domain বসানো থাকে, তাই একই namespace থেকে শুধু api আর অন্য namespace থেকে api.shop লিখলেই চলে। (search domain অনেক হওয়ায় বাইরের নাম খুঁজতে কয়েকটি বাড়তি প্রশ্ন যায় — ndots সেটিংয়ের পরিচিত একটি পারফরম্যান্স-বিষয়। DNS-এর ভিত্তি পর্ব ৩৫-এ।)

L7-এর দরজা — Ingress আর Gateway API

ClusterIP আর NodePort হলো L4: শুধু ঠিকানা আর port দেখে। কিন্তু একই public ঠিকানায় shop.example.com/api এক Service-এ আর /images আরেকটিতে পাঠাতে, TLS শেষ করতে, header দেখে সিদ্ধান্ত নিতে লাগে একটি L7 reverse proxy. Kubernetes-এ এর জন্য Ingress resource আর একটি Ingress controller (যেমন NGINX-ভিত্তিক বা Envoy-ভিত্তিক) ব্যবহার হতো; নতুন এবং আরও সমৃদ্ধ মান Gateway API, যেখানে কাঠামো বসানো (Gateway) আর route লেখা (HTTPRoute) আলাদা দলের হাতে রাখা যায়। L7 load balancing-এর ভেতরের কথা পর্ব ৫২-এ।

NetworkPolicy — Pod-এর firewall, আর সবচেয়ে প্রচলিত ফাঁদ

ডিফল্টভাবে Kubernetes-এ সব Pod সব Pod-এর সাথে কথা বলতে পারে — একটি সমতল নেটওয়ার্ক। NetworkPolicy label দিয়ে নিয়ম বসায়। নিয়মটা মনে রাখার মতো:

ফাঁদটা হলো: “db-তে শুধু api ঢুকুক” লিখে কেউ ভাবেন বাকি সব আগের মতো আছে — অথচ db-র monitoring agent, backup job সবাই এখন আটকে গেল। উল্টো ফাঁদ: কোনো policy না লিখে ভাবা “Kubernetes নিরাপদ”. আরেকটি বিষয়: NetworkPolicy প্রয়োগ করে CNI plugin; যে plugin সমর্থন করে না (যেমন শুধু Flannel), সেখানে policy লিখলেও কোনো প্রভাব পড়ে না — কোনো ত্রুটিও দেখায় না।

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-from-api
  namespace: shop
spec:
  podSelector:
    matchLabels:
      app: db            # এই Pod-গুলো এখন "selected"
  policyTypes: ["Ingress"]
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: api       # একই namespace-এর api Pod-গুলো
    ports:
    - protocol: TCP
      port: 5432

নিচের simulator দুটি অংশে: প্রথমে kube-proxy-র iptables-ধাঁচের ClusterIP — তিনটি endpoint, ৩০০টি নতুন সংযোগ, তারপর একটি Pod readiness পরীক্ষায় ব্যর্থ হয়ে endpoint-তালিকা থেকে বাদ; দ্বিতীয়ত উপরের YAML-এর মতো একটি policy দিয়ে চারটি সংযোগের সিদ্ধান্ত। এলোমেলো সংখ্যা একটি নির্দিষ্ট seed থেকে, তাই প্রতিবার একই ফল।

// kube-proxy (iptables mode) style ClusterIP DNAT + a NetworkPolicy check. Seeded => same output every run.
let seed = 54; const rnd = () => (seed = (seed * 16807) % 2147483647) / 2147483647;   // Park-Miller
const svc = { name: "api", vip: "10.96.0.20:80", eps: [
  { ip: "10.244.1.5:8080", node: "A", ready: true }, { ip: "10.244.2.7:8080", node: "B", ready: true },
  { ip: "10.244.2.8:8080", node: "B", ready: true }] };
function rules() {                       // rule i matches with probability 1/(n-i): uniform overall
  const ready = svc.eps.filter(e => e.ready);
  return ready.map((e, i) => ({ to: e.ip, p: 1 / (ready.length - i) }));
}
function connect(k) {                    // only the FIRST packet of a connection walks the rules
  const R = rules(), counts = Object.fromEntries(R.map(r => [r.to, 0]));
  console.log(`rules for ${svc.vip}: ` + R.map(r => `${r.to} p=${r.p.toFixed(3)}`).join(" | "));
  for (let c = 0; c < k; c++) { const hit = R.find(r => rnd() < r.p); counts[hit.to]++; }
  console.log(`  ${k} new connections -> DNAT:`, JSON.stringify(counts));
}
connect(300);
svc.eps[1].ready = false;                // readiness probe fails: endpoint leaves the EndpointSlice
console.log("pod 10.244.2.7 not ready -> removed from endpoints, rules rewritten");
connect(300);
// NetworkPolicy: once a pod is selected by a policy for Ingress, everything not listed is denied.
const pods = { web: { app: "web" }, api: { app: "api" }, db: { app: "db" } };
const policies = [{ name: "db-from-api", select: { app: "db" }, from: { app: "api" }, port: 5432 }];
const match = (sel, labels) => Object.entries(sel).every(([k, v]) => labels[k] === v);
function ingress(src, dst, port) {
  const sel = policies.filter(p => match(p.select, pods[dst]));
  if (!sel.length) return console.log(`${src} -> ${dst}:${port}  ALLOW (no policy selects ${dst}: default allow)`);
  const ok = sel.find(p => match(p.from, pods[src]) && p.port === port);
  console.log(`${src} -> ${dst}:${port}  ${ok ? "ALLOW by " + ok.name : "DENY (" + dst + " is selected; nothing allows this)"}`);
}
console.log("");
ingress("api", "db", 5432); ingress("web", "db", 5432); ingress("api", "db", 22); ingress("web", "api", 8080);

rules for 10.96.0.20:80: 10.244.1.5:8080 p=0.333 | 10.244.2.7:8080 p=0.500 | 10.244.2.8:8080 p=1.000
  300 new connections -> DNAT: {"10.244.1.5:8080":106,"10.244.2.7:8080":97,"10.244.2.8:8080":97}
pod 10.244.2.7 not ready -> removed from endpoints, rules rewritten
rules for 10.96.0.20:80: 10.244.1.5:8080 p=0.500 | 10.244.2.8:8080 p=1.000
  300 new connections -> DNAT: {"10.244.1.5:8080":149,"10.244.2.8:8080":151}

api -> db:5432  ALLOW by db-from-api
web -> db:5432  DENY (db is selected; nothing allows this)
api -> db:22  DENY (db is selected; nothing allows this)
web -> api:8080  ALLOW (no policy selects api: default allow)

৯ · Service mesh, overlay-এর MTU আর সমস্যা খোঁজা

Service mesh — প্রতিটি Pod-এর পাশে একজন দারোয়ান

Microservice-এ শত শত সেবা একে অপরকে ডাকে। প্রতিটির কোডে retry, timeout, এনক্রিপশন আর মাপজোখ আলাদা করে লেখা কঠিন। Service mesh এগুলো কোডের বাইরে আনে: প্রতিটি Pod-এ একটি sidecar proxy (প্রায়ই Envoy) বসানো হয়, আর Pod-এর সব ট্রাফিক netfilter-এর নিয়মে সেই proxy-র মধ্য দিয়ে যায়। দুই proxy নিজেদের মধ্যে mTLS চালায় (পর্ব ৪৮) — প্রতিটি সেবা certificate দেখিয়ে নিজের পরিচয় প্রমাণ করে, আর ট্রাফিক এনক্রিপ্টেড থাকে, এমনকি ভেতরের নেটওয়ার্কেও। নীতিও লেখা যায় সেবার পরিচয় দিয়ে: “শুধু orders সেবা payments-কে ডাকতে পারবে”. Istio আর Linkerd সবচেয়ে পরিচিত। দাম: প্রতিটি Pod-এ বাড়তি memory আর CPU, প্রতিটি অনুরোধে দুটি বাড়তি proxy-ধাপ, আর পরিচালনার জটিলতা। এজন্য সম্প্রতি sidecar ছাড়া নকশা এসেছে — যেমন Istio-র “ambient” mode, যেখানে প্রতিটি node-এ একটি ভাগ করা L4 proxy আর দরকার হলে আলাদা L7 proxy থাকে; এর পরিপক্বতা আর খুঁটিনাটি সংস্করণভেদে বদলাচ্ছে।

Overlay-এর MTU — চুপচাপ হারিয়ে যাওয়া বড় packet

অংশ ৭-এর stepper-এ দেখেছেন, VXLAN প্রতিটি packet-এ ৫০ byte যোগ করে: ভেতরের Ethernet header ১৪ + VXLAN ৮ + UDP ৮ + বাইরের IPv4 ২০ = ৫০ (পর্ব ১৩)। Underlay-এর MTU যদি ১,৫০০ হয়, তবে ভেতরের IP packet সর্বোচ্চ ১,৫০০ − ৫০ = ১,৪৫০ byte হতে পারে — এজন্যই Flannel-এর মতো VXLAN overlay-এ Pod-এর MTU সাধারণত ১,৪৫০. Underlay IPv6 হলে বাইরের header ৪০ byte, মোট ৭০, Pod-এর MTU ১,৪৩০. Pod-এর MTU ভুল করে ১,৫০০ থাকলে কী হয়? ছোট packet (ping, DNS, TCP handshake) দিব্যি চলে, কিন্তু বড় packet মোড়কের পর ১,৫৫০ হয়ে underlay-এ আটকায়। DF bit থাকলে ICMP “fragmentation needed” ফেরার কথা — কিন্তু সেটি কোনো firewall বা security group আটকালে প্রেরক কিছুই জানে না: সংযোগ খোলে, তারপর বড় response-এ ঝুলে থাকে। এই “PMTUD black hole”-এর গল্প পর্ব ৪৯-এর VPN অংশেও দেখেছেন। অনেক cloud-এ VPC-র ভেতরে jumbo frame (প্রায় ৯,০০০ byte MTU) চলে, যা overlay-এর চাপ কমায় — কিন্তু VPN বা ইন্টারনেটের দিকে গেলে আবার ছোট MTU.

সমস্যা খোঁজা — স্তর ধরে ধরে

“Pod থেকে api-তে যাওয়া যাচ্ছে না” — অনুমান না করে নিচ থেকে ওপরে উঠুন: নাম ঠিক হচ্ছে কি না, Service-এর পেছনে ready endpoint আছে কি না, সরাসরি Pod IP-তে যায় কি না, policy আটকাচ্ছে কি না, বড় packet-এ আটকায় কি না। পুরো পদ্ধতিগত তদন্ত পর্ব ৫৫-এ।

# ১. নাম ঠিক হচ্ছে? (Pod-এর ভেতর থেকে; image-এ nslookup থাকতে হবে)
$ kubectl -n shop exec deploy/web -- nslookup api
Server:    10.96.0.10
Address:   10.96.0.10:53

Name:    api.shop.svc.cluster.local
Address: 10.96.0.20

# ২. Service-এর পেছনে ready endpoint আছে? খালি হলে label বা readiness-এর সমস্যা
$ kubectl -n shop get endpointslices -l kubernetes.io/service-name=api
NAME        ADDRESSTYPE   PORTS   ENDPOINTS                AGE
api-7xk2p   IPv4          8080    10.244.1.5,10.244.2.8    3d

# ৩. Service বাদ দিয়ে সরাসরি Pod IP-তে (image-এ wget থাকলে)
$ kubectl -n shop exec deploy/web -- wget -qO- -T 3 http://10.244.2.8:8080/healthz
ok

# ৪. কোন policy এই namespace-এ আছে?
$ kubectl -n shop get networkpolicy

১০ · AI-এর যুগে cloud আর container নেটওয়ার্কিং

Terraform-এর VPC, Docker Compose-এর নেটওয়ার্ক, Kubernetes-এর YAML — AI মুহূর্তেই লিখে দেয়, আর দেখতে নিখুঁত লাগে। কিন্তু cloud-এ একটি ভুল নিয়ম মানে সরাসরি ইন্টারনেটে খোলা ডেটাবেস, আর একটি ভুল CIDR মানে মাস কয়েক পরে peering-এর অসম্ভব জট। চেনা ভুলগুলো:

AI-এর নেটওয়ার্ক-নকশা প্রয়োগের আগে — চেকলিস্ট

• প্রতিটি CIDR আর subnet-এর হিসাব নিজে মিলিয়েছি, আর অফিস, অন্য VPC, Pod ও Service CIDR-এর সাথে overlap নেই
• কোনো security group-এ ডেটাবেস, SSH বা admin port 0.0.0.0/0-এর জন্য খোলা নেই
• NACL-এ ফিরতি ট্রাফিকের (ephemeral port) নিয়ম আছে, আর NetworkPolicy বসানোর পর অনুমোদিত ও নিষিদ্ধ দুই রকম সংযোগই পরীক্ষা করেছি
• নাম আর ডিফল্ট আমার প্রদানকারী, Docker আর Kubernetes সংস্করণের অফিসিয়াল ডকুমেন্টেশনের সাথে মিলিয়েছি
• আগে আলাদা test অ্যাকাউন্ট বা namespace-এ চালিয়েছি, flow log বা packet capture দিয়ে ফল দেখেছি, আর খরচের (NAT gateway, public IP) হিসাব নিয়েছি