আপনার হটস্পটের ফায়ারওয়াল লিজের আগেই DHCP আটকে দেয়

নতুন ফোন আপনার হটস্পটে যোগ দেয়, কোনো ঠিকানা দেখায় না, আর কখনোই একটি পায় না। অ্যাক্সেস পয়েন্ট ঠিক আছে, DHCP ডিমন চলছে, এবং আপনি যে ফায়ারওয়াল নিয়মটি লিখেছেন তা ঠিকানা পরিকল্পনার সঙ্গে সামঞ্জস্যপূর্ণ দেখায়। আসলে এটি দাবি করে যে ক্লায়েন্টের কাছে ইতিমধ্যেই সেই ঠিকানাটি আছে যা সে চাইছে। প্রথম DHCP প্যাকেটে কোনো ঠিকানাই নেই, তাই নিয়মটি কখনোই কাজ করে না।

একটি ক্লায়েন্টের যোগ দেওয়া দেখুন

ক্লায়েন্টের দিক থেকে একটি অ্যাসোসিয়েশন অনুসরণ করুন। রেডিও অ্যাসোসিয়েট করে, ক্লায়েন্ট DHCP ডিসকভারি পাঠায়, সার্ভার অফার দেয়, ক্লায়েন্ট অনুরোধ করে, সার্ভার স্বীকৃতি দেয়, এবং কেবল তখনই ক্লায়েন্টের কাছে অন্য কিছুর জন্য ব্যবহারযোগ্য ঠিকানা থাকে।

সেই চূড়ান্ত স্বীকৃতির আগে যা কিছু ঘটে তা ঘটে যখন ক্লায়েন্ট সাধারণ ট্রাফিকের জন্য গেটওয়ে ব্যবহার করতে পারে না। সাবনেট নিয়ম যে জানালাটি ভুলে যায় সেটিই এটি।

প্রথম প্যাকেটে আসলে কী থাকে

RFC 2131 নির্ধারণ করে যে ক্লায়েন্ট ঠিকানা পাওয়ার আগে তার DHCP সম্প্রচার শূন্য উৎস ঠিকানা ব্যবহার করে। ক্লায়েন্ট থেকে সার্ভারে বার্তা যায় UDP পোর্ট 67-এ, আর সার্ভার থেকে ক্লায়েন্টে বার্তা যায় UDP পোর্ট 68-এ। তাই ডিসকভারি 0.0.0.0 উৎস নিয়ে আসে, এবং আপনার ক্লায়েন্ট সাবনেটের ভিতরে উৎস দাবি করা নিয়মটি তার সঙ্গে সহজভাবে মেলে না।

এটি ক্লায়েন্টের দিকের ভুল কনফিগারেশন নয়। এটি প্রোটোকল, যেভাবে ডিজাইন করা হয়েছে সেভাবেই কাজ করছে, একমাত্র সেই জানালায় যেখানে এটি সম্ভব।

কোন পথটি আসলে এটি সামলায়

যদি অ্যাক্সেস পয়েন্ট নিজেই লিজ দেয়, তবে এটি স্থানীয় সেবার কথোপকথন, এবং IP-ফিল্টার করা স্থানীয় পথে এটি ইনপুট ও আউটপুট নীতির বিষয়। VPN দিয়ে ফরওয়ার্ড করা ক্লায়েন্ট ট্রাফিক অন্য সিদ্ধান্ত, আর সেই ট্রাফিকের NAT আবার আলাদা। এই তিনটিকে গুলিয়ে ফেলাই সংকীর্ণ ব্যতিক্রমকে প্রশস্ত করে তোলে।

প্যাকেট কোথায় সামলানো হয় তা নির্ভর করে ডিমন এবং ব্যবহৃত ফায়ারওয়াল পরিবারের উপর। কাঁচা সকেট বাস্তবায়ন, ব্রিজ ব্যবস্থা এবং আগের ফিল্টার হুক এটি সম্পূর্ণ ভিন্ন জায়গায় সরাতে বা আটকাতে পারে। নিয়ম যোগ করার আগে ডিমনের ইন্টারফেস বাইন্ডিং এবং সক্রিয় হুক নিশ্চিত করুন।

ফোরাম থেকে কপি করা একটি সাধারণ ইনপুট/আউটপুট রেসিপি এই প্রমাণ নয় যে আপনার বাস্তবায়ন একইভাবে সেই চেইনগুলো অতিক্রম করে।

উত্তর সবসময় সম্প্রচার হয় না

শুধু সম্প্রচার উত্তর অনুমোদন করা ব্যতিক্রমও ভুল। DHCP উত্তরের গন্তব্য নির্ভর করে ক্লায়েন্টের অবস্থা ও বার্তার ক্ষেত্রের উপর, এবং প্রোটোকল সম্প্রচার ও ইউনিকাস্ট—দুই ক্ষেত্রেই উল্লেখ করে। যদি আপনার সার্ভার এমন ঠিকানায় ইউনিকাস্টে উত্তর দেয় যা সে দিতে যাচ্ছে, তবে শুধু-সম্প্রচার নিয়ম কাজটি শেষ করার ধাপটিই আটকে দেয়। কনফিগার করা সার্ভার আসলে যে বিনিময় করে, তার বিরুদ্ধেই নিয়মটি লিখুন।

পরবর্তী লিজ নবায়নগুলো ভিন্ন অবস্থায় বিনিময়টি পুনরাবৃত্তি করে, তাই শুধু প্রথম যোগ দেওয়ার জন্য নয়, সেগুলোর জন্যও জায়গা রাখুন।

সংকীর্ণভাবে ঠিক করুন, তারপর বাকিটা দেখুন

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

টেবিল ফ্লাশ করা DHCP কনফিগারেশনের ধাপ নয়। iptables-এ flush নির্বাচিত চেইন বা টেবিল থেকে নিয়ম মুছে দেয়, আর NAT টেবিল ফ্লাশ করলে অনুবাদ নিয়ম তৈরি হয় না। বিস্তৃত ACCEPT নীতি বসানো লিজের সঙ্গে সম্পর্কহীন সুরক্ষা সরিয়ে দেয়, তাই দুটির কোনোটিই পুনর্ব্যবহারযোগ্য হটস্পট সমাধানে পড়ে না।

ক্লায়েন্ট লিজ পেয়ে গেলে DNS, ফরওয়ার্ডিং এবং VPN নির্গমন আলাদা কাজ হিসেবে দেখুন। লিজ শুধু স্থানীয় ঠিকানাকরণ প্রতিষ্ঠা করে, তার বেশি কিছু নয়।