VPN সার্ভারের জন্য ক্লাউড ফায়ারওয়াল বনাম হোস্ট ফায়ারওয়াল

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

প্রান্ত থেকে শুরু করে ভেতরের দিকে হাঁটুন

ক্রমটি নির্দিষ্ট: পাবলিক এন্ডপয়েন্ট, রিসোর্স ইন্টারফেস, সংযুক্ত ক্লাউড নীতি, গেস্ট ঠিকানা, প্রসেস লিসেনার, স্থানীয় ইনপুট নিয়ম। প্রতিটি ধাপ হয় প্যাকেটটি পার করে, নয় তদন্ত শেষ করে, তাই গেস্ট থেকে শুরু করলে সবচেয়ে বেশি সময় নষ্ট হয়।

ফরোয়ার্ড করা ক্লায়েন্ট ট্রাফিক আলাদা ধাপ, যা টানেল ডিক্যাপসুলেট হওয়ার পরে দেখা হয়। ক্লাউড স্তর কেবল বাইরের টানেল দেখে, তাই এটি একটি সংযোগ অনুমোদন করেও ভেতরের কোনো সেবা অনুরোধের সঙ্গে কোনো সম্পর্ক না রাখতে পারে। যে টানেল সংযুক্ত হয় কিন্তু ভেতরের হোস্টে পৌঁছায় না, তা সাধারণত ফরোয়ার্ডিংয়ের দিকে ইঙ্গিত করে, বন্ধ পোর্টের দিকে নয়।

গেস্ট স্পর্শ করার আগে ক্লাউড নীতি পড়ুন

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

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

প্রথমে লিসেনার, তারপর ইনপুট চেইন নিশ্চিত করুন

ইনস্ট্যান্সে দেখুন VPN প্রসেসটি প্রত্যাশিত ঠিকানা ও পোর্টে বাইন্ড করা আছে কি না, যেমন ss -lntp 'sport = :1194' দিয়ে। কেবল 127.0.0.1-এ বাইন্ড করা ডেমন স্থানীয় ক্লায়েন্ট গ্রহণ করে এবং টানেল দিয়ে কিছুই নয়, যা বাইরে থেকে হুবহু ফিল্টার করা পোর্টের মতো দেখায়।

তারপর স্থানীয় নিয়মগুলো সেসব সিনট্যাক্সে পড়ুন যা আপনি সেগুলো পরিবর্তন করতে ব্যবহার করতেন, যেমন iptables -S INPUT বা nft list chain inet filter input। ফাইলে লেখা কিন্তু কখনো লোড না করা নিয়ম, বা মিলে যাওয়া অনুমোদন ছাড়া ডিফল্ট ড্রপ, প্যাকেটগুলো নীরবে ফেলে দেয়। ফরোয়ার্ডিং গেটওয়ের জন্য ফরোয়ার্ডিং ও রিভার্স-পাথ সেটিংসও দেখুন। ইনস্ট্যান্সে ঠিকানা দেওয়া নয় বরং এর মধ্য দিয়ে রুট করা প্যাকেটের কী হবে, তা এগুলোই ঠিক করে।

এক স্তরে স্টেটফুল, পরের স্তরে স্টেটলেস

সিকিউরিটি গ্রুপ মনে রাখে কোন প্রবাহগুলো তারা অনুমোদন করেছে এবং উত্তরগুলো ফিরে আসতে দেয়। সাবনেট অ্যাক্সেস কন্ট্রোল লিস্ট ও অনেক হোস্ট ফায়ারওয়াল এমন অবস্থা রাখে না, তাই কেবল আউটবাউন্ড দিক ঢাকা নিয়ম অনুরোধটি পার করে উত্তরটি ফেলে দেয়। দ্বিতীয় স্তরের নিয়ম না পড়ে স্তরগুলোর মধ্যে রিটার্ন-ট্রাফিকের অনুমান কখনো বহন করবেন না (second layer's rule)।

অ্যাকাউন্টের প্রতিটি নিয়ম পড়ার চেয়ে কাউন্টার দ্রুত বিষয়টি ঠিক করে। বাড়তে থাকা কাউন্টার বোঝায় প্যাকেট সেখানে পৌঁছেছে ও সেখানেই ফেলা হয়েছে, আর শূন্যে জমে থাকা কাউন্টার বোঝায় এটি সেখানে পৌঁছায়ইনি; নিয়মগুলো কাউন্টারসহ লোড করা থাকলে iptables -vnL INPUT ও nft list ruleset সেই সংখ্যাগুলো দেখায়।

সক্রিয় নয়, নতুন সেশন দিয়ে পরীক্ষা করুন

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

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