VPN চালু আর localhost কাজ করছে না: নাম, প্রক্সি নাকি বাইন্ড?

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

যখন localhost কর্পোরেট জোনে রিজলভ হয়

সুড়ঙ্গ চালু থাকার সময় নামটি কোথায় রিজলভ হয় দেখুন, তারপর সুড়ঙ্গ বন্ধ করে একই কোয়েরি চালিয়ে দুটি উত্তর মিলিয়ে দেখুন। যেখানে আপনি 127.0.0.1 আশা করেছিলেন সেখানে কর্পোরেট রেঞ্জের ঠিকানা পাওয়াই সূত্র। localhost.mycompany.corp-এর মতো রেকর্ড ক্লায়েন্ট সেই সাফিক্স সার্চ তালিকায় যোগ করার মুহূর্তেই লুপব্যাক এন্ট্রিকে হারায়, আর অনুরোধ সেই পোর্টে কিছুই শুনছে না এমন একটি প্রাইভেট হোস্টে যায়। সার্চ তালিকা অনুমান না করে পড়ুন, কারণ ক্লায়েন্ট একাধিক ডোমেইন যোগ করতে পারে আর কোন প্রার্থী আগে পরীক্ষা হবে তা ক্রম ঠিক করে:

getent hosts localhost
resolvectl domain
ss -ltnp | grep 8080

অ্যাপ্লিকেশন, ডেটাবেস ক্লায়েন্ট বা নোটবুক URL-এ হোস্ট নামের জায়গায় আক্ষরিক ঠিকানা বসান, তারপর অনুরোধ আবার করুন। ব্যর্থতা মুছে গেলে আপনার নামকরণের সমস্যা ছিল আর সুড়ঙ্গ শুধু ট্রিগার। তা থেকে গেলে শ্রোতা বা রুট পরবর্তী সন্দেহভাজন আর নামটি ছিল শুধু ভুল সূত্র।

লুপব্যাক ধরে ফেলা প্রক্সি সেটিংস

সুড়ঙ্গ ওঠার সময় প্রয়োগ হওয়া সিস্টেম প্রক্সি 127.0.0.1-এ যাওয়া অনুরোধ গ্রহণ করে এমন দূরের প্রক্সিতে পাঠাবে যার ধারণা নেই আপনি কী বোঝাতে চেয়েছেন। খালি বাইপাস তালিকা স্থানীয় অনুরোধকে দূরের অনুরোধে বদলে দেয়, আর ত্রুটি বার্তা এটি খুব কমই বলে। লুপব্যাক ঠিকানাগুলো একটি আদেশের জন্য নয়, পুরো সেশনের জন্য বাইপাস তালিকায় যোগ করুন, তারপর নেটওয়ার্ক সম্পর্কে কিছু সিদ্ধান্তে আসার আগে নিশ্চিত করুন টুলটি তা মানে।

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

curl --noproxy '*' http://127.0.0.1:8080/health
NO_PROXY=localhost,127.0.0.1,::1 your-tool

বাইন্ড ঠিকানা ঠিক করে কে সংযোগ করতে পারে

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

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

যেখানে ডিবাগিং টুল LAN আশা করে

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

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

ব্যর্থ হওয়া প্রথম ধাপে থামুন

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

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