স্টেটলেস VPN এজ ফায়ারওয়ালে DNS উত্তর কেন ব্যর্থ হয়

টানেল চালু আছে, ক্লায়েন্টরা VPN হোস্টে পৌঁছাতে পারে, কিন্তু হোস্ট কিছুই রিজলভ করতে পারে না। এর নিজের আউটবাউন্ড কোয়েরিগুলো ইন্টারফেস ছেড়ে পরিষ্কারভাবে বেরিয়ে যায়, তাই ব্যর্থতা ফেরার পথে: একটি আপস্ট্রিম এজে, যা ইনকামিং ট্রাফিক ফিল্টার করে অথচ হোস্ট এইমাত্র কী পাঠিয়েছে তার কোনো স্মৃতি রাখে না। টানেল পোর্টের অনুমতি ওই বিনিময়কে আদৌ বর্ণনা করে না। DNS কোয়েরির উত্তর আলাদা একটি ফ্লো, এবং এজ যদি স্টেটলেস হয়, তবে ফিরে আসার অনুমতি তাকে কিছুই দেয়নি।

দুটি বিনিময় একই বিনিময় নয়

টিউপলগুলো লিখে ফেলুন, ভুলটা স্পষ্ট হয়ে যাবে। রিকোয়েস্টের ডেস্টিনেশন পোর্ট হয়ে যায় উত্তরের সোর্স পোর্ট, যা বেশিরভাগ মানুষ পোর্ট 53-এর জন্য ইনবাউন্ড নিয়ম যোগ করার সময় যা ভাবেন তার ঠিক উল্টো:

query:  203.0.113.10:53018 -> 198.51.100.53:53
reply:  198.51.100.53:53 -> 203.0.113.10:53018

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

স্টেটলেস এজ বনাম স্টেটফুল হোস্ট ফায়ারওয়াল

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

তুলনাটি গুরুত্বপূর্ণ কারণ দুটি ডিভাইস ভিন্নভাবে ব্যর্থ হয়। যে স্টেটফুল ফায়ারওয়াল উত্তরটি অস্বীকার করে সে ড্রপ লগ করে; স্টেটলেস এজ নীরবে তা অস্বীকার করে, তাই হোস্ট কেবল টাইম আউট হয়।

পোর্ট নম্বর নয়, প্রোটোকলকে ঘিরে অনুমতিটি গড়ুন

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

তারপর নিশ্চিত করুন পথের কোন পণ্যটি আসলে ট্রাফিক ফিল্টার করছে। নথিভুক্ত IPv4 এজ স্কোপ IPv6 নীতি প্রতিষ্ঠা করে না, আর প্রদানকারীর অভ্যন্তরীণ ট্রাফিক হয়তো ওই ফিল্টার দিয়ে কখনোই যায় না।

যেকোনো সোর্স পোর্ট 53 অনুমতি দেওয়া কেন সমাধান নয়

যে নিয়ম সোর্স পোর্ট 53 দাবি করা যেকোনো কিছু গ্রহণ করে, তা এমন নিয়ম যা প্রেরক হেডার ফিল্ডে যা লেখে তাই গ্রহণ করে। পোর্ট নম্বর প্রেরককে প্রমাণীকরণ করে না এবং পেলোড বৈধ উত্তর তা প্রমাণ করে না, তাই নিয়মটি রিজলভিংকে আরও নির্ভরযোগ্য না করেই হোস্টের ঝুঁকি বাড়ায়। সোর্স সীমাবদ্ধতা এবং ক্লায়েন্টের নিজের উত্তর-যাচাই, সোর্স-পোর্ট র‍্যান্ডমাইজেশনসহ, অ্যাক্সেস লিস্ট সরল করতে বন্ধ না করে ধরে রাখুন।

রিজলভার যদি আপনার নিয়ন্ত্রিত সার্ভিস হয়, তবে তার ঠিকানায় সীমাবদ্ধ করাই যথেষ্ট। যদি এটি পাবলিক রিজলভার হয়, তবে আপনি যে ঠিকানাগুলো অনুমোদন করেছেন সেগুলোতে সীমাবদ্ধ করুন এবং নিয়মের মন্তব্যে সেগুলো লিখুন।

সঠিক সীমানায়, সঠিক দিকে যাচাই করুন

একই কোয়েরির জন্য হোস্টে এবং এজে ক্যাপচার করুন, আর প্যাকেট সংখ্যা নয় টিউপল তুলনা করুন। দুই পাশেই দৃশ্যমান অথচ হোস্টের দিকে কোনো উত্তর দেখা যাচ্ছে না এমন কোয়েরি ইনবাউন্ড ফিল্টারের দিকে ইঙ্গিত করে; কেবল হোস্টের দিকে দৃশ্যমান কোয়েরি রাউটিং বা রিজলভারকেই ইঙ্গিত করে। শুধু UDP অনুমতি থাকলে TCP কোয়েরি দিয়ে পুনরাবৃত্তি করুন, কারণ প্রথম পরীক্ষা যে ফাঁকটি দেখতে পারে না সেটিই তা।

এটি ঠিক করা হোস্টের সত্যিই প্রয়োজনীয় একটি DNS বিনিময় সম্পূর্ণ করে। এটি হোস্টকে পাবলিক রিজলভার বানায় না, ফরওয়ার্ড করা VPN ফ্লো অনুমোদন করে না, কিংবা DNS-ই কোনো অসংলগ্ন টানেল সমস্যার কারণ ছিল তা প্রমাণ করে না।