Route table, internet gateway আর NAT — packet কোন পথে যায়

১ · Route table — ডাকঘরের সর্টিং টেবিল

পর্ব ২৫-এ আপনি ঠিকানার নকশা দেখেছেন: VPC, subnet আর CIDR. কিন্তু ঠিকানা থাকলেই চিঠি পৌঁছায় না। কেউ একজনকে বলতে হয় চিঠিটি কোন পথে যাবে। Cloud-এ এই কাজটি করে route table.

Table-এর প্রতিটি সারিকে route বলে। Route-এর দুটি অংশ: destination (গন্তব্যের CIDR) আর target (packet যেখানে যাবে)। নিচে একটি private subnet-এর table:

Destination        Target        মানে
10.0.0.0/16        local         VPC-র ভেতরে, সরাসরি
0.0.0.0/0          nat-a         বাকি সব, NAT gateway হয়ে

প্রথম সারিটি local route. প্রতিটি table-এ VPC-র নিজের CIDR-এর জন্য এটি নিজে থেকেই থাকে। এর ফলে VPC-র ভেতরের সব subnet একে অপরের কাছে পৌঁছাতে পারে। সাধারণত এটি মোছা যায় না। “পৌঁছাতে পারা” মানে অবশ্য “অনুমতি আছে” নয়। অনুমতির কাজ security group-এর, যা পর্ব ২৭-এ আসবে।

দ্বিতীয় সারিটি default route. 0.0.0.0/0 মানে “সব ঠিকানা”। অন্য কোনো সারি না মিললে packet এই পথে যায়। ডাকঘরের “বাকি সব” বস্তার মতো।

Subnet আর table-এর সম্পর্ক

প্রতিটি subnet একসময়ে ঠিক একটি table-এর সাথে যুক্ত থাকে। এই সংযোগকে association বলে। একটি table অনেক subnet ব্যবহার করতে পারে। যে subnet-কে আপনি কোনো table-এ যুক্ত করেননি, সে পড়ে যায় main route table-এ। এই নীরব আচরণ থেকেই অনেক ভুল জন্মায়, যা অংশ ৮-এ দেখবেন।

Instance নিজে route table পড়ে না। তার OS শুধু জানে “বাইরের সব কিছু subnet-এর router ঠিকানায় যাবে”, যেমন 10.0.11.1, মানে subnet-এর শুরুর ঠিকানা + ১. এই ঠিকানায় আছে একটি virtual router. আসল সিদ্ধান্ত নেয় cloud-এর network, table দেখে। তাই VM-এর ভেতরে ip route চালিয়ে cloud-এর table দেখা যায় না। ip route কীভাবে পড়তে হয়, তা পর্ব ১৩-এ আছে।

Target কত রকম

Target মুছে গেলে route থেকে যায়, কিন্তু কোথাও পৌঁছায় না। একে blackhole route বলে। AWS-এর console-এ এমন route-এর পাশে blackhole লেখা দেখা যায়।

২ · Longest-prefix match — সবচেয়ে নির্দিষ্ট পথ জেতে

একটি ঠিকানা একাধিক সারিতে মিলতে পারে। 0.0.0.0/0 তো সব ঠিকানাতেই মেলে। তাহলে কোনটি জিতবে? নিয়মটি একটিই: longest-prefix match. যে সারির prefix সবচেয়ে লম্বা, অর্থাৎ /-এর পরের সংখ্যা সবচেয়ে বড়, সেটিই জেতে।

মেলানোর হিসাবটি সহজ। ধরুন গন্তব্য 10.1.5.9 আর সারি 10.1.0.0/16. /16 মানে প্রথম ১৬ bit তুলনা করতে হবে, অর্থাৎ প্রথম দুটি সংখ্যা। 10.1 আর 10.1 সমান, তাই মিলেছে। 10.1.5.0/24-এর প্রথম ২৪ bit, অর্থাৎ 10.1.5-ও মেলে। ২৪ বড়, তাই /24 জিতবে।

Prefix দৈর্ঘ্য ৮-এর গুণিতক না হলে bit দেখতে হয়। 10.0.4.0/22-এর তৃতীয় সংখ্যা 4, বাইনারিতে 00000100. /22 মানে তৃতীয় সংখ্যার প্রথম ৬ bit স্থির, তাই 4 থেকে 7 পর্যন্ত সবই এর ভেতরে। CIDR-এর পুরো হিসাব Subnetting পর্বে আছে।

নিচের সিমুলেটরে table-এর সারিগুলো ইচ্ছে করে এলোমেলো রাখা হয়েছে। প্রতিটি গন্তব্যের জন্য কোড সব সারি দেখে, আর যত সারি মেলে তার মধ্যে সবচেয়ে লম্বা prefix রাখে। Table আর গন্তব্য বদলে নিজে পরীক্ষা করুন।

// One route table. Most specific matching prefix wins; order does not matter.
const table = [
  ["0.0.0.0/0",       "nat-a"],     // default route
  ["10.0.0.0/16",     "local"],
  ["10.1.0.0/16",     "peering-1"],
  ["10.1.5.0/24",     "vpn-1"],
  ["198.51.100.0/24", "storage-endpoint"],
];
const toInt = ip => ip.split(".").reduce((n, b) => n * 256 + Number(b), 0);
const maskOf = len => (len === 0 ? 0 : (0xFFFFFFFF << (32 - len)) >>> 0);

function lookup(dst) {
  const ip = toInt(dst);
  let best = null;
  for (const [cidr, target] of table) {
    const [net, lenText] = cidr.split("/");
    const len = Number(lenText), mask = maskOf(len);
    const same = ((ip & mask) >>> 0) === ((toInt(net) & mask) >>> 0);
    if (same && (!best || len > best.len)) best = { cidr, target, len };
  }
  return best;
}

const dests = ["10.0.11.20", "10.1.5.9", "10.1.9.9", "10.2.0.1",
               "198.51.100.80", "198.51.101.80", "203.0.113.50"];
for (const d of dests) {
  const r = lookup(d);
  console.log(d.padEnd(15) + r.cidr.padEnd(17) + "-> " + r.target);
}

একই prefix দুবার থাকলে কী হয়? এটি provider-ভেদে আলাদা। Azure-এর নথিতে আগে longest-prefix, তারপর নিজের দেওয়া route, তারপর BGP, শেষে system route. Google Cloud-এ route-এর priority নম্বর আছে। AWS-এ static route সাধারণত শেখা route-এর আগে আসে। মূল কথা, prefix-এর দৈর্ঘ্য সবার আগে দেখা হয়।

৩ · Internet gateway — আর public subnet-এর আসল সংজ্ঞা

Internet gateway (সংক্ষেপে IGW) হলো VPC আর ইন্টারনেটের মাঝের দরজা। এটি কোনো একটি VM নয়, আর একটি AZ-এর জিনিসও নয়। Provider এটি নিজে চালান, আপনি শুধু VPC-র সাথে যুক্ত করেন। আপনার দিক থেকে এর ক্ষমতা বাড়ানোর কিছু নেই।

IGW দুটি কাজ করে। এক, route table-এর target হিসেবে ইন্টারনেটের দিকে পথ দেয়। দুই, IPv4-এর জন্য 1:1 ঠিকানা অনুবাদ করে। এখানেই বেশিরভাগ নতুন শিক্ষার্থীর ভুল ধারণা ভাঙে।

নিচের ধাপগুলোতে একটি public instance web-1-এর packet দেখুন। “পরে” চাপলে টেবিলের source আর destination বদলাবে।

Public subnet কাকে বলে

এবার সংজ্ঞাটি পরিষ্কার। Public subnet কোনো বিশেষ ধরনের subnet নয়। Console-এ এমন কোনো টিক-বক্স নেই। একটি subnet public, যদি তার route table-এ IGW-র দিকে route থাকে। Route না থাকলে সেটি private subnet. পার্থক্যটি পুরোপুরি একটি table-এর একটি সারির।

কিন্তু route একা যথেষ্ট নয়। সরাসরি ইন্টারনেটে কথা বলতে একটি instance-এর তিনটি জিনিস লাগে:

• Subnet-এর table-এ 0.0.0.0/0 → igw আছে
• Instance-এর একটি public IP বা static public IP আছে
• Firewall নিয়ম সেই traffic-কে অনুমতি দেয় (পর্ব ২৭)

৪ · NAT gateway — ভেতর থেকে বাইরে, উল্টো দিকে নয়

Database আর app server-কে ইন্টারনেট থেকে দেখা যাওয়া উচিত নয়, তাই এগুলো থাকে private subnet-এ। কিন্তু এদেরও বাইরে যেতে হয়: security patch নামাতে, package আনতে, বাইরের payment API ডাকতে। দরকার এমন একটি পথ, যেটি শুধু একদিকে খোলা। সেটিই NAT gateway.

NAT-এর তত্ত্ব, port ব্যবহার করে অনেক ঠিকানাকে একটিতে আনার কৌশল আর খাতার গঠন Computer Networks কোর্সের NAT পর্বে বিস্তারিত আছে। এখানে দেখব cloud-এ এটি কীভাবে বসে। NAT gateway-র নিজের একটি private ঠিকানা আর একটি static public IP থাকে। এটি বসে public subnet-এ। Private subnet-এর table-এর default route একে দেখায়।

নিচের ধাপগুলো এই পর্বের কেন্দ্র। app-1 একটি apt mirror-এ যাচ্ছে। প্রতিটি ধাপে source বদলানো খেয়াল করুন। AWS-এর নথি অনুযায়ী এখানে অনুবাদ হয় দুবার: NAT-এ, তারপর IGW-তে।

NAT-এর একটি বাস্তব সীমাও আছে। এক public ঠিকানার port সংখ্যা সীমিত। একই destination ঠিকানা, port আর protocol-এ বহু সংযোগ খুললে port ফুরিয়ে যেতে পারে, একে port exhaustion বলে। AWS-এর নথিতে প্রতি public IP-তে একই destination-এর জন্য প্রায় ৫৫,০০০ সংযোগের কথা আছে, লেখার সময়ে। সমাধান: বেশি public IP যোগ করা, connection pool ব্যবহার, বা destination ভাগ করা।

৫ · প্রতি AZ-এ NAT, NAT instance আর IPv6-এর পথ

একটি NAT কেন যথেষ্ট নয়

AWS ও Azure-এর সাধারণ NAT gateway একটি নির্দিষ্ট availability zone-এর ভেতরে থাকে। সেই AZ-এ বড় সমস্যা হলে NAT-ও যায়। ধরুন আপনার একটিই NAT, AZ-a-তে, আর সব private subnet তাকেই দেখায়। AZ-a পড়ে গেলে AZ-b-র সুস্থ server-গুলোও বাইরে যেতে পারবে না। আপনি দুই AZ-এ server রেখে যে সুরক্ষা কিনলেন, একটি NAT তা নষ্ট করে দিল। NAT তখন একটি লুকানো single point of failure হয়ে গেল।

আরেকটি দাম আছে। AZ-b থেকে AZ-a-র NAT-এ যাওয়া প্রতি GB traffic-এ data transfer খরচ হতে পারে। তাই সাধারণ নকশা: প্রতি AZ-এ একটি NAT, আর প্রতি AZ-এর private subnet-এর জন্য আলাদা route table, ঠিক ছবি ২৬.১-এর মতো। এক AZ-এর NAT গেলে শুধু সেই AZ-এর outbound যায়, আর সেই AZ-এর server-ও তখন সমস্যায়। ব্যর্থতার সীমা AZ-এর ভেতরেই থাকে।

NAT instance বনাম managed NAT

Managed সার্ভিসের আগে মানুষ একটি Linux VM-কেই NAT বানাতেন: IP forwarding চালু, iptables-এ masquerade, আর AWS-এ source/destination check বন্ধ। এখনো এটি সম্ভব, একে NAT instance বলে।

IPv6: অনুবাদের দরকার নেই, দরজা এখনো দরকার

IPv6-এ ঠিকানার অভাব নেই, তাই instance সরাসরি বিশ্বজুড়ে অনন্য ঠিকানা পায়। NAT-এর মূল কারণটিই তখন নেই। কিন্তু private server-কে ইন্টারনেট থেকে আড়াল করার প্রয়োজন তো থাকে। AWS-এ এই কাজ করে egress-only internet gateway: ভেতর থেকে শুরু হওয়া সংযোগ যেতে দেয়, বাইরে থেকে শুরু হওয়া সংযোগ আটকায়। ঠিকানা বদলায় না। Route দেখতে হয় এরকম: ::/0 → eigw. অন্য provider-এ একই ফল সাধারণত firewall নিয়ম দিয়ে আসে। IPv6-এর ঠিকানা-গঠন IPv6 পর্বে পাবেন।

৬ · NAT-এর বিল — ঘণ্টা, প্রতি GB আর storage endpoint

NAT gateway-র বিল অনেক দলকে অবাক করে। কারণ এর খরচ দুই ভাগে: চালু থাকার ঘণ্টা, আর ভেতর দিয়ে যাওয়া প্রতি GB. দ্বিতীয়টির নাম data processing charge. এটি egress-এর ওপরে আলাদা করে বসে, আর সাধারণত দুই দিকের ডেটাতেই লাগে।

সবচেয়ে সাধারণ অপচয় হলো একই region-এর object storage-এ যাওয়া ডেটা। Private server একটি bucket থেকে backup টানছে, আর প্রতিটি GB NAT পার হচ্ছে, অথচ গন্তব্য একই region-এর ভেতরে। এখানে gateway endpoint কাজে লাগে। এটি route table-এ storage সার্ভিসের ঠিকানা-তালিকার জন্য একটি বেশি নির্দিষ্ট route বসায়। Longest-prefix match-এর জোরে storage-এর traffic NAT এড়িয়ে যায়, default route অক্ষত থাকে। Endpoint-এর ধরন আর নিরাপত্তা পর্ব ২৮-এ আসবে।

নিচের হিসাবে সব দর অনুমিত: NAT ঘণ্টায় $০.০৫, প্রতি GB $০.০৫, ইন্টারনেট egress প্রতি GB $০.০৯, AZ পার হলে প্রতি GB $০.০২. আরও ধরে নিচ্ছি, gateway endpoint বিনা খরচে আর একই region-এর storage-এ transfer খরচ নেই। এগুলো AWS-এর gateway endpoint-এর লেখার সময়ের আচরণের সাথে মেলে, কিন্তু আপনার provider-এর pricing পাতা দেখে নিন।

// All prices are ASSUMED round numbers. Check your provider's pricing page.
const P = { natHour: 0.05, natPerGB: 0.05, egressPerGB: 0.09, crossAzPerGB: 0.02 };
const HOURS = 720;              // 30-day month
const storageGB = 9000;         // private servers <-> object storage, same region
const internetGB = 3000;        // private servers <-> public internet

function month({ nats, endpoint, otherAzShare }) {
  const viaNat = internetGB + (endpoint ? 0 : storageGB);
  const hourly  = nats * P.natHour * HOURS;
  const process = viaNat * P.natPerGB;
  const egress  = internetGB * P.egressPerGB;
  const crossAz = viaNat * otherAzShare * P.crossAzPerGB;
  const total = hourly + process + egress + crossAz;
  return { viaNat, hourly, process, egress, crossAz, total };
}

const plans = [
  ["2 NAT, no endpoint", { nats: 2, endpoint: false, otherAzShare: 0 }],
  ["2 NAT, endpoint",    { nats: 2, endpoint: true,  otherAzShare: 0 }],
  ["1 NAT, no endpoint", { nats: 1, endpoint: false, otherAzShare: 0.5 }],
  ["1 NAT, endpoint",    { nats: 1, endpoint: true,  otherAzShare: 0.5 }],
];
const f = x => x.toFixed(2).padStart(8);
console.log("plan                viaNAT    hour processing  egress crossAZ    total");
for (const [name, p] of plans) {
  const m = month(p);
  console.log(name.padEnd(19) + String(m.viaNat).padStart(6) + f(m.hourly) +
    f(m.process).padStart(11) + f(m.egress) + f(m.crossAz) + f(m.total));
}
const save = month(plans[0][1]).total - month(plans[1][1]).total;
console.log("endpoint saves per month with 2 NAT: $" + save.toFixed(2));

বিল কমানোর ক্রমটি মনে রাখুন: আগে দেখুন কোন গন্তব্য সবচেয়ে বেশি GB নিচ্ছে (flow log দিয়ে, অংশ ৯)। তারপর storage-এ endpoint, container image-এর জন্য একই region-এর registry, আর নিজের সার্ভিসগুলোর জন্য VPC-র ভেতরের পথ। শেষে অপ্রয়োজনীয় সংখ্যক NAT আছে কি না দেখুন। Cloud-এর বিলের বড় ছবি পর্ব ৭২-এ আসবে।

৭ · পথের উল্টো দিক — asymmetric path

এতক্ষণ যাওয়ার পথ দেখলাম। কিন্তু route table শুধু এক দিকের কথা বলে। উত্তরের packet-এর জন্য উল্টো দিকের table আলাদাভাবে কাজ করে। যাওয়া আর আসার পথ আলাদা হলে তাকে asymmetric path বলে।

Router-এর জন্য এটি সমস্যা নয়। ইন্টারনেটে এমন প্রায়ই হয়, কারণ router প্রতিটি packet আলাদাভাবে বিচার করে, কিছু মনে রাখে না। সমস্যা হয় যন্ত্রটি stateful হলে, অর্থাৎ যে নিজের খাতায় সংযোগ মনে রাখে: NAT আর firewall. যে পথে সংযোগ শুরু হয়নি, সেই পথের যন্ত্রের খাতায় সারিই নেই।

লক্ষণটি চেনা দরকার: একদিকের packet দেখা যায়, অন্যদিকের নয়, আর TCP handshake শেষ হয় না। সমাধানের নিয়ম সহজ: একটি সংযোগের দুই দিক একই stateful যন্ত্র দিয়ে যাবে। প্রথম উদাহরণে instance-কে সত্যিই public করতে চাইলে public subnet-এ আনুন। না চাইলে public IP সরিয়ে load balancer ব্যবহার করুন (পর্ব ১৮)।

৮ · পথের চারটি সাধারণ ভুল — আর সমস্যা খোঁজার ধারা

“Private server ইন্টারনেট পাচ্ছে না” এই অভিযোগের বেশিরভাগ উত্তর চারটি ঘরের মধ্যে পড়ে:

এই চিন্তাটিই একটি প্রোগ্রাম হিসেবে নিচে আছে। Path tracer instance থেকে শুরু করে subnet, table, NAT আর IGW পর্যন্ত এগোয়, আর প্রথম ভুলটিতে থেমে যায়। প্রকৃত reachability tool-ও মূলত এভাবেই configuration বিশ্লেষণ করে।

// Walk from an instance towards the internet. Return the first fault.
function trace(c) {
  const hops = [c.vm.name], stop = why => ({ hops, why });
  const tableOf = s => c.assoc[s] || "main";            // no link = main table
  const next = s => c.tables[tableOf(s)]["0.0.0.0/0"];
  hops.push(c.vm.subnet + ":" + tableOf(c.vm.subnet));
  const t1 = next(c.vm.subnet);
  if (!t1) return stop("NO DEFAULT ROUTE in table " + tableOf(c.vm.subnet));
  if (t1 === "igw") {
    hops.push("igw");
    return stop(c.vm.publicIp ? "OK" : "NO PUBLIC IP: igw has nothing to translate to");
  }
  const nat = c.nats[t1];
  if (!nat) return stop("BLACKHOLE: target " + t1 + " does not exist");
  hops.push(t1, nat.subnet + ":" + tableOf(nat.subnet));
  if (next(nat.subnet) !== "igw") return stop("NAT IN PRIVATE SUBNET: " + nat.subnet + " has no igw route");
  hops.push("igw"); return stop("OK");
}
const tables = { main: {}, "rt-pub": { "0.0.0.0/0": "igw" },
                 "rt-prv": { "0.0.0.0/0": "nat-a" }, "rt-old": { "0.0.0.0/0": "nat-x" } };
const base = { tables, nats: { "nat-a": { subnet: "pub-a" } },
               assoc: { "pub-a": "rt-pub", "app-a": "rt-prv" } };
const app = { name: "app-1", subnet: "app-a" }, web = { name: "web-1", subnet: "pub-a" };
const cases = [
  ["healthy private", { ...base, vm: app }],
  ["wrong table",     { ...base, vm: app, assoc: { "pub-a": "rt-pub" } }],
  ["old NAT deleted", { ...base, vm: app, assoc: { "pub-a": "rt-pub", "app-a": "rt-old" } }],
  ["NAT misplaced",   { ...base, vm: app, nats: { "nat-a": { subnet: "app-a" } } }],
  ["no public IP",    { ...base, vm: web }],
  ["healthy public",  { ...base, vm: { ...web, publicIp: "203.0.113.25" } }],
];
for (const [name, cfg] of cases) {
  const r = trace(cfg);
  console.log(name.padEnd(16) + r.why + "\n  path: " + r.hops.join(" > "));
}

একটি বাস্তব ঘটনা, ধাপে ধাপে

একটি কাল্পনিক অনলাইন বাজার অ্যাপের app-1-এ security patch দিতে গিয়ে apt-get update আটকে গেছে। নিচের ধাপগুলো সেই খোঁজ। সব আউটপুট নমুনা, version-ভেদে আলাদা হতে পারে, আর সব id কাল্পনিক।

$ sudo apt-get update
Err:1 https://mirror.example.com/ubuntu noble InRelease
  Could not connect to mirror.example.com:443
  (198.51.100.80), connection timed out

$ dig +short mirror.example.com
198.51.100.80
$ curl -sS -m 5 -o /dev/null https://mirror.example.com
curl: (28) Failed to connect to mirror.example.com
port 443 after 5001 ms: Timeout was reached

$ ip route
default via 10.0.11.1 dev ens5
10.0.11.0/24 dev ens5 proto kernel scope link src 10.0.11.20
# OS ঠিক আছে। বাকি সিদ্ধান্ত cloud-এর table-এ।

$ aws ec2 describe-route-tables \
    --filters Name=association.subnet-id,Values=subnet-0app \
    --query "RouteTables[].Routes[]" --output text
10.0.0.0/16   local      active
0.0.0.0/0     nat-0aaa   active

$ aws ec2 describe-nat-gateways --nat-gateway-ids nat-0aaa \
    --query "NatGateways[].[State,SubnetId]" --output text
available   subnet-0app
# NAT বসে আছে app-এর নিজের private subnet-এ!

10.0.11.20 198.51.100.80 49152 443 6 ... ACCEPT OK
# বাইরে যাওয়ার কোনো রেকর্ড নেই, ফিরতি রেকর্ডও নেই।
# ACCEPT মানে firewall আটকায়নি, পৌঁছেছে এমন নয়।

$ aws ec2 create-nat-gateway --subnet-id subnet-0pub \
    --allocation-id eipalloc-0bbb
$ aws ec2 replace-route --route-table-id rtb-0app \
    --destination-cidr-block 0.0.0.0/0 --nat-gateway-id nat-0bbb
$ sudo apt-get update      # app-1 থেকে যাচাই
$ aws ec2 delete-nat-gateway --nat-gateway-id nat-0aaa

৯ · Flow log আর reachability tool — প্রমাণ জোগাড়

পথ কেমন হওয়া উচিত, তা বলে configuration. আসলে কী ঘটছে, তা বলে flow log. প্রতিটি network interface-এর জন্য এটি সংক্ষিপ্ত রেকর্ড রাখে: কে, কাকে, কোন port, কত packet, আর সিদ্ধান্ত ACCEPT না REJECT. ভেতরের ডেটা এতে থাকে না। রেলস্টেশনের রেজিস্টার ভাবুন: কে এলো গেল লেখা আছে, ব্যাগের ভেতর কী, তা নয়।

নিচের Bash block-এ AWS-এর ডিফল্ট ধাঁচের ১৪টি ঘরের নমুনা log আছে, প্রথম সারিতে ঘরগুলোর নাম। ঠিকানাগুলো নমুনা। awk আগে দেখেছেন পর্ব ৯-এ। আমরা খুঁজব কোন flow আটকে গেছে।

set -euo pipefail
# Flow log sample in the common space-separated default layout.
log=$(mktemp); trap 'rm -f "$log"' EXIT
cat > "$log" <<'LOG'
version account eni src dst srcport dstport proto packets bytes start end action status
2 123456789012 eni-0app 10.0.11.20 203.0.113.80 49152 443 6 6 480 1760000000 1760000060 ACCEPT OK
2 123456789012 eni-0app 203.0.113.80 10.0.11.20 443 49152 6 5 3120 1760000000 1760000060 REJECT OK
2 123456789012 eni-0app 10.0.11.20 203.0.113.80 49153 443 6 6 480 1760000060 1760000120 ACCEPT OK
2 123456789012 eni-0app 203.0.113.80 10.0.11.20 443 49153 6 5 3120 1760000060 1760000120 REJECT OK
2 123456789012 eni-0app 10.0.11.20 10.0.21.5 41000 5432 6 12 2100 1760000000 1760000060 ACCEPT OK
2 123456789012 eni-0db 10.0.12.30 10.0.21.5 41222 5432 6 3 180 1760000000 1760000060 REJECT OK
2 123456789012 eni-0db 10.0.12.30 10.0.21.5 41223 5432 6 3 180 1760000060 1760000120 REJECT OK
2 123456789012 eni-0db 10.0.12.30 10.0.21.5 41224 5432 6 3 180 1760000120 1760000180 REJECT OK
2 123456789012 eni-0web 198.51.100.7 10.0.1.25 53211 22 6 1 60 1760000000 1760000060 REJECT OK
2 123456789012 eni-0web 198.51.100.7 10.0.1.25 53212 3389 6 1 60 1760000000 1760000060 REJECT OK
2 123456789012 eni-0web 203.0.113.9 10.0.1.25 55000 443 6 9 1400 1760000000 1760000060 ACCEPT OK
2 123456789012 eni-0idle - - - - - - - 1760000000 1760000060 - NODATA
LOG

echo "== records by action =="
awk 'NR>1 && $14=="OK" {print $13}' "$log" | sort | uniq -c

echo "== rejected: src -> dst:dstport, by count =="
awk 'NR>1 && $13=="REJECT" {print $4, "->", $5":"$7}' "$log" |
  sort | uniq -c | sort -k1,1nr -k2,2

echo "== rejected replies (server port to high port) =="
awk 'NR>1 && $13=="REJECT" && $6<1024 && $7>=1024 {
  print $4":"$6, "->", $5":"$7, "pkts="$9 }' "$log"

প্রমাণের চারটি স্তর

তিন provider-এ একই ধারণা

নামগুলো লেখার সময়ের, আর আচরণে সূক্ষ্ম পার্থক্য আছে। এসব tool কিছু ক্ষেত্রে বিশ্লেষণ-প্রতি টাকা নিতে পারে।

১০ · AI-এর যুগে routing যাচাই

AI কয়েক সেকেন্ডে পুরো VPC-র Terraform লিখে দিতে পারে। চলতেও পারে। কিন্তু routing-এর ভুল প্রায়ই সাথে সাথে ধরা পড়ে না: database public হয়ে যায়, অথবা NAT-এর বিল মাস শেষে চমকে দেয়। Terraform-এর বিস্তারিত পর্ব ৫২-তে আসবে। আপাতত নিচের AWS-ধাঁচের ছোট অংশটি পড়তে পারাই লক্ষ্য। এখানে একটি AZ-এর private subnet-এর পথ বাঁধা হয়েছে।

resource "aws_nat_gateway" "a" {
  allocation_id = aws_eip.nat_a.id
  subnet_id     = aws_subnet.public_a.id   # public subnet, not private
  depends_on    = [aws_internet_gateway.main]
}

resource "aws_route_table" "private_a" {
  vpc_id = aws_vpc.main.id
  route {
    cidr_block     = "0.0.0.0/0"
    nat_gateway_id = aws_nat_gateway.a.id  # NAT in the same AZ
  }
}

resource "aws_route_table_association" "private_a" {
  subnet_id      = aws_subnet.private_a.id
  route_table_id = aws_route_table.private_a.id
}

AI সাধারণত যেসব ভুল করে

AI-এর লেখা network config হাতে পেলে

• terraform plan বা --dry-run আগে দেখেছি, আর diff-এর প্রতিটি route পড়েছি
• প্রতিটি subnet-এর association পরিষ্কার, কিছুই main table-এর ভরসায় নেই
• NAT আছে public subnet-এ, আর প্রতি AZ-এ নিজের table
• Database subnet-এ IGW-র route নেই, public IP-ও নেই
• সব resource argument provider-এর নথিতে মিলিয়ে দেখেছি
• মাসিক খরচ অনুমান করেছি, budget alert আছে
• একটি পরীক্ষার পরিবেশে reachability tool চালিয়ে পথ দেখেছি