কেন curl রিমোট URL-এর বদলে localhost-এ সংযোগ করে
VPN-কে দোষ দেওয়ার আগে উত্তরাধিকারসূত্রে পাওয়া প্রক্সি, ডিফল্ট curlrc এবং প্রকৃত লক্ষ্যকে আলাদা করুন। তিনটি নিয়ন্ত্রিত রানে TLS যাচাই চালু থাকে।
আপনি যে URL দিয়েছেন তা নির্বিশেষে curl যদি localhost-এ সংযোগ করার চেষ্টা করে, তাহলে VPN শুরু করার ভুল জায়গা. একটি স্থানীয় HTTP বা SOCKS প্রক্সি আসলেই প্রথম সংযোগ হতে পারে, এমনকি আপনার প্রয়োজনীয় সেবাটি সম্পূর্ণ অন্য জায়গায় থাকলেও। ওই প্রক্সি আর চালু না থাকলে curl গন্তব্যে পৌঁছানোর আগেই localhost-এর চেষ্টা ব্যর্থ হয়। প্রক্সির উত্তর মানেই গন্তব্য উত্তর দিয়েছে এমন প্রমাণ নয়।
এই ধাপগুলি ক্রমানুসারে করুন এবং যে প্রথম ধাপটি প্রথম সংযোগের চেষ্টা বদলায় সেখানেই থামুন।
প্রথমে curl-এর নিজের প্রক্সি নিয়ম পড়ুন
curl প্রোটোকল-নির্দিষ্ট প্রক্সি ভেরিয়েবল পড়ে, যেমন https_proxy এবং HTTPS_PROXY, এবং কোনো প্রোটোকল-নির্দিষ্ট মান প্রযোজ্য না হলে ALL_PROXY. যে শেল, সেবা বা টাস্কটি প্রকৃতপক্ষে curl চালায় তার পরিবেশ দেখুন, আপনার বর্তমান টার্মিনালের নয়। একটি CI কাজ, একটি systemd ইউনিট এবং একটি ইন্টারঅ্যাকটিভ শেল তিনটি ভিন্ন সেট উত্তরাধিকারে পেতে পারে। দৃশ্যমান শেল থেকে অনুমান করাই এই তদন্তে একটা দুপুর নষ্ট করে।
একটি ব্যতিক্রম মনে রাখার মতো। curl http_proxy কেবল ছোট হাতের অক্ষরে গ্রহণ করে; বড় হাতের HTTP_PROXY উপেক্ষা করা হয়, তাই একই পরিবেশ অন্য টুলে ভিন্নভাবে আচরণ করে।
মানগুলি গোপনে পড়ুন, কারণ প্রক্সি URL-এ প্রায়ই শংসাপত্র থাকে।
তারপর ডিফল্ট curl কনফিগারেশন ফাইলে প্রক্সি বা সংযোগের ওভাররাইড আছে কিনা দেখুন এবং আপনি প্রকৃতপক্ষে কোন এক্সিকিউটেবল চালাচ্ছেন তা নিশ্চিত করুন। একটি শেল অ্যালিয়াস, একটি ফাংশন বা একটি র্যাপার স্ক্রিপ্ট এমন অপশন যোগ করতে পারে যা আপনার কমান্ড লাইনে কখনো দেখা যায় না।
TLS চালু রেখে তিনটি ইনভোকেশন তুলনা করুন
তিনটি রানের জন্যই একটি অনুমোদিত ডায়াগনস্টিক গন্তব্য এবং একই বাইনারি ব্যবহার করুন।
curl -v https://service.corp.example/status
curl -q -v https://service.corp.example/status
curl -q --proxy '' -v https://service.corp.example/status-q ডিফল্ট curlrc দমন করে এবং কাজ করার জন্য লাইনের প্রথম প্যারামিটার হতে হয়। এটি প্রক্সি পরিবেশ ভেরিয়েবল সরায় না, যা এমন লোকদের অবাক করে যারা ঠিক তা-ই আশা করেন। তৃতীয় রূপটি একটি খালি --proxy মান যোগ করে, কেবল ওই ইনভোকেশনের জন্য পরিবেশ-অনুরোধ করা প্রক্সিকে ওভাররাইড করে। প্রতিটি আউটপুটে প্রথম সংযোগের চেষ্টা তুলনা করুন, চূড়ান্ত স্ট্যাটাস কোড নয়।
ভার্বোজ আউটপুট হেডার, টোকেন এবং প্রক্সি শংসাপত্র প্রকাশ করতে পারে, তাই এটি স্থানীয়ভাবে রাখুন এবং শেয়ার করার আগে অংশগুলি পড়ুন।
প্রতিটি ফলাফল কী বাদ দেয়
যদি ডিফল্ট কনফিগারেশন বাদ দেওয়া সংযোগ বদলায়, তবে কনফিগারেশন ফাইলই উৎস। যদি উত্তরাধিকারসূত্রে পাওয়া প্রক্সি স্পষ্টভাবে নিষ্ক্রিয় করা তা বদলায়, তবে পরিবেশ ভেরিয়েবলই উৎস। যদি কোনওটিই তা না বদলায় এবং localhost তবুও দেখা যায়, তবে কমান্ড-লাইন সংযোগ ওভাররাইড, হোস্টনেম রিজলিউশন এবং নির্বাচিত এক্সিকিউটেবল দেখুন। এগুলির প্রতিটির আলাদা সমাধান আছে, এবং কোনওটিই রাউটিং পরিবর্তন নয়।
কাস্টম লাইব্রেরি লোডিং বা ইনজেক্ট করা নেটওয়ার্ক আচরণ পরের স্তর, এবং একা একটি পরিবেশ ভেরিয়েবল তার প্রমাণ নয়।
প্রক্সির সিদ্ধান্ত VPN থেকে আলাদা রাখুন
curl একবার সরাসরি গন্তব্য বেছে নিলে, অপারেটিং সিস্টেম এখনও সেই সংযোগ রাউট করে। একটি অ্যাপ্লিকেশন প্রক্সি নিষ্ক্রিয় করা VPN-এর রুট বা তার ফিল্টারিং নীতি নিষ্ক্রিয় করে না। সরাসরি প্রবেশের তুলনা কেবল যেখানে সেই ডায়াগনস্টিক অনুমোদিত সেখানে করুন। যে পরীক্ষা নীরবে নীতি এড়িয়ে যায় তা বৈধ ফলাফল নয়, তা একটি ঘটনা।
স্থানীয় প্রক্সি প্রয়োজন হলে তার সেটিংস মুছে ফেলার বদলে তার সেবা ও ঠিকানা পুনরুদ্ধার করুন।
কেবল নির্বাচিত ব্যক্তিগত গন্তব্যের সরাসরি প্রবেশ প্রয়োজন হলে একটি সংকীর্ণ অনুমোদিত বাদ দিন এবং বাকি সবকিছুর জন্য প্রক্সি রাখুন। নির্বাচিত পথের প্রথম ত্রুটিটি সংরক্ষণ করুন, কারণ localhost প্রত্যাখ্যান, প্রক্সি CONNECT প্রত্যাখ্যান, শংসাপত্র ব্যর্থতা এবং অনুমোদন ত্রুটি চারটি ভিন্ন ধাপ চিহ্নিত করে।