nginx ভাঙার আগেই OpenVPN SNAT নিয়মের পরিধি নির্ধারণ করুন

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

নিশ্চিত করুন যে কন্টেইনারটি একটি tun ডিভাইস তৈরি করতে পারে

টানেল ইন্টারফেস তৈরি হতে না পারলে আর কিছুই গুরুত্বপূর্ণ নয়। যাচাই করুন যে /dev/net/tun উপস্থিত এবং একটি পরীক্ষামূলক ডিভাইস তৈরি সফল হয়, কারণ অনেক প্রদানকারী ডিফল্টভাবে কন্টেইনারের ভিতরে tun নিষ্ক্রিয় রাখে। কখনও তৈরি হয়নি এমন ডিভাইসের জন্য কোনো firewall কাজই ক্ষতিপূরণ দেয় না।

ডিভাইসটি না থাকলে কেবল হোস্ট বা প্রদানকারীই এটি সক্রিয় করতে পারে। একটি ভিন্ন প্ল্যান প্রায়শই সপ্তাহব্যাপী খোলা সহায়তা থ্রেডের চেয়ে সস্তা। OpenVPN লগের একটি লাইনও পড়ার আগে এটি নিশ্চিত করুন। নাহলে আপনি সন্ধ্যাটি এমন নিয়ম টিউন করতে কাটাবেন যা কখনও প্যাকেট দেখবে না।

এই ইন্টারফেসে MASQUERADE কী করে তা নির্ধারণ করুন

একটি সাধারণ ভার্চুয়াল মেশিনে স্বাভাবিক ইগ্রেস নিয়মটি হলো POSTROUTING MASQUERADE যা মূল ইন্টারফেস থেকে বেরোয়। OpenVZ কন্টেইনারে দৃশ্যমান ডিভাইসটি প্রায়শই venet0, অর্থাৎ হোস্ট-পরিচালিত ভার্চুয়াল ইন্টারফেস, রাউটেড NIC নয়, এবং MASQUERADE সেখানে টিউটোরিয়ালে ধরে নেওয়া মতো সবসময় আচরণ করে না।

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

iptables -t nat -A POSTROUTING -o venet0 -s 10.8.0.0/24 -j SNAT --to-source 203.0.113.10
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

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

নিয়মটি একটি পুল ও একটি ইন্টারফেসে সীমাবদ্ধ করুন

দ্বিতীয় লক্ষণের কারণ ভিন্ন: উৎস বা আউটপুট কোনো বিধিনিষেধ ছাড়া একটি POSTROUTING নিয়ম। এমন নিয়ম হোস্ট ছেড়ে যাওয়া প্রতিটি প্যাকেট পুনর্লিখন করে।

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

সমাধান হলো মিলটি টানেল পুল ও ইগ্রেস ইন্টারফেসে সংকুচিত করা, তারপর একাধিক কভার করতে একটি নিয়ম প্রশস্ত করার বদলে প্রতি পুলে একটি করে নিয়ম যোগ করা।

নিয়মগুলো স্থায়ী করুন এবং জানুন আর কে তাদের মালিক

হাতে যোগ করা নিয়ম রিবুটে হারিয়ে যায়, তাই সেগুলো iptables-save দিয়ে সংরক্ষণ করুন বা যেখানে ইনস্টল আছে সেখানে netfilter-persistent দিয়ে পরিচালনা করুন। পুনরুদ্ধার OpenVPN শুরুর আগে চলে তা নিশ্চিত করুন। তারপর কোনো ঘটনার সময় ফাঁকটি আবিষ্কার করার বদলে ইচ্ছাকৃতভাবে একবার রিবুট করুন।

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

কাউন্টার ও একটি ধৃত ফ্লো দিয়ে যাচাই করুন

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

সার্ভারে iptables -t nat -L -v -n দিয়ে NAT ও FORWARD নিয়মের প্যাকেট কাউন্টার পড়ুন এবং একটি ক্যাপচারে একটি ফ্লো দেখুন। যদি ক্যাপচারে ক্লায়েন্টের ঠিকানা দেখা যায় এবং কোনো উত্তর না আসে, ফাঁকটি ফেরার পথে বা প্রদানকারীর ফিল্টারিংয়ে, ক্লায়েন্ট প্রোফাইলে নয়। ধৃত উৎসটি নিয়ম যে ঠিকানায় অনুবাদ করে তার সঙ্গে তুলনা করুন, কারণ অমিল মানে অন্য একটি নিয়ম আগে মিলেছে। একটি পর্যবেক্ষিত ফ্লো এক পাতার কনফিগারেশন পড়ার চেয়ে বেশি কিছু নিষ্পত্তি করে।

পুল, অনূদিত ঠিকানা এবং ইন্টারফেসের নাম পরিবর্তন রেকর্ডে একসঙ্গে রাখুন। একটি পুলের জন্য সঠিক নিয়ম পরেরটিকে ভুল অনুবাদ করে।