ক্যাপস্টোন — একটি প্রতিষ্ঠানের পুরো নেটওয়ার্ক নকশা

১ · প্রয়োজন সংগ্রহ — কার জন্য, কী কাজে, কত দিনের জন্য

এতদিন আমরা নেটওয়ার্কের এক একটি টুকরো আলাদা করে শিখেছি — switch, VLAN, subnet, routing, DNS, TLS, firewall. এই ক্যাপস্টোনে সব টুকরো জোড়া লাগিয়ে একটি পুরো প্রতিষ্ঠানের নেটওয়ার্ক নকশা করব, ঠিক যেভাবে একজন নেটওয়ার্ক প্রকৌশলী বাস্তবে করেন।

প্রতিষ্ঠান (কাল্পনিক)

আমাদের প্রতিষ্ঠান “নদীতীর ফাউন্ডেশন” — একটি সম্পূর্ণ কাল্পনিক উন্নয়ন সংস্থা (NGO); কোনো বাস্তব প্রতিষ্ঠানের সাথে মিল কাকতালীয়। এর ডোমেইন হিসেবে ব্যবহার করব example.org, আর সব public ঠিকানা নেওয়া হয়েছে শুধু উদাহরণের জন্য সংরক্ষিত documentation address থেকে (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24, IPv6-এ 2001:db8::/32).

এরপর লিখে নেওয়া হয় অনুমানগুলো — যেগুলো ভুল হলে নকশা বদলাতে হবে, তাই সেগুলো স্পষ্ট রাখা জরুরি:

• বৃদ্ধি: তিন বছরে যন্ত্রের সংখ্যা ৩০% বাড়বে — তাই প্রতিটি হিসাবে ×১.৩.
• প্রাপ্যতা (availability): অফিস সময়ে HQ-এর ইন্টারনেট আর finance অ্যাপ বন্ধ থাকা চলবে না; একটি যন্ত্র নষ্ট হলে কয়েক সেকেন্ডে বিকল্প পথ। শাখায় কিছুটা কম কড়াকড়ি।
• বাজেট: NGO, তাই খরচ-সচেতন — যেখানে সম্ভব ওপেন স্ট্যান্ডার্ড, এক vendor-এ আটকে না থাকা, আর ধাপে ধাপে কেনা।
• নিয়মকানুন (compliance): দাতা সংস্থার অডিট, আর্থিক তথ্যের গোপনীয়তা, লগ সংরক্ষণ। বাংলাদেশের প্রযোজ্য আইন ও নিয়ন্ত্রক নির্দেশনা (যেমন ডেটা আর VPN সংক্রান্ত) বাস্তবায়নের সময় আইনজ্ঞের সাথে যাচাই করতে হবে — এই পর্ব আইনি পরামর্শ নয়।

২ · লজিক্যাল নকশা — কাজ অনুযায়ী VLAN

প্রথম বড় সিদ্ধান্ত: নেটওয়ার্ককে কী কী ভাগে ভাঙব। নিয়মটি সহজ — যাদের বিশ্বাসের মাত্রা আর traffic-এর ধরন একই, তারা এক VLAN-এ। পর্ব ১৩-এ (VLAN আর trunking) দেখেছেন, VLAN একটি switch-কে কয়েকটি আলাদা broadcast domain-এ ভাগ করে; আর প্রতিটি VLAN পরে একটি আলাদা subnet আর আলাদা zone হবে।

কয়েকটি ছোট কিন্তু গুরুত্বপূর্ণ সিদ্ধান্ত:

• একই VLAN নম্বর সব সাইটে — চট্টগ্রামেও VOIP মানে 40. মুখস্থ রাখা, টেমপ্লেট বানানো আর সমস্যা খোঁজা সহজ।
• IP ফোন: ডেস্কের একটি তারেই ফোন আর তার পেছনের PC — ফোনের frame যায় voice VLAN 40-এর tag নিয়ে, PC-র frame tag ছাড়া VLAN 10-এ। ফোন voice VLAN নম্বর জানে LLDP-MED থেকে।
• Native VLAN অব্যবহৃত (যেমন 999), আর trunk-এ শুধু দরকারি VLAN — পর্ব ১৩-এর VLAN hopping প্রতিরোধ।
• Finance কর্মী Wi-Fi-তে এলেও VLAN 20-এ: একই SSID, কিন্তু login-এর পর RADIUS সার্ভার ব্যবহারকারীর দল দেখে VLAN ঠিক করে দেয় — একে বলে dynamic VLAN assignment.

৩ · ঠিকানার পরিকল্পনা — VLSM, summarisation আর IPv6

পুরো প্রতিষ্ঠানের জন্য একটি private ব্লক বেছে নিই: 10.20.0.0/16. তারপর ব্লকটি “মহল্লা” ধরে ভাগ — ঠিক যেমন শহরের ঠিকানায় আগে এলাকা, তারপর রোড, তারপর বাড়ি:

এখন প্রতিটি সাইটের ভেতরে পর্ব ১৭-এর VLSM: প্রতিটি VLAN-এর যন্ত্রসংখ্যা ×১.৩, তার সাথে gateway-এর জন্য +১; তারপর সবচেয়ে বড় subnet আগে বসানো। নিচের planner পুরো কাজটি করে আর একটি পূর্ণ টেবিল ছাপে — subnet, ব্যবহারযোগ্য host, gateway আর DHCP pool.

// VLSM planner: hosts now x 1.3 growth (+1 for the gateway) -> aligned subnets per site block.
const ip = s => s.split(".").reduce((a, o) => a * 256 + Number(o), 0);
const str = n => [24, 16, 8, 0].map(b => Math.floor(n / 2 ** b) % 256).join(".");
const SITES = [   // [site, block, [VLAN id, name, hosts now, static only?]]
  ["HQ", "10.20.0.0/20", [[10, "STAFF", 320], [60, "GUEST", 150], [40, "VOIP", 120],
    [20, "FINANCE", 40], [50, "CCTV", 40], [99, "MGMT", 38, 1], [30, "SERVERS", 30, 1],
    [200, "DMZ", 8, 1], [900, "TRANSIT", 5, 1]]],
  ["CTG", "10.20.16.0/22", [[10, "STAFF", 80], [40, "VOIP", 30], [60, "GUEST", 40],
    [50, "CCTV", 8], [99, "MGMT", 8, 1]]],
  ["KHL", "10.20.20.0/22", [[10, "STAFF", 50], [40, "VOIP", 20], [60, "GUEST", 25],
    [50, "CCTV", 6], [99, "MGMT", 6, 1]]],
];
console.log("site vlan name     need subnet            usable gateway      DHCP pool");
for (const [site, block, vlans] of SITES) {
  const [net, len] = block.split("/"), start = ip(net), end = start + 2 ** (32 - len);
  let cur = start;
  const plan = vlans.map(([id, name, now, st]) => {
    const need = Math.ceil(now * 1.3);
    let h = 2; while (2 ** h - 2 < need + 1) h++;          // +1: the gateway
    return { id, name, need, st, size: 2 ** h, pfx: 32 - h };
  }).sort((a, b) => b.size - a.size);                       // biggest first => aligned
  for (const v of plan) {
    cur = Math.ceil(cur / v.size) * v.size;
    const gw = cur + 1, last = cur + v.size - 2, keep = Math.min(10, v.size - 3 - v.need);
    const pool = v.st ? "static" : `${str(gw + 1 + keep)} - ${str(last)}`;
    console.log(`${site.padEnd(4)} ${String(v.id).padEnd(4)} ${v.name.padEnd(8)} ${String(v.need).padStart(4)} ` +
      `${(str(cur) + "/" + v.pfx).padEnd(17)} ${String(v.size - 2).padStart(6)} ${str(gw).padEnd(12)} ${pool}`);
    cur += v.size;
  }
  const used = cur - start;
  console.log(`  -> ${site}: ${used} of ${end - start} addresses used, summary route ${block}` +
    (cur <= end ? " (all subnets inside)" : " OVERFLOW!"));
}

Summarisation-এর লাভ: HQ-এর firewall চট্টগ্রামের পাঁচটি subnet আলাদা না জেনে একটি route রাখে — 10.20.16.0/22; উল্টো দিকে চট্টগ্রাম পুরো প্রতিষ্ঠানের জন্য একটি route রাখে — 10.20.0.0/16, আর longest prefix match-এ নিজের subnet-গুলো (আরও নির্দিষ্ট) আগে জেতে। চট্টগ্রামে নতুন VLAN যোগ হলেও HQ-এর route বদলাতে হবে না (route summarisation, পর্ব ১৭ ও ২২)।

IPv6 পরিকল্পনা

IPv6-এ ঠিকানার অভাব নেই, তাই হিসাব আরও সহজ (পর্ব ২১)। প্রতিষ্ঠান পায় একটি /48 — এখানে উদাহরণের 2001:db8::/48. /48 থেকে /64 পর্যন্ত ১৬ bit = ৬৫,৫৩৬টি /64. আমরা ১৬ bit-কে মানুষের পড়ার মতো করে সাজাই: প্রথম hex অঙ্ক সাইট, বাকি তিনটি VLAN নম্বর।

• প্রতিটি VLAN-এ ঠিক একটি /64 — SLAAC /64 ছাড়া কাজ করে না, আর অনেক Android ফোন stateful DHCPv6 সমর্থন করে না, তাই client VLAN-এ SLAAC চালু রাখতে হয়।
• প্রতিটি সাইট একটি /52 (৪০৯৬টি /64) — IPv4-এর মতোই একটি summary route.
• Dual stack: IPv4 আর IPv6 একসাথে। সবচেয়ে বড় ঝুঁকি: firewall-এ শুধু IPv4-এর নিয়ম লিখে IPv6 খোলা রেখে দেওয়া। আর access switch-এ RA Guard, যাতে কোনো যন্ত্র নিজেকে router ঘোষণা করতে না পারে।

৪ · ভৌত নকশা — core, access, Wi-Fi আর PoE

HQ মাঝারি আকারের, তাই পুরোনো তিন স্তরের (core–distribution–access) নকশার দরকার নেই। আমরা নিই collapsed core: server room-এ দুটি layer-3 switch একসাথে core আর distribution-এর কাজ করে, আর প্রতি তলায় access switch.

• Redundancy: দুই core-এর মাঝে LACP-এ দুটি 10G তার একটি যৌক্তিক লিঙ্ক (link aggregation) — একটি তার কাটলেও চলে। প্রতিটি access switch-এর একটি uplink CORE-1-এ, একটি CORE-2-এ।
• Loop আর RSTP (পর্ব ১২): দুই uplink মানে loop, তাই RSTP একটিকে বন্ধ রাখে। Root bridge ইচ্ছা করে বসানো হয় CORE-1-এ (সবচেয়ে কম priority, যেমন 4096), CORE-2 দ্বিতীয় (8192) — না হলে কোনো পুরোনো access switch root হয়ে সব traffic ঘুরপথে নিতে পারে।
• Gateway redundancy: প্রতিটি VLAN-এর gateway .1 একটি VRRP virtual ঠিকানা; CORE-1 .2 (master), CORE-2 .3. নিয়ম: STP root আর VRRP master একই switch-এ, যাতে frame অকারণে CORE-2 ঘুরে না আসে।
• বিকল্প: অনেক vendor দুই core-কে একটি যৌক্তিক switch বানায় (stacking বা MLAG); তখন access switch দুই core-এ LACP করতে পারে, কোনো লিঙ্ক বন্ধ থাকে না। এটি vendor-নির্ভর, তাই নকশায় বিকল্প হিসেবে লেখা।

Wi-Fi — AP, channel আর নিরাপত্তা

প্রতি তলা ধরে নিই প্রায় ১,০০০ বর্গমিটার, ৬০ জন মানুষ আর একটি মিটিং রুম। ঘন অফিসে একটি AP সাধারণত ২০–৩০ জন সক্রিয় ব্যবহারকারী ভালোভাবে সামলায়, তাই প্রতি তলায় ৬টি AP — তবে চূড়ান্ত সংখ্যা ঠিক হয় সাইট সার্ভে (দেয়াল, কাঁচ, লিফটের দেয়াল মেপে) করে। পর্ব ১৪-এর (Wi-Fi) নিয়মে channel পরিকল্পনা:

ওপর-নিচের তলায় একই জায়গার AP-কে আলাদা channel দেওয়া হয়, কারণ সংকেত ছাদ ভেদ করে যায়। কোন 5 GHz channel আর কত শক্তি অনুমোদিত, তা দেশের নিয়ন্ত্রক সংস্থার (বাংলাদেশে BTRC) নিয়মে যাচাই করে নিতে হবে; কিছু channel-এ DFS লাগে। SSID মাত্র দুটি, কারণ প্রতিটি SSID-এর beacon airtime খায়:

• NT-Staff — WPA3-Enterprise: প্রত্যেকে নিজের account-এ 802.1X দিয়ে ঢোকেন; RADIUS যাচাই করে দল অনুযায়ী VLAN 10 বা 20 দেয়। কেউ চাকরি ছাড়লে শুধু তাঁর account বন্ধ — সবার পাসওয়ার্ড বদলাতে হয় না।
• NT-Guest — WPA3-Personal (পুরোনো ফোনের জন্য WPA2/WPA3 transition): পাসওয়ার্ড রিসেপশনে, মাসে একবার বদল; client isolation চালু, যাতে এক অতিথি আরেকজনের ফোনে পৌঁছাতে না পারেন; গতি সীমিত।

PoE বাজেট — হাতে হিসাব

AP, IP ফোন আর ক্যামেরা বিদ্যুৎ পায় ডেটার তারেই — PoE. Switch-এর মোট PoE ক্ষমতা সীমিত, তাই হিসাব লাগে। Switch প্রতিটি যন্ত্রের জন্য তার class অনুযায়ী সর্বোচ্চ শক্তি সংরক্ষণ করে ধরে নিয়ে হিসাব করি:

চট্টগ্রাম: ৩টি AP × ৩০ = ৯০ W, ৩০টি ফোন × ৭ = ২১০ W, ৮টি ক্যামেরা × ১৫.৪ = ১২৩.২ W; মোট ৪২৩.২ W. ৪৮-port-এর একটি সাধারণ switch-এর PoE বাজেট যদি ৩৭০ W হয়, তাহলে চাপ ৪২৩.২ ÷ ৩৭০ ≈ ১১৪% — যথেষ্ট নয়! হয় ৭৪০ W মডেল, নয়তো দুটি switch. নিয়ম হিসেবে বাজেটের ৮০%-এর বেশি পরিকল্পনা করবেন না — ভবিষ্যতের যন্ত্র আর হিসাবের ভুলের জন্য জায়গা রাখতে। আর PoE switch মানে UPS-এর ওপর বেশি চাপ — load-shedding-এ ফোন আর ক্যামেরা চালু রাখতে UPS-এর হিসাবও এই সংখ্যা থেকেই আসে। পুরো হিসাব অংশ ৮-এর calculator-এ।

৫ · Routing — VLAN-এর মাঝে, ইন্টারনেটে আর শাখায়

Routing তিন স্তরে ভাবুন: ভবনের ভেতরে (VLAN থেকে VLAN), ভবন থেকে ইন্টারনেটে, আর শহর থেকে শহরে (শাখা)।

1. ভবনের ভেতরে: core switch-এর প্রতিটি VLAN-এ একটি virtual interface (SVI) — সেটিই gateway, আর inter-VLAN routing হয় switch-এর hardware-এ, পূর্ণ গতিতে। ব্যতিক্রম GUEST আর DMZ: এদের gateway সরাসরি firewall, core-এ এদের কোনো SVI নেই — অতিথির packet ভেতরের কোনো router ছোঁয়ার সুযোগই পায় না।
2. ইন্টারনেটে: core-এ একটিই default route: 0.0.0.0/0 via 10.20.5.17 (firewall জোড়ার virtual ঠিকানা)। Firewall-এ উল্টো route: 10.20.0.0/20 via 10.20.5.22 (core-এর VRRP ঠিকানা) — GUEST, DMZ আর TRANSIT firewall-এ সরাসরি যুক্ত, তাই আরও নির্দিষ্ট হওয়ায় সেগুলো সরাসরি যায় (পর্ব ২২)।
3. শাখায়: ভাড়া করা ব্যক্তিগত লাইন দামি, তাই সাধারণ ইন্টারনেটের ওপর এনক্রিপ্টেড site-to-site VPN — এখানে WireGuard (পর্ব ৪৯); IPsec IKEv2-ও সমান উপযুক্ত, বিশেষ করে ভিন্ন vendor-এর যন্ত্রের মাঝে।

দুটি শাখার জন্য health check-সহ static route যথেষ্ট আর সহজে বোঝা যায়। শাখা পাঁচ-ছয়টি ছাড়ালে প্রতিটি tunnel-কে একটি সাধারণ interface ধরে তার ওপর OSPF চালানো ভালো (পর্ব ২৪) — tunnel-এর cost দিয়ে প্রধান আর বিকল্প পথ ঠিক হয়, নতুন শাখার route নিজে থেকেই ছড়ায়। WireGuard-এ তখন প্রতিটি peer-এর জন্য আলাদা interface আর চওড়া AllowedIPs লাগে, কারণ কোন ঠিকানা কোন tunnel-এ যাবে তা routing protocol ঠিক করবে।

এবার একটি packet ধরে পুরো পথ দেখি: চট্টগ্রামের একজন কর্মী (10.20.16.25) HQ-এর intranet portal (10.20.4.210:443) খুলছেন। চট্টগ্রামের public ঠিকানা 198.51.100.66, HQ-এর ISP-A ঠিকানা 198.51.100.10.

Dual-ISP আর failover

HQ-তে দুটি ভিন্ন ISP, সম্ভব হলে ভিন্ন ভৌত পথে (একটি fiber রাস্তার এক পাশ দিয়ে, অন্যটি আরেক পাশ বা ভিন্ন প্রযুক্তি)। Firewall প্রতিটি ISP দিয়ে কয়েক সেকেন্ড পরপর কয়েকটি নির্ভরযোগ্য ঠিকানায় ping পাঠায় — health check. কয়েকটি পরপর ব্যর্থ হলে ISP-A “down”, default route চলে যায় ISP-B-তে; শাখাগুলোও tunnel “b”-তে সরে। ফিরে আসার সময় তাড়াহুড়া নয় — পরপর বেশ কয়েকটি সফল উত্তরের পর, যাতে টলমলে লিঙ্কে route বারবার উল্টে না যায় (flapping).

// Dual-ISP failover with health checks: down after 3 failed probes, up after 5 good ones.
const DOWN_AFTER = 3, UP_AFTER = 5, STEP = 5;               // probe every 5 seconds
// probe result via ISP-A for each tick (1 = reply, 0 = lost); first lost probe at t=15 s
const probesA = [1, 1, 1, 0, 0, 0, 0, 0, 0, 1, 1, 0, 1, 1, 1, 1, 1, 1];
let up = true, bad = 0, good = 0;
console.log("  t  probe  bad good  ISP-A  default route        CTG tunnel");
probesA.forEach((ok, i) => {
  if (ok) { good++; bad = 0; } else { bad++; good = 0; }
  let note = "";
  if (up && bad >= DOWN_AFTER) { up = false; note = "<- ISP-A declared DOWN"; }
  if (!up && good >= UP_AFTER) { up = true; note = "<- ISP-A back UP"; }
  const route = up ? "0.0.0.0/0 via ISP-A" : "0.0.0.0/0 via ISP-B";
  const tunnel = up ? "wg-ctg-a (primary)" : "wg-ctg-b (backup)";
  console.log(`${String(i * STEP).padStart(3)}  ${ok ? "ok  " : "LOST"}  ${String(bad).padStart(3)}` +
    ` ${String(good).padStart(4)}  ${up ? "up  " : "DOWN"}   ${route.padEnd(20)} ${tunnel.padEnd(19)}${note}`);
});
const firstLost = probesA.indexOf(0) * STEP, declared = (probesA.indexOf(0) + DOWN_AFTER - 1) * STEP;
console.log(`outage starts ~${firstLost}s, failover at ${declared}s -> up to ${declared - firstLost + STEP}s of loss`);

৬ · সেবা — DHCP, DNS, NTP, ওয়েবসাইট, ইমেইল আর certificate

নেটওয়ার্ক শুধু রাস্তা; মানুষ যা ব্যবহার করেন তা হলো সেবা। প্রতিটি সেবার জন্য প্রশ্ন একই — কোথায় চলবে, একটি নষ্ট হলে কী হবে।

ইমেইলের DNS record-গুলো লিখে ফেলি (মেইল সেবাদাতার নাম কাল্পনিক provider.example; DKIM key ছোট করে দেখানো):

; উদাহরণ — example.org zone (সংক্ষেপিত)
example.org.                 MX   10 mx1.provider.example.
example.org.                 TXT  "v=spf1 include:_spf.provider.example -all"
s1._domainkey.example.org.   TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...IDAQAB"
_dmarc.example.org.          TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.org"
example.org.                 CAA  0 issue "letsencrypt.org"
portal.example.org.          A    198.51.100.12      ; বাইরের view
www.example.org.             CNAME example-org.cdn.example.

• SPF: কোন server example.org-এর নামে মেইল পাঠাতে পারে; -all মানে তালিকার বাইরে সব ব্যর্থ। অফিসের কোনো স্ক্যানার বা অ্যাপ নিজে মেইল পাঠালে সেটিও তালিকায় যোগ করতে হবে।
• DKIM: প্রতিটি মেইলে digital signature; public key DNS-এ, selector s1.
• DMARC ধাপে ধাপে: শুরু p=none (শুধু রিপোর্ট), কয়েক সপ্তাহ রিপোর্ট দেখে সব বৈধ প্রেরক ঠিক হলে p=quarantine, তারপর p=reject. সরাসরি reject দিয়ে শুরু করলে নিজের বৈধ মেইলও হারাতে পারে।
• CAA: কোন CA এই ডোমেইনের certificate দিতে পারবে — ভুল বা প্রতারণামূলক certificate-এর ঝুঁকি কমায়।

এবার সব জোড়া লাগিয়ে দেখি — HQ-এর দোতলার একজন কর্মী সকালে ল্যাপটপ খুলে intranet portal খুলছেন। ছয়টি ধাপে সেবা আর নেটওয়ার্ক একসাথে কাজ করে:

৭ · নিরাপত্তা নকশা — zone, নীতির ছক আর firewall

পর্ব ৪৬-এর (নিরাপত্তার ভিত্তি) মূল কথা: নেটওয়ার্ককে বিশ্বাসের মাত্রা অনুযায়ী zone-এ ভাগ করুন, আর zone-এর সীমানায় পাহারা বসান — defense in depth. আমাদের zone: INTERNET, DMZ, STAFF, FINANCE, SERVERS, MGMT, GUEST, IoT/CCTV, VOIP, শাখা (BRANCH) আর VPN. এবার ছক — সারিতে উৎস, কলামে গন্তব্য; ফাঁকা ঘর মানে নিষেধ (default deny).

ছকটি কাগজে সুন্দর, কিন্তু কাজ করছে কি না জানতে হলে পরীক্ষা লাগে। নিচের evaluator নিয়মগুলো ওপর থেকে মেলায় — প্রথম যেটি মেলে সেটিই সিদ্ধান্ত, কিছু না মিললে default deny. পরীক্ষার প্রবাহগুলো আসলে গ্রহণযোগ্যতার পরীক্ষার তালিকা (অংশ ৯)।

// Inter-zone policy: first matching rule wins, anything unmatched is denied (default deny).
const SVC = { web: "tcp/80,443", https: "tcp/443", dns: "udp+tcp/53", db: "tcp/5432",
  sip: "udp/5060+rtp", ssh: "tcp/22", smtp: "tcp/25", ntp: "udp/123", syslog: "udp/514" };
const RULES = [   // [id, from, to, services, action]
  ["R1", "STAFF",   "INTERNET", ["web"],           "allow"],
  ["R2", "STAFF",   "SERVERS",  ["https", "dns"],  "allow"],
  ["R3", "FINANCE", "SERVERS",  ["https", "dns", "db"], "allow"],
  ["R4", "FINANCE", "INTERNET", ["https"],         "allow"],
  ["R5", "VOIP",    "SERVERS",  ["sip"],           "allow"],
  ["R6", "GUEST",   "INTERNET", ["web", "dns"],    "allow"],
  ["R7", "CCTV",    "INTERNET", ["*"],             "deny+log"],
  ["R8", "VPN-ADMIN", "MGMT",   ["ssh", "https"],  "allow"],
  ["R9", "MGMT",    "SERVERS",  ["syslog", "ntp"], "allow"],
  ["R10", "INTERNET", "DMZ",    ["https"],         "allow"],
  ["R11", "BRANCH",  "SERVERS", ["https", "dns"],  "allow"],
];
function decide(from, to, svc) {
  for (const [id, f, t, list, act] of RULES)
    if (f === from && t === to && (list.includes("*") || list.includes(svc)))
      return `${act.toUpperCase().padEnd(8)} (${id})`;
  return "DENY     (default)";
}
const FLOWS = [
  ["GUEST", "SERVERS", "db"],      ["STAFF", "INTERNET", "web"],  ["CCTV", "INTERNET", "https"],
  ["VPN-ADMIN", "MGMT", "ssh"],    ["STAFF", "MGMT", "ssh"],      ["FINANCE", "SERVERS", "db"],
  ["STAFF", "SERVERS", "db"],      ["INTERNET", "DMZ", "https"],  ["INTERNET", "SERVERS", "ssh"],
  ["BRANCH", "SERVERS", "https"],  ["GUEST", "STAFF", "https"],   ["VOIP", "SERVERS", "sip"],
];
console.log("from       -> to        service  port          decision");
for (const [f, t, s] of FLOWS)
  console.log(`${f.padEnd(10)} -> ${t.padEnd(9)} ${s.padEnd(8)} ${SVC[s].padEnd(13)} ${decide(f, t, s)}`);
const allow = FLOWS.filter(([f, t, s]) => decide(f, t, s).startsWith("ALLOW")).length;
console.log(`${allow} of ${FLOWS.length} test flows allowed; everything else is dropped and logged`);

Firewall-এর নিয়ম — nftables-ধাঁচে

ছক থেকে আসল নিয়ম। নিচেরটি পর্ব ৪৯-এর nftables-এর ধাঁচে লেখা একটি সরলীকৃত উদাহরণ — interface-এর নাম কাল্পনিক, আর বাস্তব firewall-এর ভাষা vendor অনুযায়ী আলাদা হবে।

# উদাহরণ — HQ firewall (nftables-ধাঁচ, সরলীকৃত)
table inet nt_fw {
  chain forward {
    type filter hook forward priority 0; policy drop;
    ct state established,related accept
    ct state invalid drop
    iifname "guest" oifname { "ispA", "ispB" } tcp dport { 80, 443 } accept          # R6
    iifname "guest" log prefix "GUEST-DENY " drop
    ip saddr 10.20.4.64/26 oifname { "ispA", "ispB" } log prefix "CCTV-OUT " drop  # R7
    iifname "wg-*" ip saddr { 10.20.16.0/22, 10.20.20.0/22 } ip daddr 10.20.4.192/26 tcp dport 443 accept  # R11
    iifname "vpn" ip saddr 10.20.32.0/27 ip daddr 10.20.4.128/26 tcp dport { 22, 443 } accept   # R8
    iifname { "ispA", "ispB" } ip daddr 10.20.5.5 tcp dport 443 accept                 # R10 (DNAT-এর পরে)
    iifname "core" ip saddr 10.20.0.0/23 oifname { "ispA", "ispB" } tcp dport { 80, 443 } accept  # R1
    log prefix "DEFAULT-DENY " counter
  }
}
table ip nt_nat {
  chain prerouting  { type nat hook prerouting priority -100;
    iifname "ispA" ip daddr 198.51.100.12 tcp dport 443 dnat to 10.20.5.5 }
  chain postrouting { type nat hook postrouting priority 100;
    oifname "ispA" snat to 198.51.100.10
    oifname "ispB" snat to 203.0.113.10 }
}

• NAT (পর্ব ১৯): বাইরে যাওয়ার সময় SNAT — যে ISP দিয়ে যাচ্ছে তার ঠিকানায়। ভেতরে আসার জন্য শুধু একটি DNAT: public 198.51.100.12:443 → DMZ-এর reverse proxy 10.20.5.5, যা যাচাই করে তবেই portal-এ পাঠায়। ভেতরের কোনো server সরাসরি ইন্টারনেটে খোলা নয়।
• Egress-ও নিয়ন্ত্রিত: ভেতর থেকে বাইরে সব খোলা নয় — শুধু দরকারি port (egress filtering). অতিথি নেটওয়ার্ক ছাড়া ভেতরের সব যন্ত্র নাম খোঁজে শুধু ভেতরের resolver দিয়ে — সরাসরি বাইরের DNS-এ যেতে পারে না।
• IPv6-এর জন্যও একই নিয়ম (table inet দুটিকেই ধরে); IPv6-এ NAT নেই, নিরাপত্তা আসে stateful নিয়ম থেকে।

এবার একজন অতিথির ফোন দিয়ে ছকটি বাস্তবে দেখি। অতিথি কৌতূহলে finance-এর database server-এর ঠিকানায় (10.20.4.220:5432) যোগাযোগের চেষ্টা করলেন, তারপর একটি সাধারণ ওয়েবসাইট (192.0.2.80:443) খুললেন।

বাকি নিরাপত্তা-স্তর

• Remote-access VPN আর MFA: বাইরে থেকে কর্মীরা VPN-এ ঢোকেন, প্রবেশের সময় পাসওয়ার্ডের সাথে দ্বিতীয় প্রমাণ (OTP বা hardware key). খেয়াল করুন, WireGuard নিজে শুধু key দিয়ে পরিচয় যাচাই করে — MFA লাগলে IKEv2-EAP, MFA-সমর্থিত VPN gateway বা zero trust ধরনের access প্রক্সি বেছে নিতে হয়। অ্যাডমিনরা পান আলাদা ঠিকানা-অংশ (10.20.32.0/27), যা MGMT-এ যেতে পারে।
• Management plane আলাদা: switch, AP, firewall-এর login শুধু MGMT VLAN থেকে, SSH key আর কেন্দ্রীয় AAA দিয়ে; Telnet আর সাধারণ HTTP বন্ধ। Firewall নষ্ট হলে ঢোকার জন্য একটি out-of-band পথ (console server আর আলাদা মোবাইল সংযোগ) রাখুন।
• Access স্তরের সুরক্ষা: DHCP snooping, Dynamic ARP Inspection, অব্যবহৃত port বন্ধ, তারের port-এও 802.1X বা MAC-ভিত্তিক NAC (পর্ব ৫০)।
• লগ, SIEM আর IDS: firewall, core, AP, VPN আর DNS-এর লগ একটি কেন্দ্রীয় লগ সার্ভারে, সেখান থেকে SIEM-এ সতর্কবার্তা। IDS বসে core আর firewall-এর মাঝের TRANSIT লিঙ্কে এবং DMZ-এ — switch-এর port mirroring বা TAP থেকে packet-এর কপি দেখে; প্রথমে শুধু দেখে (IDS), নিয়ম ঠিকমতো বসার পর প্রয়োজনে পথে বসিয়ে আটকায় (IPS).
• Backup — ৩-২-১: server-এর ডেটা তিন কপি, দুই মাধ্যমে, একটি অন্য শহরে (যেমন চট্টগ্রাম শাখায় বা ক্লাউডে), আর একটি কপি অফলাইন বা অপরিবর্তনীয় — ransomware যেন সেটি মুছতে না পারে। Switch আর firewall-এর configuration-ও প্রতি রাতে backup. বছরে অন্তত একবার পুনরুদ্ধার পরীক্ষা করুন — পরীক্ষা না করা backup আসলে আশা মাত্র।

৮ · QoS আর bandwidth — কত Mbps কিনবেন

ভিডিও ডাউনলোড এক সেকেন্ড দেরি হলে কেউ টের পান না; কিন্তু ফোনে কথা ১৫০ মিলিসেকেন্ডের বেশি দেরি হলে বা jitter বাড়লে কথা কেটে যায়। তাই VoIP-কে অগ্রাধিকার (পর্ব ২৬, Multicast আর QoS):

• চিহ্ন দেওয়া: IP ফোন কথার packet-এ DSCP EF (46) বসায়, call setup-এর SIP-এ সাধারণত CS3 (24). Access switch শুধু voice VLAN-এর চিহ্ন বিশ্বাস করে; কর্মীর PC নিজে EF বসালে তা মুছে দেয় — নইলে সবাই নিজেকে “জরুরি” বলবে।
• সারি: যেখানে ভিড় হয় — মূলত firewall থেকে ISP-এর দিকে — EF-এর জন্য priority queue, তবে সীমা দিয়ে (যেমন লিঙ্কের ৩০%), যাতে ভুল চিহ্নিত traffic অন্যদের না খেয়ে ফেলে।
• Shaping: ISP লিঙ্কের ঠিক নিচে (যেমন ৯৫%) নিজে shape করুন — তাহলে সারি তৈরি হয় আপনার firewall-এ, যেখানে নিয়ম আপনার; ISP-এর যন্ত্রে নয়।
• বাস্তবতা: ইন্টারনেট পেরিয়ে DSCP সাধারণত মানা হয় না, আর tunnel-এ এনক্রিপ্ট করার সময় কিছু বাস্তবায়ন ভেতরের DSCP বাইরের header-এ কপিও করে না। তাই অগ্রাধিকার নিশ্চিত হয় শুধু নিজের লিঙ্কের দুই প্রান্তে।

এবার প্রতিটি সাইটের ISP লিঙ্কের আকার। সূত্র: ব্যবহারকারী × জনপ্রতি হার × একসাথে ব্যস্ত অংশ + কল × ০.১ + বাইরে থেকে CCTV দেখা + guest-এর সীমা, তারপর ×১.৩ বাড়তি জায়গা। সংখ্যাগুলো অনুমান — জনপ্রতি ১.৫ Mbps, ব্যস্ত সময়ে ৫০% সক্রিয় — বাস্তবে বর্তমান লিঙ্কের flow data মেপে (অংশ ৯) ঠিক করতে হয়। একই calculator PoE বাজেটও মেলায়:

// Busy-hour bandwidth per site + PoE budget per switch group. All inputs are ASSUMPTIONS.
const PER_USER = 1.5, CONC = 0.5, CALL = 0.1, CCTV_VIEW = 2, HEAD = 1.3;   // Mbps / ratios
const TIERS = [50, 100, 200, 300, 500, 1000];                               // link sizes (Mbps)
const SITES = [   // [site, users, concurrent outside calls, remote CCTV views, guest cap Mbps]
  ["HQ", 180, 20, 4, 30], ["CTG", 40, 6, 2, 10], ["KHL", 25, 4, 2, 5],
];
console.log("site  data  voice  cctv guest  total  x1.3   link");
for (const [s, u, calls, views, guest] of SITES) {
  const data = u * PER_USER * CONC, voice = calls * CALL, cctv = views * CCTV_VIEW;
  const total = data + voice + cctv + guest, need = total * HEAD;
  const link = TIERS.find(t => t >= need);
  console.log(`${s.padEnd(4)} ${data.toFixed(1).padStart(5)} ${voice.toFixed(1).padStart(6)} ` +
    `${cctv.toFixed(0).padStart(5)} ${String(guest).padStart(5)} ${total.toFixed(1).padStart(6)} ` +
    `${need.toFixed(1).padStart(6)} ${String(link).padStart(5)} Mbps`);
}
const W = { ap: 30, phone: 7, cam: 15.4 };   // PSE allocation: PoE+ class 4, class 2, class 3
const GROUPS = [   // [switch group, APs, phones, cameras, PoE budget W]
  ["HQ-F1", 6, 40, 16, 1480], ["HQ-F2", 6, 40, 12, 1480], ["HQ-F3", 6, 40, 12, 1480],
  ["CTG", 3, 30, 8, 370], ["KHL", 2, 20, 6, 370],
];
console.log("\ngroup   APs phones cams   watts budget  load  verdict");
for (const [g, ap, ph, cam, budget] of GROUPS) {
  const watts = ap * W.ap + ph * W.phone + cam * W.cam, load = watts / budget * 100;
  const verdict = load > 100 ? "OVER - bigger PoE switch" : load > 80 ? "tight (>80%)" : "ok";
  console.log(`${g.padEnd(7)} ${String(ap).padStart(3)} ${String(ph).padStart(6)} ${String(cam).padStart(4)} ` +
    `${watts.toFixed(1).padStart(7)} ${String(budget).padStart(6)} ${load.toFixed(0).padStart(4)}%  ${verdict}`);
}

৯ · চালানো, পরীক্ষা আর ধাপে ধাপে বাস্তবায়ন

Monitoring আর কাগজপত্র

• SNMPv3 (পুরোনো v2c-এর “public” community নয়) দিয়ে প্রতিটি যন্ত্রের CPU, interface-এর ব্যবহার আর error; firewall আর core থেকে NetFlow/IPFIX — কে কত traffic খাচ্ছে। সতর্কবার্তা: ISP-এর latency, tunnel down, DHCP pool ৮০% ভরা, PoE বাজেট, UPS ব্যাটারি।
• IPAM: অংশ ৩-এর টেবিলটিই একটি IPAM টুলে (যেমন ওপেন-সোর্স NetBox) — কোন ঠিকানা কার, কোন VLAN কোথায়। Excel-এর পাঁচটি কপি নয়, সত্যের একটি উৎস।
• ডায়াগ্রাম তিন স্তরে: ভৌত (কোন তার কোন port-এ), L2 (VLAN, trunk, STP root), L3 (subnet, route, zone).
• Runbook: সাধারণ কাজ আর সমস্যার ধাপে ধাপে নির্দেশ — নতুন কর্মী যোগ, ISP বন্ধ, AP বদল।
• Change management: প্রতিটি পরিবর্তনের আগে লিখিত পরিকল্পনা, আরেকজনের পর্যালোচনা, নির্দিষ্ট সময় (অফিস সময়ের বাইরে), ফেরানোর উপায় (rollback) আর পরে যাচাই।

গ্রহণযোগ্যতার পরীক্ষা (acceptance test)

সমস্যা খোঁজার runbook — “intranet খুলছে না”

পর্ব ৫৫-এর (সমস্যা খোঁজা) নিয়মে নিচ থেকে ওপরে, প্রতিটি ধাপে একটি প্রশ্ন:

1. সংযোগ: তার বা Wi-Fi যুক্ত? Switch port-এ link আর error আছে কি? 802.1X সফল?
2. ঠিকানা: ip addr বা ipconfig — ঠিক subnet? 169.254.x.x মানে DHCP পৌঁছায়নি (relay বা pool দেখুন)।
3. Gateway: ping 10.20.0.1; না পেলে VLAN বা ARP-এর সমস্যা।
4. নাম: dig portal.example.org বা nslookup — ভেতরের ঠিকানা আসছে?
5. পথ আর নিয়ম: traceroute, core-এর ACL counter, firewall-এর deny লগ, শাখা হলে tunnel-এর শেষ handshake.
6. অ্যাপ: curl -v https://portal.example.org — TLS বা server-এর ত্রুটি? প্রয়োজনে tcpdump-এ packet দেখা।

খরচ আর অগ্রাধিকার অনুযায়ী ধাপ

১০ · AI-এর যুগে নেটওয়ার্ক নকশা — খসড়া AI-এর, দায় আপনার

“২০০ জনের অফিসের নেটওয়ার্ক ডিজাইন করে দাও” — AI কয়েক সেকেন্ডে সুন্দর একটি নকশা লিখে দেবে। প্রথম খসড়া, চেকলিস্ট বা বিকল্প খুঁজতে এটি সত্যিই কাজের। কিন্তু নকশার ভুল ধরা পড়ে মাসের পর মাস পরে, আর তখন ঠিক করতে লাগে পুরো অফিসের ঠিকানা বদল। চেনা ভুলগুলো:

AI-এর নকশা হাতে পেলে — যাচাইয়ের চেকলিস্ট

• প্রতিটি subnet নিজে বা script দিয়ে আবার হিসাব করেছি — overlap নেই, alignment ঠিক, gateway-সহ host যথেষ্ট
• প্রতিটি যন্ত্র আর লিঙ্কের জন্য লিখেছি “এটি নষ্ট হলে কী হবে”
• Firewall নীতি default deny; IPv4 আর IPv6 দুটোর জন্যই নিয়ম আছে
• কমান্ড আর configuration নিজের যন্ত্রের ডকুমেন্টেশনের সাথে মিলিয়েছি, ল্যাব বা VM-এ চালিয়ে দেখেছি
• উল্লেখিত RFC আর মান নিজে খুলে পড়েছি
• চালুর আগে পরীক্ষার তালিকা আর rollback পরিকল্পনা লিখেছি