পাঠ ৫৬ · ৫৭-এর মধ্যে · মডিউল ১২
Home / Courses / Computer Networks / হোম/অফিস নেটওয়ার্ক ডিজাইন

কেস স্টাডি: একটি হোম/অফিস নেটওয়ার্ক ডিজাইন করা

Case study: designing a home/office network
১০ মিনিট পড়া উন্নত · Advanced Python কোডসহ সম্পূর্ণ বাংলায়

এই পাঠে যা শিখবেন

  • একটি ছোট অফিসের জন্য প্রাইভেট IP রেঞ্জ বাছাই ও সাবনেটিং
  • DHCP, NAT ও ফায়ারওয়াল সেগমেন্টেশন কীভাবে একসাথে একটি সম্পূর্ণ নেটওয়ার্ক ডিজাইন তৈরি করে
  • Python দিয়ে একটি সম্পূর্ণ নেটওয়ার্ক ডিজাইন মডেল করা — সাবনেট, হোস্ট কাউন্ট ও পলিসি যাচাই

১ · দৃশ্যপট (Scenario)

ধরুন আপনাকে একটি ছোট অফিসের নেটওয়ার্ক ডিজাইন করতে বলা হয়েছে — সেখানে স্টাফদের কম্পিউটার, ভিজিটরদের জন্য একটি গেস্ট WiFi, এবং একটি লোকাল ফাইল সার্ভার আছে। লক্ষ্য — সবাইকে ইন্টারনেট অ্যাক্সেস দেওয়া, কিন্তু গেস্ট WiFi থেকে অফিসের অভ্যন্তরীণ রিসোর্সে (স্টাফ ডিভাইস, সার্ভার) কোনো প্রবেশাধিকার না দেওয়া।

২ · ওয়াকথ্রু (Walkthrough)

প্রথমে একটি প্রাইভেট IP রেঞ্জ (M4/L14) বেছে নিয়ে সেটিকে আলাদা উদ্দেশ্যের জন্য কয়েকটি সাবনেটে (M4/L15) ভাগ করা হয় — স্টাফ ডিভাইস, গেস্ট WiFi ও সার্ভারের জন্য আলাদা সাবনেট, যা সাইবার-সিকিউরিটি কোর্সের নেটওয়ার্ক সেগমেন্টেশন নীতির সরাসরি প্রয়োগ। প্রতিটি সাবনেটে DHCP (M6/L33) কনফিগার করা হয় যাতে ডিভাইসগুলো স্বয়ংক্রিয়ভাবে একটি সঠিক IP ঠিকানা পায়। গেটওয়েতে NAT (M4/L21) সেটআপ করা হয়, যাতে সব অভ্যন্তরীণ ডিভাইস একটিমাত্র পাবলিক IP শেয়ার করে ইন্টারনেটে যেতে পারে। এরপর ফায়ারওয়াল নিয়ম (M10/L46) প্রয়োগ করা হয় যা গেস্ট সাবনেট থেকে স্টাফ সাবনেটে যাওয়া ট্রাফিক সম্পূর্ণ ব্লক করে, কিন্তু ইন্টারনেট অ্যাক্সেস অনুমোদিত রাখে। সবশেষে, বিভিন্ন এলাকার জন্য উপযুক্ত ফিজিক্যাল/ওয়্যারলেস মাধ্যম (M2 তারযুক্ত সংযোগ, M8 WiFi) বেছে নেওয়া হয়।

Python
import ipaddress

# ------------------------------------------------------------
# ধাপ ১ — প্রাইভেট IP রেঞ্জ বেছে তিনটি উদ্দেশ্য-ভিত্তিক সাবনেটে ভাগ করা (M4/L14-15)
# ------------------------------------------------------------
network_design = {
    "staff":   {"cidr": "192.168.10.0/24", "purpose": "স্টাফ ডিভাইস (কম্পিউটার, প্রিন্টার)"},
    "guest":   {"cidr": "192.168.20.0/26", "purpose": "গেস্ট WiFi"},
    "servers": {"cidr": "192.168.30.0/28", "purpose": "লোকাল সার্ভার (ফাইল সার্ভার, NAS)"},
}

# ------------------------------------------------------------
# ধাপ ২ — ফায়ারওয়াল/সেগমেন্টেশন পলিসি (M10/L46) — কোন সাবনেট কোথায় যেতে পারবে
# ------------------------------------------------------------
policy_table = {
    "staff":   {"servers", "internet"},
    "guest":   {"internet"},          # গেস্ট শুধু ইন্টারনেট পাবে, স্টাফ/সার্ভার সাবনেটে নয়
    "servers": {"internet"},
}

def check_policy(source_subnet, dest, policy_table):
    """একটি সাবনেট থেকে একটি গন্তব্যে ট্রাফিক অনুমোদিত কি না তা যাচাই করে।"""
    return dest in policy_table.get(source_subnet, set())

# ------------------------------------------------------------
# ডিজাইন সারাংশ প্রিন্ট — প্রতিটি সাবনেটের ব্যবহারযোগ্য হোস্ট গণনা (L15-এর সাবনেটিং গণিত)
# ------------------------------------------------------------
print("নেটওয়ার্ক ডিজাইন সারাংশ:\n")
for name, info in network_design.items():
    net = ipaddress.ip_network(info["cidr"])
    usable_hosts = net.num_addresses - 2  # নেটওয়ার্ক ঠিকানা ও ব্রডকাস্ট ঠিকানা বাদে
    print(f"  {name:8s} | CIDR {info['cidr']:18s} | ব্যবহারযোগ্য হোস্ট: {usable_hosts:3d} | {info['purpose']}")

print("\nফায়ারওয়াল/সেগমেন্টেশন পলিসি যাচাই:")
checks = [("guest", "staff"), ("guest", "internet"), ("staff", "servers"), ("servers", "staff")]
for source, dest in checks:
    allowed = check_policy(source, dest, policy_table)
    print(f"  {source:7s} -> {dest:9s}: {'অনুমোদিত' if allowed else 'ব্লকড'}")

assert check_policy("guest", "staff", policy_table) is False
assert check_policy("guest", "internet", policy_table) is True
print("\nসেগমেন্টেশন সঠিকভাবে কাজ করছে — গেস্ট স্টাফ সাবনেটে পৌঁছাতে পারছে না, কিন্তু ইন্টারনেট পাচ্ছে।")

    
কেন সাবনেট /26 বা /28-এর মতো ভিন্ন আকারের

স্টাফ সাবনেট (/24) সবচেয়ে বড়, কারণ বেশিরভাগ ডিভাইস সেখানে থাকে। গেস্ট সাবনেট (/26) মাঝারি, আর সার্ভার সাবনেট (/28) সবচেয়ে ছোট, কারণ সেখানে কয়েকটি মাত্র নির্দিষ্ট সার্ভার থাকে — প্রতিটি সাবনেটের আকার তার প্রকৃত প্রয়োজনের সাথে মেলানো হয়, অপ্রয়োজনীয়ভাবে বড় সাবনেট না দিয়ে, যা সাবনেটিং-এর (L15) মূল ব্যবহারিক উদ্দেশ্য।

মূল কথা · Key takeaway

একটি বাস্তব নেটওয়ার্ক ডিজাইন একক কোনো প্রযুক্তি নয় — এটি সাবনেটিং, DHCP, NAT ও ফায়ারওয়াল নিয়মের একটি সমন্বিত সিদ্ধান্ত, যেখানে প্রতিটি অংশ এই কোর্সের একটি নির্দিষ্ট আগের পাঠ থেকে আসে। নিরাপত্তা ও ব্যবহারযোগ্যতার ভারসাম্য রক্ষা করতে সেগমেন্টেশন (কে কোথায় পৌঁছাতে পারবে) ডিজাইনের একটি কেন্দ্রীয় সিদ্ধান্ত।

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।

প্র ০১ গেস্ট WiFi-কে কেন একটি সম্পূর্ণ আলাদা সাবনেটে রাখা হয়, স্টাফদের সাথে একই সাবনেটে নয়?

আলাদা সাবনেটে রাখলে ফায়ারওয়াল নিয়মের মাধ্যমে সহজেই গেস্ট ট্রাফিক থেকে স্টাফ রিসোর্স আলাদা করা যায় — যদি একই সাবনেটে থাকত, তাহলে সাধারণত সবাই একে অপরকে সরাসরি দেখতে ও পৌঁছাতে পারত, যা নিরাপত্তার দৃষ্টিকোণ থেকে অগ্রহণযোগ্য।

প্র ০২ NAT না থাকলে এই অফিসের প্রতিটি ডিভাইসের জন্য কী প্রয়োজন হতো?

NAT ছাড়া প্রতিটি ডিভাইসের একটি স্বতন্ত্র পাবলিক IP ঠিকানা প্রয়োজন হতো, যা ব্যয়বহুল ও IPv4 ঠিকানার স্বল্পতার কারণে ব্যবহারিকভাবে কঠিন। NAT একটিমাত্র পাবলিক IP-এর পেছনে পুরো প্রাইভেট নেটওয়ার্ক লুকিয়ে রাখে, যা খরচ কমায় ও কিছুটা অতিরিক্ত নিরাপত্তাও দেয় (বাইরে থেকে সরাসরি অভ্যন্তরীণ ডিভাইসে পৌঁছানো যায় না)।

প্র ০৩ সার্ভার সাবনেটের পলিসিতে শুধু "internet" আছে, "staff" নেই — এর মানে কি স্টাফরা সার্ভারে পৌঁছাতে পারবে না?

না — পলিসি টেবিলটি প্রতিটি সাবনেট থেকে বাইরের দিকে যাওয়ার অনুমতি বর্ণনা করে। স্টাফ সাবনেটের পলিসিতে "servers" আছে, তাই স্টাফ থেকে সার্ভারে যাওয়া অনুমোদিত — কিন্তু সার্ভার সাবনেটের পলিসিতে "staff" না থাকায়, সার্ভার থেকে স্টাফ সাবনেটে সংযোগ শুরু করা ব্লকড, যা একটি সাধারণ ও নিরাপদ ডিজাইন প্যাটার্ন (সার্ভারের নিজে থেকে ক্লায়েন্ট ডিভাইসে সংযোগ শুরু করার দরকার নেই)।

অনুশীলন

  1. চিন্তা করুন: network_design-এ একটি চতুর্থ সাবনেট "iot" (192.168.40.0/29) যোগ করুন — এর ব্যবহারযোগ্য হোস্ট সংখ্যা কত হবে অনুমান করুন, তারপর Run চেপে যাচাই করুন।

    /29-এ মোট ঠিকানা সংখ্যা 2^(32-29) = 8টি, তার মধ্যে নেটওয়ার্ক ও ব্রডকাস্ট ঠিকানা বাদ দিলে ব্যবহারযোগ্য হোস্ট সংখ্যা 8 - 2 = 6টি — কোড রান করলে ঠিক এই সংখ্যাই প্রিন্ট হবে।

  2. পরীক্ষা করুন: policy_table-এ "guest"-এর সেটে "servers" যোগ করুন এবং check_policy("guest", "servers", policy_table) কল করে দেখুন ফলাফল কী আসে — এটি কি নিরাপদ ডিজাইন হবে?

    যোগ করার পর ফলাফল True আসবে — কিন্তু এটি একটি নিরাপত্তা-বিপজ্জনক পরিবর্তন, কারণ এর মানে গেস্ট WiFi-এর যেকোনো ব্যবহারকারী এখন সরাসরি অভ্যন্তরীণ সার্ভারে পৌঁছাতে পারবে — যা সেগমেন্টেশনের মূল উদ্দেশ্যকেই ব্যর্থ করে দেয়। বাস্তব ডিজাইনে এই পরিবর্তন এড়ানো উচিত।

আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ

আগের পাঠ
কেস স্টাডি: নেটওয়ার্ক সমস্যা ডিবাগ করা