একটি OpenVPN ক্লায়েন্টে দুটি পরিষেবা ঠিকানা: iroute এবং lo

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

উপনামটি স্থানীয়, মালিকানা দূরবর্তী

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

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

আপনার নোটেও দুটি পরিসর আলাদা রাখুন। উদাহরণের ঠিকানাগুলো নথিকরণের মান, আর সেগুলোকে বাস্তব LAN-এর সঙ্গে ওভারল্যাপ করানোই কাজ করা ব্যবস্থাকে ভাঙা দেখানোর দ্রুততম উপায়।

ক্লায়েন্টে ঠিকানাটি স্থায়ীভাবে যোগ করুন

পরিষেবা ঠিকানাটি লুপব্যাকে হোস্ট প্রিফিক্সসহ রাখুন, যাতে হোস্ট এটিকে পৌঁছানোর সাবনেট নয় বরং স্থানীয় ইনপুট হিসেবে ধরে। ip address add 10.66.0.10/32 dev lo একটি ঠিকানার জন্য তা করে, আর দ্বিতীয় ঠিকানার জন্য কমান্ডটি পুনরাবৃত্তি করলে দুটি পরিষেবা মডেল হয়।

এটি একবারের পরীক্ষা হিসেবে চালান, তারপর হোস্টের নেটওয়ার্ক কনফিগারেশনের মালিক যা তার মধ্যে সরিয়ে নিন, কারণ রানটাইমে যোগ করা কিছু রিবুটে হারিয়ে যায় আর পুনঃসংযোগে নকল জমে। নেটওয়ার্কের পরে ক্রমসজ্জিত একটি systemd ইউনিট একটি বিকল্প, আর ডিস্ট্রিবিউশনের নেটওয়ার্ক ম্যানেজার আরেকটি। যা-ই বেছে নিন, অ্যাপ্লিকেশন বাঁধার আগে ঠিকানাটি থাকতেই হবে, নয়তো পরিষেবা ভুল সকেটে ওঠে। ম্যানুয়াল কমান্ডের পরে নয়, রিবুটের পরে ip address show dev lo দিয়ে যাচাই করুন।

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

হাব সত্যিই যে CCD ফাইল পড়ে সেখানেই এটি দাবি করুন

সার্ভারে মালিকানার ঘোষণাটি প্রমাণীকৃত সাধারণ নাম দ্বারা নির্বাচিত প্রতি-ক্লায়েন্ট ফাইলে যায়, client-config-dir দ্বারা নামকৃত ডিরেক্টরির ভিতরে। লাইনটি iroute 10.66.0.10 255.255.255.255, প্রতি ঠিকানায় একটি, এবং এটি সার্ভারকে বলে কোন পিয়ার ওই গন্তব্যের ট্রাফিক পাবে।

দুটি খুঁটিনাটি এটি নিঃশব্দে ভাঙে। ফাইলের নামটি সার্ভার সত্যিই যে নাম ব্যবহার করে তার সঙ্গে মিলতে হবে, যা username-as-common-name চালু থাকলে আলাদা হয়। আর iroute কেবল TUN মোডে ক্লায়েন্ট কনফিগারেশন ডিরেক্টরি কনফিগার থাকলে কাজ করে, তাই একই লাইন ব্রিজড স্থাপনায় কিছুই করে না। বিদ্যমান ফাইলে লাইন যোগ করুন, এটি প্রতিস্থাপন করবেন না, কারণ এতে ইতিমধ্যে একটি স্থির ঠিকানা বা push অপশন থাকতে পারে। OpenVPN 2.6 রেফারেন্স ডিরেক্টরি ও মালিকানা নির্দেশিকা দুটিই নথিভুক্ত করে।

হাবের নিজের কার্নেলেরও ওই গন্তব্যগুলোর পথ দরকার যাতে স্থানীয়ভাবে উৎপন্ন ট্রাফিক টানেল প্রক্রিয়ায় ঢোকে। সার্ভার কনফিগারেশনে route 10.66.0.10 255.255.255.255 সার্ভার নিজে যে ট্রাফিক তৈরি করে তা ঢাকে, আর অন্য ক্লায়েন্টদের গন্তব্যটি নিজে জানতে push "route 10.66.0.10 255.255.255.255" দরকার।

রাউটিং ও অনুমোদন আলাদা থাকে। ধাক্কানো রুট একটি ক্লায়েন্টকে বলে প্যাকেট কোথায় পাঠাবে আর কিছুই মঞ্জুর করে না; পরিষেবাকে এখনও তার নিজের শর্তে কলারকে গ্রহণ করতে হয়।

ইনপুট নীতি ও ফিরতি পথ যাচাই করুন

উপনামে ঠিকানা দেওয়া প্যাকেট মালিক হোস্টে স্থানীয় ইনপুট হিসেবে পৌঁছায়, তাই প্রশ্ন হলো স্থানীয় ফায়ারওয়াল ওই উৎস ও পোর্ট অনুমোদন করে কি না। পুরো ঠিকানা খোলার বদলে VPN উৎস পরিসর থেকে নির্দিষ্ট পরিষেবা পোর্ট অনুমোদন করুন।

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

একই পোর্টে ভিন্ন ঠিকানায় বাঁধা দ্বিতীয় শ্রোতার দিকে খেয়াল রাখুন, কারণ কার্নেল যে সকেট মেলে সেখানেই পৌঁছে দেয় আর ফলাফল এলোমেলো দেখায়। ss -lntp দিয়ে যাচাই করুন এবং বাঁধা ঠিকানাটি পরিষেবা উপনাম কি না নিশ্চিত করুন। এখানে সোর্স NAT দরকার নেই, আর এটি যোগ করলে আপনার লগ যে কলার পরিচয়ের উপর নির্ভর করে তা লুকিয়ে যায়।

ঠিকানা ও মালিকানা আলাদাভাবে পরীক্ষা করুন

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

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