একটি NIC নাকি দুটি? VPN সার্ভারের ইন্টারফেস বিন্যাস নির্ধারণ

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

যে তিনটি শর্ত এটি ঠিক করে

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

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

তিনটির কোনোটিই চেসিসের পোর্ট সংখ্যা নিয়ে নয়। এগুলো রাউটিং, ঠিকানার মালিকানা এবং নকশাটি ভৌত পৃথকীকরণের উপর কতটা নির্ভর করে তা নিয়ে।

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

যখন সেবাটি VPN হোস্টেই চলে

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

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

ss -lntup | grep -E "5432|8080"
ip -brief addr show
ip route get 10.8.0.6 from 10.8.0.1

সেবাকে কেবল পাবলিক ঠিকানায় বাঁধলে, বা ভুলবশত টানেল ইন্টারফেস ফিল্টার করলে, এমন সংযোগ তৈরি হয় যা হোস্টে পৌঁছে তারপর মরে যায়। এটি VPN-এর ত্রুটির মতো দেখায় এবং সাধারণত সকেট বা ফায়ারওয়ালের সিদ্ধান্ত।

যখন গন্তব্য LAN-এ থাকে

এখানেই একক-অ্যাডাপ্টার নকশা জটিল হওয়ার সুনাম পায়। সার্ভারকে ক্লায়েন্টের প্যাকেট LAN-এর দিকে ফরওয়ার্ড করতে হয়, আর LAN ডিভাইসকে উত্তর ক্লায়েন্ট পুলে ফেরত পাঠাতে হয়। হয় আপনি ওই পুলটি LAN-এ রুট হিসেবে বহন করেন, নাকি সার্ভারে উৎস ঠিকানার অনুবাদ করেন যাতে উত্তর সার্ভারেই ফিরে আসে।

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

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A4 'chain forward'
ip route show table main | grep 10.8.0

অসমমিত পথই ক্লাসিক লক্ষণ: ক্লায়েন্টের অনুরোধ আসে, উত্তর ভিন্ন রাউটার দিয়ে বেরিয়ে যায়, আর সংযোগ কোনো প্রান্তে ত্রুটি ছাড়াই সময় শেষে বন্ধ হয়। টানেল সম্পর্কে কিছু সিদ্ধান্তে আসার আগে দুই দিকেই ক্যাপচার করুন।

কেন অ্যালিয়াস দ্বিতীয় জোন তৈরি করে না

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

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

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

আপনি যে ট্রাফিক অনুমোদন করেন তার সঙ্গে বিন্যাস মিলিয়ে দেখুন

সার্ভারকে যে ট্রাফিক শ্রেণি বহন করতে হবে তা তালিকাভুক্ত করুন: ক্লায়েন্ট থেকে হোস্ট, ক্লায়েন্ট থেকে LAN, হোস্ট থেকে LAN, এবং এনক্রিপ্টেড বহিরাগত সংযোগ। প্রতিটি শ্রেণির একটি উৎস, একটি গন্তব্য ও একটি ইন্টারফেস আছে, আর বিন্যাসকে চারটিই একসঙ্গে পূরণ করতে হবে। যে নকশা তিনটি সামলায়, সাধারণত সেটিই টিকিট তৈরি করে।

তারপর নকশা নথির চিত্র নয়, প্রকৃত ইন্টারফেস ও প্রকৃত ক্যাপচার নিশ্চিত করুন। নিচের কমান্ড দুটি দৃশ্যই ছাপে।

ip -brief addr
ip route
tcpdump -ni any udp port 51820 -c 5
tcpdump -ni tun0 -c 5

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