ZeroTier-এ HTTP কি এনক্রিপ্টেড? ওভারলে কোথায় শেষ হয় দেখুন
ZeroTier পিয়ার-টু-পিয়ার হপ এনক্রিপ্ট করে, রাউটার বা ব্রিজের পেছনের LAN অংশ নয়। সাধারণ HTTP-কে নিরাপদ বলার আগে দেখুন ওভারলে কোথায় শেষ হয়।
এই পরীক্ষাগুলো ক্রমানুসারে করুন এবং প্রথমটিতে ব্যর্থ হলেই থামুন, কারণ প্রতিটি উত্তর পরের ধাপের অর্থ বদলে দেয়। আসল প্রশ্নটি সংকীর্ণ: ZeroTier নেটওয়ার্কে সাধারণ HTTP ইন্টারনেটের ওপর খোলাখুলিভাবে যায় কি না। দুটি ZeroTier পিয়ারের মধ্যে সাধারণত যায় না, কারণ ওভারলে ওই হপটি এনক্রিপ্ট করে। তবে এটি দুটি প্রান্তবিন্দু সম্পর্কে একটি কথা, কোনো অনুরোধ যে প্রতিটি সেগমেন্ট পার হয় তা নয়। একটি রাউটার, ব্রিজ বা রিভার্স প্রক্সি প্রান্তবিন্দুটি সরিয়ে দেয়, আর তার ওপারে প্লেইনটেক্সট আবার শুরু হয়।
পরীক্ষা 1: ব্রাউজার যে ঠিকানায় ডায়াল করে তা খুঁজুন
URL-এর সঙ্গে মেশিনে প্রকৃতপক্ষে যা আছে তা মিলিয়ে দেখুন। ip -brief addr show zt ইন্টারফেস এবং নেটওয়ার্ক কন্ট্রোলার যে ওভারলে ঠিকানা দিয়েছে তা তালিকাভুক্ত করে; URL যদি ওই ঠিকানা ব্যবহার করে, তবে ব্রাউজারের সকেট ওভারলেতে ঢোকে।
নামটির বদলে LAN ঠিকানায় রিজলভ হলে, ক্লায়েন্টের স্ট্যাটাস নির্দেশক যা-ই বলুক, ওভারলে আদৌ জড়িত নাও থাকতে পারে। ip route get 10.147.20.5 ইন্টারফেস এবং কার্নেল যে সোর্স ঠিকানা বেছে নেবে তা প্রিন্ট করে, তাই সেখানে zt ইন্টারফেস মানে প্যাকেট ওভারলেতে ঢোকে, আর আপনার ফিজিক্যাল NIC-এর নাম মানে ঢোকে না। নাম আরেকটি স্তর যোগ করে: ওভারলে ঠিকানায় নির্দেশ করা রেকর্ড LAN ঠিকানায় নির্দেশ করা রেকর্ডের চেয়ে আলাদা আচরণ করে, আর একটি সার্চ সাফিক্স বা hosts ফাইলের এন্ট্রি চুপচাপ ঠিক করে দিতে পারে আপনি কোনটি পাবেন।
পরীক্ষা 2: নিশ্চিত করুন দুই প্রান্তই পিয়ার, ডিক্রিপ্ট করা রিলে নয়
ZeroTier পিয়ারদের মধ্যে এনক্রিপ্ট করে, আর যেখানে সরাসরি পথ নেই সেখানে প্যাকেটগুলো একটি রুটের মধ্য দিয়ে রিলে হয় যা সেগুলোকে এনক্রিপ্টেড অবস্থাতেই এগিয়ে পাঠায়। zerotier-cli peers প্রতিটি পিয়ারের পথকে লেটেন্সি সংখ্যাসহ DIRECT বা RELAY হিসেবে চিহ্নিত করে। রিলে করা পথ রাউন্ড ট্রিপ খরচ করে, গোপনীয়তা নয়।
উত্তরটি যা সত্যিই বদলায় তা হলো এমন একটি সদস্য যা আসলে প্রান্তবিন্দু নয়। দূরের প্রান্তটি যদি ZeroTier সদস্য হয় যা একটি ফিজিক্যাল LAN-এ রাউটিং বা ব্রিজিং করে, তবে ওভারলে ওই সদস্যেই শেষ হয় এবং পরের হপটি সাধারণ ইথারনেট।
পরীক্ষা 3: অনুরোধ কোথায় পাঠযোগ্য হয় তা দেখুন
যে হোস্ট পৃষ্ঠাটি পরিবেশন করে বলে আপনি মনে করেন, সেখানে রিলোড করার সময় ওভারলে ইন্টারফেস ক্যাপচার করুন: sudo tcpdump -i ztxxxxxxx -A -c 5 'tcp port 80'। ওই আউটপুটে পাঠযোগ্য একটি অনুরোধ লাইন প্রমাণ করে ট্রাফিক ওই হোস্টে ডিক্রিপ্ট হয়ে পৌঁছেছে, আর সেটিই আপনি যে সীমানা খুঁজছেন।
তারপর বাকি LAN-এর দিকে মুখ করা ইন্টারফেসে ক্যাপচার করুন। একই অনুরোধ যদি সেখানে খোলাখুলি দেখা যায়, তবে তা অ্যাপ্লিকেশনে পৌঁছানোর আগেই ওভারলে ছেড়েছে এবং ওই সেগমেন্টের প্রতিটি ডিভাইস তা পড়তে পারে। LAN-এর দিকে কিছু না দেখা গেলে এবং পৃষ্ঠা তবুও লোড হলে, অ্যাপ্লিকেশনটি ZeroTier হোস্টেই শেষ হচ্ছে।
সামনে রিভার্স প্রক্সি থাকলে লুপব্যাক ক্যাপচারও গুরুত্বপূর্ণ, কারণ যে প্রক্সি HTTPS গ্রহণ করে আর HTTP এগিয়ে পাঠায়, সে সীমানাটি নিজের ব্যাকএন্ডে সরিয়ে দেয়।
পরীক্ষা 4: রাউটার বা ব্রিজের পেছনের প্রতিটি হপ হিসাব করুন
ওভারলে ও LAN-এর মধ্যে রাউটিং করার জন্য কনফিগার করা সদস্য একটি সাধারণ নকশা এবং এখানেই এসব অনুমানের বেশিরভাগ ভেঙে পড়ে। ওভারলে ব্রাউজার-থেকে-রাউটার অংশটি রক্ষা করে, তার পরে কিছুই নয়। ব্রিজ ভিন্ন প্রক্রিয়ায় একই কথা বলে: ওভারলে ও ফিজিক্যাল সেগমেন্ট একটি ব্রডকাস্ট ডোমেইনে পরিণত হয়, তাই ব্রিজ করা ল্যাপটপ থেকে আসা অনুরোধ সাধারণ ইথারনেট পেরোয়, যদিও ল্যাপটপটি ZeroTier নেটওয়ার্কে থাকে।
অনুমান না করে ট্রেস করুন। ক্লায়েন্ট থেকে সার্ভিস ঠিকানায় traceroute এবং গেটওয়ে সদস্যের রাউটিং টেবিল দেখায় শেষ হপটি zt নাকি eth।
ZeroTier একটি ট্রাস্টেড-পাথ মোডও দেয় যা পারফরম্যান্সের জন্য নির্ধারিত স্থানীয় পথে ট্রান্সপোর্ট নিরাপত্তা বাদ দিতে পারে। এটি ব্যবহার করা নেটওয়ার্ক স্বাভাবিক এনক্রিপ্টেড-পথ অনুমান উত্তরাধিকারে পায় না, তাই উদ্ধৃত করার আগে নেটওয়ার্ক কনফিগারেশন পড়ুন। প্রোটোকল ডকুমেন্টেশন পিয়ার এনক্রিপশন ও সেই ব্যতিক্রম দুটোই বর্ণনা করে।
পরীক্ষা 5: অ্যাপ্লিকেশনকে এখনও কী করতে হবে তা ঠিক করুন
ওভারলে সদস্যপদ একটি ডিভাইসকে নেটওয়ার্কে প্রমাণীকরণ করে এবং অন্য প্রান্তের সার্ভিসটি আপনার পৌঁছাতে চাওয়া সার্ভিস কি না সে সম্পর্কে কিছুই বলে না। HTTPS ভিন্ন প্রশ্নের উত্তর দেয় হোস্টনামকে একটি কী-তে বেঁধে, তাই দুটি সুরক্ষা একে অপরকে প্রতিস্থাপন না করেই ওভারল্যাপ করে। অনুমোদিত পিয়ারও ভুল সার্ভিস হতে পারে, আর একটি আপোষকৃত প্রান্তবিন্দু অনুরোধটি এনক্রিপশনের আগে ও ডিক্রিপশনের পরে দুবারই পড়ে। কোনও প্রক্রিয়াই অ্যাপ্লিকেশন কী রেকর্ড করে তা নিরীক্ষণ করে না।
পুনরায় ব্যবহারযোগ্য সেশন বা পাসওয়ার্ড আছে এমন যেকোনো কিছুর জন্য অ্যাপ্লিকেশনে বা আপনার নিয়ন্ত্রিত প্রক্সিতে TLS শেষ করুন এবং সার্টিফিকেট যাচাই চালু রাখুন। যেখানে একটি পুরোনো সার্ভিসকে সাধারণ HTTP-তে থাকতেই হবে, সেখানে এটি যে সঠিক হোস্ট-থেকে-হোস্ট পথ ব্যবহার করতে পারে, কে এতে পৌঁছাতে পারে এবং কোন সেগমেন্ট অরক্ষিত থাকে তা লিখে রাখুন; ভবিষ্যতের পর্যালোচকের প্রয়োজন ওই টীকাটিই।
"VPN সংযুক্ত" এগুলোর কোনোটিরই মূল্যায়ন নয়। সৎ সংস্করণে দুই প্রান্তবিন্দু, তাদের মধ্যের পথ এবং প্রথম যে হপটি আওতাভুক্ত নয় তার নাম থাকে।
ক্যাপচার আউটপুট ও পিয়ার তালিকা সার্ভিস ডকুমেন্টেশনের পাশে রাখুন, যাতে যে কেউ রুট বদলায় বা ব্রিজ যোগ করে সে দেখতে পারে কোন অনুমানটি সে ভাঙতে চলেছে।