একটি Pi-তে দুটি VPN হপ: কোন রুট কোন পিয়ার বহন করে
একটি Pi-তে দুটি টানেল ঠিকানা কোনো ত্রুটি নয়। প্রতিটি গন্তব্যের নিজস্ব বাহক, নিজস্ব প্রমাণ এবং বাইরের হপ মরে গেলে ঘোষিত ফলব্যাক দরকার।
একটি ছোট বোর্ডে দুটি টানেল ঠিকানা ভুলের মতো দেখায়, আর প্রতিক্রিয়া হলো একটি মুছে ফেলা। সেই প্রতিক্রিয়া যা গুছানোর কথা ছিল তাকেই ভাঙে। দুটি হপ বহনকারী একটি হোস্ট প্রতিটি সংযুক্তির জন্য একটি করে ঠিকানা রাখে, এবং প্রতিটি ঠিকানা আলাদা রুট দ্বারা নির্বাচিত হয়। জিজ্ঞাসা করার মতো প্রশ্ন হলো কোন রুট কোন গন্তব্যের জন্য কোন বাহক বেছে নেয়, কতগুলো ঠিকানা আছে তা নয়।
তিনটি গন্তব্য যাদের আলাদা বাহক দরকার
দুই-হপের শৃঙ্খল হলো স্তুপীকৃত তিনটি গন্তব্য শ্রেণি, এবং প্রতিটিকে আলাদা সংযুক্তি বহন করে। বাইরের পিয়ারকে পৌঁছাতে হয় ভৌত লিংকের উপর দিয়ে। ভেতরের পিয়ারকে পৌঁছাতে হয় বাইরের টানেলের মধ্য দিয়ে। আচ্ছাদিত অ্যাপ্লিকেশনের গন্তব্যে পৌঁছাতে হয় ভেতরের টানেলের মধ্য দিয়ে, যার নিজের পরিবহন বহন করে বাইরেরটি।
| Destination class | View that names the carrier | Command that proves it | Symptom when the wrong carrier wins |
|---|---|---|---|
| Outer peer, 198.51.100.10 | the main table, by destination | ip route get 198.51.100.10 | the outer handshake never completes |
| Inner peer, 203.0.113.7 | the main table once the outer tunnel is up | ip route get 203.0.113.7 | the inner handshake leaves over the physical link |
| Application destination, 172.30.9.1 | the table the inner client's traffic is selected into | ip route get 172.30.9.1 from 10.8.0.2 | the exit address looks right and the traffic never crossed the outer hop |
| Parallel tunnels, one per source group | one policy per group, not the main table | ip rule show beside a marked test connection | both tunnels are up and one steals the other's traffic |
রুটে হাত দেওয়ার আগে সারিগুলো পাঠকের প্রকৃত ঠিকানা দিয়ে পূরণ করুন, কারণ সারণিটি কেবল তখনই কাজে লাগে যখন তা নির্দিষ্ট হয়। কাজ করা শৃঙ্খল একসঙ্গে চারটি সারিই সন্তুষ্ট করে, আর আধা-কাজ করা শৃঙ্খল সাধারণত তাদের একটিকে ভুল বাহক দিয়ে সন্তুষ্ট করে। ভুল সারিকে ত্রুটি হিসেবে পড়াই একটি রাউটিং সমস্যাকে সন্ধ্যা-ভর সম্পাদনায় পরিণত করে।
ঠিকানার সংখ্যা নয়, ভূমিকা আছে
লিনাক্স একটি ইন্টারফেসে একাধিক ঠিকানা এবং একটি হোস্টে একাধিক টানেল অনুমোদন করে, তাই সংখ্যা সঠিকতা সম্পর্কে কিছু বলে না। গুরুত্বপূর্ণ হলো কোন ঠিকানা কোন সংযুক্তির, এবং নির্দিষ্ট পিয়ারের জন্য রুটটি আপনার ইচ্ছাকৃত সংযুক্তি বেছে নেয় কি না। তিনটি দৃশ্য তিন দিক থেকে তার উত্তর দেয়, এবং প্রতিবার একই ক্রমে সেগুলো পড়া উচিত।
ঠিকানা তালিকা দেখায় কী আছে এবং কোন সংযুক্তি তা মালিক। রুট সারণি সাধারণ গন্তব্য ট্রাফিকের বাহক প্রশ্নের উত্তর দেয়। নীতি দৃশ্য উৎস বা চিহ্ন দ্বারা নির্বাচিত ট্রাফিকের জন্য আবার উত্তর দেয়, যা দুটি ক্লায়েন্ট একটি হোস্ট শেয়ার করলে স্বাভাবিক ব্যবস্থা।
ip -4 addr show
ip -4 route show table all
ip rule show
তালিকা লম্বা দেখায় বলে ঠিকানা মোছা পথের একটি অংশ সরাতে পারে, আর অতিরিক্ত দেখায় বলে রুট মোছা একই কাজ আরও নীরবে করে। কোনোটিই ত্রুটি দেয় না; পিয়ার কেবল আপনার ইচ্ছাকৃত পথে উত্তর দেওয়া বন্ধ করে, অন্য পথে পৌঁছানোযোগ্য থাকে। ভেতরের পিয়ারের প্রস্থান ঠিকানা জানানো একটি অ্যাপ্লিকেশন প্রমাণ করে না যে ট্রাফিক বাইরের টানেল অতিক্রম করেছে, কারণ সরাসরি অ্যাক্সেস একই পর্যবেক্ষণ দেয়। পর্যবেক্ষণ ও প্রমাণের মধ্যে এই ফাঁকই রাউটিং স্তরে বাহক যাচাই করার কারণ।
সক্রিয়করণের ক্রম নির্দিষ্ট ঘুমকে হারায়
ভেতরের ক্লায়েন্ট যদি বাইরের ক্লায়েন্টের সরবরাহ করা ঠিকানা বা রুটের উপর নির্ভর করে, তবে সক্রিয়করণকে বিলম্বের বদলে সেই সম্পদের জন্য অপেক্ষা করতে হবে। ঘুম কাজ করে সেই দিন পর্যন্ত যেদিন বাইরের টানেল ধীর হয়, আর তারপর এটি এমনভাবে মাঝে মাঝে ব্যর্থ হয় যা কেউ পুনরুৎপাদন করতে পারে না। নির্ভরতা-ভিত্তিক ক্রম অনুমান দূর করে এবং নির্ভরতাটি একবার বর্ণনা করা ছাড়া কিছুই খরচ করে না। ইন্টারফেসের নামও ক্রম নির্ধারণের প্রক্রিয়া নয়।
কার্নেল tun0 এবং tun1-এর মতো নাম তৈরি হওয়ার ক্রমে দেয়, এবং সেই ক্রম রিবুট বা পুনঃসংযোগের মধ্যে বদলাতে পারে। কনফিগারেশনটি টুলিং যে পরিচয় দেয় তার সঙ্গে বা আপনি সচেতনভাবে দেওয়া নামের সঙ্গে বাঁধুন। আপনি যে নাম বেছে নেন তা চুক্তি; কার্নেল যে নাম বেছে নেয় তা দুর্ঘটনা।
প্রতিটি ক্লায়েন্টের পরিবহনকে অন্যটির অ্যাপ্লিকেশন রুটের বাইরে রাখুন, এবং OpenVPN 2.6 রাউটিং অপশনগুলো আসলে কী প্রতিশ্রুতি দেয় সে সম্পর্কে সুনির্দিষ্ট থাকুন। নথিভুক্ত ডিফল্ট-রিডাইরেকশন প্রক্রিয়া একটি ক্লায়েন্টকে আগে থেকেই থাকা গেটওয়ের মধ্য দিয়ে নিজের দূরবর্তী পিয়ারে পৌঁছানোর সক্ষমতা রাখে, যা একটি নির্দিষ্ট পুনরাবৃত্তি লুপ কাটে। এটি একটি ক্লায়েন্টকে অন্য ক্লায়েন্টের বাহক করে না, তাই শৃঙ্খলের বাকি অংশ আপনার নকশাই থাকে। যেখানে শৃঙ্খলের রুটের বদলে নীতি দরকার, সেখানে স্পষ্ট উৎস বা চিহ্ন নিয়ম লিখুন এবং যে ট্রাফিকের সঙ্গে মেলানোর কথা তা দিয়ে পরীক্ষা করুন।
বাইরের হপ মরে গেলে কী হয়
শৃঙ্খল সম্পূর্ণ গণ্য হওয়ার আগে ঠিক করুন বাইরের হপ অদৃশ্য হলে কী হবে। ভেতরের ক্লায়েন্টের পরিবহন তার সঙ্গে মরে যায়, আর পরের পদক্ষেপটি প্রযুক্তিগত নয়, নীতিগত প্রশ্ন: ব্যর্থ হওয়া, পুনরায় চেষ্টা করা, নাকি ভৌত লিংকের উপর দিয়ে সরাসরি পুনঃসংযোগ করা। তৃতীয় ফলাফলটিই ভাবার মতো। ব্যবহারকারী যখন বিশ্বাস করেন কভারেজ এখনও অটুট, ঠিক তখনই এটি নিঃশব্দে দুই-হপের নকশাকে এক-হপের নকশায় বদলে দেয়।
যদি দুটি হপ বাধ্যতামূলক হয়, তবে বাইরেরটি চলে গেলে ভেতরের ক্লায়েন্টকে সরাসরি পথ স্থাপন করতে পারা চলবে না, এবং তা জানার উপায় হলো বাইরের হপ ভেঙে ভেতরেরটি কী করে তা দেখা। অনুমোদিত ফলব্যাক বৈধ উত্তর, কিন্তু তা লিখিত, পরীক্ষিত ও জানানো হতে হবে। কেউ নথিভুক্ত না করা ফলব্যাক কোনো ঘটনা পর্যালোচনায় লিক থেকে আলাদা করা যায় না।
DNS এবং অন্য ঠিকানা পরিবার একই সিদ্ধান্তের অংশ। স্থানীয়ভাবে তৈরি লুকআপ হোস্টের নিজের নীতি অনুসরণ করে, ফরোয়ার্ড করা ক্লায়েন্টের নয়, তাই ফরোয়ার্ড করা ট্রাফিকের জন্য কাজ করা রিজলভার হোস্ট নিজে যে ব্যবহার করে তা নাও হতে পারে।
প্রতিটি স্তর আপনি যেভাবে তৈরি করেছেন সেই ক্রমে গ্রহণ করুন
শৃঙ্খল যে ক্রমে তৈরি হয়েছে সেই ক্রমে পরীক্ষা করুন: প্রথমে একা বাইরের টানেল, তারপর বাইরের টানেলের মধ্য দিয়ে ভেতরের ক্লায়েন্টের পরিবহন, তারপর ভেতরের টানেলের মধ্য দিয়ে অ্যাপ্লিকেশন। প্রতিটি গ্রহণকে নতুন সংযোগ হতে হবে, আগে খোলা থাকা পৃষ্ঠা নয়। তারপর প্রতিটি স্তর আলাদাভাবে ভেঙে পুনরুদ্ধার করুন এবং পরেরটি কী করে দেখুন।
ফলব্যাক ফলাফল এখানে সবচেয়ে মূল্যবান পর্যবেক্ষণ, এবং যা একটি পাবলিক-IP পৃষ্ঠা কখনও দেখায় না। পিয়ার পথ, তারা যে ঠিকানা ব্যবহার করে এবং সেই ফলাফল কনফিগারেশনের পাশে সংরক্ষণ করুন, কারণ সুখী পথটি পরবর্তীতে প্রশ্নবিদ্ধ হওয়া অংশ নয়।