আলাদা ইগ্রেস: usb0-তে VPN পুল, eth0-তে গেটওয়ে ট্রাফিক

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

সোর্স ঠিকানাটি রাউটিং সিদ্ধান্ত পর্যন্ত টিকে থাকে কি না নিশ্চিত করুন

সোর্স রেঞ্জের সাথে মেলে এমন নীতি নিয়ম কেবল তখনই কাজ করে যখন প্যাকেটটি লুকআপের সময় সেই সোর্স বহন করে। ফরওয়ার্ড করা ক্লায়েন্ট ট্রাফিক তা করে, যতক্ষণ না রাউটিংয়ের আগে আপস্ট্রিমে কিছু তা পুনর্লিখন করেছে। গেটওয়ে নিজে যে ট্রাফিক তৈরি করে তা করে না, আর ঠিক সেজন্যই গেটওয়ের নিজের ডিফল্ট যেখানে আছে সেখানেই থাকতে পারে।

এখানেই স্থানীয় পরীক্ষা বিভ্রান্ত করে। গেটওয়েতে চালানো curl হলো গেটওয়ের ঠিকানা দিয়ে স্থানীয়ভাবে তৈরি প্রবাহ, তাই এটি মেইন টেবিল নেয় এবং ক্লায়েন্ট পথ সম্পর্কে কিছুই প্রমাণ করে না। সংযুক্ত ক্লায়েন্ট থেকে পরীক্ষা করুন, বা এমন সোর্স দিয়ে ট্রাফিক তৈরি করুন যা সত্যিই পুলের অন্তর্গত।

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

একটি সম্পূর্ণ নির্বাচিত টেবিল তৈরি করুন

টেবিল কোনো বন্ধুসহ ডিফল্ট রুট নয়। এতে যথেষ্ট রুট দরকার যাতে প্রতিটি লুকআপ এর ভেতরেই সমাধান হয়, WAN সাবনেটের সংযুক্ত রুটসহ যাতে পরবর্তী হপ পৌঁছানো যায়। tun1-এ 10.77.0.0/24 পুল, পরবর্তী হপ 203.0.113.1 সহ WAN ঠিকানা 203.0.113.20/24 এবং টেবিল 600-এর জন্য:

ip -4 route replace 203.0.113.0/24 dev usb0 src 203.0.113.20 table 600
ip -4 route replace 10.77.0.0/24 dev tun1 table 600
ip -4 route replace default via 203.0.113.1 dev usb0 table 600
ip -4 rule add priority 1500 from 10.77.0.0/24 lookup 600

নিয়মটি বিদ্যমান যেকোনো ক্যাচ-অল নিয়মের নিচে প্রায়োরিটিতে বসে, তাই মেলা ক্লায়েন্টরা আগে টেবিল 600-এ পৌঁছায় আর বাকি সব মেইন টেবিলে নেমে যায়। ip-rule রেফারেন্স ক্রমানুসারে লুকআপ মডেল ও সিলেক্টর সিনট্যাক্স সম্পূর্ণ বর্ণনা করে।

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

শ্রোতার নিজের ট্রাফিক নীতির বাইরে রাখুন

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

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

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

ফরওয়ার্ডিং ও অনুবাদকে রুটের সাথে মিলিয়ে নিন

রাউটিং একটি আপলিঙ্ক নির্বাচন করে; এটি ফরওয়ার্ড করার অনুমতি দেয় না। কার্নেলে IPv4 ফরওয়ার্ডিং চালু থাকতে হবে, আর ফায়ারওয়ালকে ক্লায়েন্ট-থেকে-WAN দিক ও ফেরার ট্রাফিক গ্রহণ করতে হবে। সঠিক টেবিলের সাথে ফ্লো ফেলে দেওয়া FORWARD চেইন একটি অনুপস্থিত রুটের মতোই লক্ষণ দেয়, তাই দুটোই একসাথে যাচাই করা হয়।

দ্বিতীয় WAN যদি ব্যক্তিগত পুলকে আপনার দিকে ফেরত রাউট না করে, তবে সেই ইগ্রেসে সোর্স অনুবাদ করুন। গতিশীল ঠিকানার ইন্টারফেসের জন্য পুল ও ইন্টারফেসে সীমাবদ্ধ সংকীর্ণ masquerade নিয়মই সাধারণ পছন্দ:

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -o usb0 -j MASQUERADE

এখানে লক্ষ্যের চেয়ে পরিধি বেশি গুরুত্বপূর্ণ। যেকোনো আউটবাউন্ড ইন্টারফেসে মেলা masquerade নিয়ম eth0 দিয়ে সঠিকভাবে যাওয়া ট্রাফিকও পুনর্লিখন করবে, যা রাউটিং ভুল ঠিক করার বদলে লুকিয়ে ফেলে। অনুবাদ রাউটিং সিদ্ধান্তের পরে চলে, তাই ভুল আপলিঙ্কে পাঠানো প্যাকেট কখনো সারাতে পারে না।

পথ আলাদা হলে টানেল ওভারহেডও মনোযোগ দাবি করে। ক্লায়েন্টরা বড় TCP MSS-এ সম্মত হলে এবং বিকল্প WAN-এর MTU কম হলে বা তার ভেতরে টানেল থাকলে, বড় সেগমেন্ট আটকে যায় আর ছোটগুলো কাজ করে। ফরওয়ার্ডিং পথে MSS ক্ল্যাম্প করলে তা মাঝেমধ্যে ঝুলে যাওয়ার বদলে পূর্বানুমেয় আচরণে পরিণত হয়।

usb0 হারিয়ে গেলে কী হবে তা ঠিক করুন

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

যেখানে এই ফলব্যাক অগ্রহণযোগ্য, সেখানে টেবিল 600-এ একটি স্পষ্ট টার্মিনাল রুট যোগ করুন, যেমন blackhole ডিফল্ট, অথবা ইন্টারফেস বন্ধ থাকা অবস্থায় ফায়ারওয়ালে পুলটি ফেলে দিন। দুটির যেকোনোটি এমন সিদ্ধান্ত যা আপনি লিখে রাখতে পারেন; নীরবতা নয়।

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