ব্রিজ করা OpenVPN ক্লায়েন্টে ইন্টারনেট নেই? NAT নিয়মটি যাচাই করুন

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

প্রমাণ কাউন্টার, টেবিলের লাইন নয়

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

iptables -t nat -L POSTROUTING -v -n

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

কার্নেল আসলে যে নাম লিখে রাখে, সেটি খুঁজুন

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

ip -brief link

নামটি লিখে রাখুন। এই ডায়াগনোসিসের প্রতিটি পরবর্তী কমান্ড এটির উল্লেখ করে, আর এখানে একটি টাইপো মূল ভুলটির মতোই ঠিক একই শূন্য কাউন্টার তৈরি করবে।

টানেল ডিভাইসের বিপরীতে নিয়মটি নতুন করে লিখুন

নিয়মটি টানেল ডিভাইসের দিকে নির্দেশ করুন এবং ক্লায়েন্ট রেঞ্জকে তার ম্যাচ শর্ত হিসেবে রাখুন, যাতে এটি টানেল ট্রাফিক ঢাকে এবং হোস্টের নিজের সংযোগগুলোকে অক্ষত রাখে। নিজের রেঞ্জ ও ডিভাইসের নাম বসান, কারণ নিচের দুটিই উদাহরণ এবং কোনোটি ইনস্টলেশনের মধ্যে বহনযোগ্য নয়।

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tap0 -j MASQUERADE

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

কাউন্টারসহ forward চেইন পড়তে একটি কমান্ডই লাগে এবং আরেকটি নিয়ম স্পর্শ করার আগেই বাকি অর্ধেক সম্ভাবনা বাদ দেয়।

কেন ফিজিক্যাল কার্ড কখনো মেলে না

ব্রিজ হল tap ডিভাইস ও একটি ফিজিক্যাল ইন্টারফেস দিয়ে গড়া সফটওয়্যার সুইচ। ক্লায়েন্ট ফ্রেম ওই সুইচে ঢোকে এবং কার্ডের প্যাকেট হিসেবে নয়, ব্রিজের সদস্য হিসেবে ফিজিক্যাল নেটওয়ার্কের দিকে বের হয়। তাই কার্নেল প্যাকেটটি ব্রিজ ও তার পোর্টের নামে আরোপ করে, আর এই কারণেই আপনার মনে থাকা কার্ডটি ম্যাচে কখনো দেখা যায় না। ফিজিক্যাল ইন্টারফেসে কিছুই নষ্ট হয়নি; এটি শুধু সেই ডিভাইস নয় যা কার্নেল ওই প্যাকেটের জন্য নির্ধারণ করে।

এরপর মানুষ যে সমস্যায় পড়ে, সেটি একই গঠন থেকে আসে: ব্রিজে ফ্রেম ফিল্টারিং IP ফিল্টারিং থেকে আলাদা ব্যবস্থা। যদি প্রয়োজন ফ্রেম-স্তরের সীমাবদ্ধতা হয়, তবে তা ব্রিজ ফিল্টারিংয়ের অন্তর্গত, IP টেবিলের নিয়মের নয়.

শুরু থেকে শেষ পর্যন্ত প্রমাণ করুন, তারপর স্থায়ী করুন

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

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

নতুন করে লেখার পরেও কাউন্টার না নড়লে, নিয়মের সোর্স রেঞ্জের সঙ্গে ক্লায়েন্ট আসলে যে ঠিকানা পেয়েছে তা মিলিয়ে দেখুন, কারণ ব্রিজ করা সার্ভার আপনার অনিচ্ছাকৃত রেঞ্জ থেকে ঠিকানা দিতে পারে।