curl আপনার PAC ফাইল পড়তে পারে না: বরং প্রক্সি পাস করুন
PAC হলো একটি JavaScript নীতি; curl চায় একটি এন্ডপয়েন্ট। জিজ্ঞাসা করুন আপনার URL-এর জন্য নীতিটি কোন প্রক্সি বেছে নেয়, সেটি পাস করুন এবং NO_PROXY ও TLS লক্ষ্য করুন।
কনফিগ ফাইলে PAC ফাইলের ঠিকানা আর প্রক্সি এন্ডপয়েন্ট দেখতে বিনিময়যোগ্য মনে হয়, কিন্তু তারা নয়। একটি হলো নীতি প্রোগ্রাম যা প্রতিটি URL-এর জন্য মূল্যায়ন করতে হয়; অন্যটি হলো একটি হোস্ট ও পোর্ট যা সংযোগ গ্রহণ করে। curl কেবল দ্বিতীয়টিই বোঝে। PAC ঠিকানাকে --proxy পাস করা একটি শ্রেণিগত ভুল, যা বিভ্রান্তিকরভাবে ব্যর্থ হয়, সাধারণত ওয়েব সার্ভারে দীর্ঘ CONNECT টাইমআউটের পরে।
প্রতিটি আসলে কী
| আপনার আছে | এটি কী | curl এটি দিয়ে কী করে |
|---|---|---|
http://wpad.corp.example/proxy.pac | JavaScript যা একটি নির্দিষ্ট URL-এর জন্য প্রক্সি বা সরাসরি সংযোগ ফেরত দেয় | এটিকে একটি ফাইল হিসেবে নামায় এবং সেখানেই থেমে যায় |
http://proxy.corp.example:8080 | একটি লিসেনার যা প্রক্সিকৃত অনুরোধ গ্রহণ করে | এটি ব্যবহার করে, HTTPS লক্ষ্যের জন্য CONNECT সহ |
এটি স্পষ্টভাবে বলা হয়েছে curl FAQ-তে: curl কোনো JavaScript বা PAC ব্যাখ্যা দেয় না। curl-এর চারপাশে PAC-সচেতন একটি র্যাপার তা করতে পারে, কিন্তু curl নিজে নয়, এবং কোনো ফ্ল্যাগ এটিকে ব্রাউজারে পরিণত করে না।
কেন ব্রাউজার কাজ করে আর curl করে না
একটি ব্রাউজার সিস্টেম প্রক্সি কনফিগারেশনের সঙ্গে একীভূত হয়, PAC ফাইল নামায় এবং আপনি যে URL খুলছেন তার বিরুদ্ধে এর নিয়মগুলো চালায়। সেই মূল্যায়নই PAC ফাইল যে সেবা দেয়, এবং তা আপনার টার্মিনালের ভেতরে নয়, ব্রাউজারের ভেতরে ঘটে।
curl দিয়ে PAC ফাইল ডাউনলোড করলে কেবল তার টেক্সট আসে। এটি curl-কে নীতিটি চালাতে বাধ্য করে না, আর প্রক্সি খুঁজতে হাতে হাতে পড়া একই মূল্যায়নের একটি ম্যানুয়াল সংস্করণ, ভুল শাখা বাছাইয়ের একই সম্ভাবনা নিয়ে। যদি পড়েন, তবে ফাইলের প্রথম প্রক্সি নামটি নয়, আপনার হোস্টের সঙ্গে মেলে এমন return বিবৃতিটি পড়ুন। বেশিরভাগ PAC ফাইলে কয়েকটি থাকে, আর কেবল একটি শাখাই আপনার জন্য প্রযোজ্য।
একটি অনুমোদিত HTTP প্রক্সি এবং একটি অনুমোদিত HTTPS সেবার জন্য একটি উদাহরণমূলক অনুরোধ:
curl --proxy http://proxy.corp.example:8080 https://service.example.net/statusপ্রথম ঠিকানাটি প্রক্সি লিসেনার, দ্বিতীয়টি আপনি যে সেবা চান। এগুলো উদাহরণ এন্ডপয়েন্ট, কারও করা পরীক্ষা নয়, তাই আপনার প্রতিষ্ঠানের স্কিম, পোর্ট ও প্রমাণীকরণ কর্মপ্রবাহ দিয়ে প্রতিস্থাপন করুন।
এই গন্তব্যের জন্য প্রক্সি বাছুন
প্রশাসককে জিজ্ঞাসা করুন নীতিটি আপনার প্রয়োজনীয় URL-এর জন্য কোন প্রক্সি বেছে নেয়, প্রতিষ্ঠান কোন প্রক্সির মালিক তা নয়। PAC নিয়মগুলো অভ্যন্তরীণ সেবা, প্রকাশ্য সাইট ও ফলওভার অবস্থার জন্য ভিন্ন ফল দিতে পারে, এবং আজ যে নিয়ম আপনার URL-এর সঙ্গে মেলে, সম্পাদনার পরে তা অন্য একটির সঙ্গে মেলতে পারে।
যদি কর্মপ্রবাহে একাধিক পরিচিত অনুরোধ লাগে, তবে প্রশাসক-সমর্থিত স্থির সেটিং বা অনুমোদিত PAC-সচেতন ইন্টিগ্রেশন ব্যবহার করুন। একটি কপি করা ঠিকানা হার্ডকোড করা সেদিন পর্যন্ত কাজ করে যেদিন নীতি বদলে যায় আর কেউ মনে রাখে না কেন সেই ঠিকানা বেছে নেওয়া হয়েছিল।
তারপর দেখুন curl কী উত্তরাধিকারসূত্রে পায়। প্রক্সি এনভায়রনমেন্ট ভেরিয়েবল এবং NO_PROXY আপনার পাস করা প্রক্সিকে ওভাররাইড বা বাদ দিতে পারে, আর আপনার লক্ষ্যের সঙ্গে মেলা বর্জন অনুরোধটিকে নীরবে সরাসরি পাঠায়। প্রতিটি বর্জন মুছে ফেলা বা সবকিছু এক ঠিকানা দিয়ে চালানো নয়, অভিপ্রেত নীতিটি সংরক্ষণ করুন। অনুরোধটি একবার -v সহ চালান এবং দেখুন এটি আসলে কোন ঠিকানায় সংযুক্ত হয়েছে।
দুই TLS পরিচয় আলাদা রাখুন
HTTPS প্রক্সির ক্ষেত্রে দুটি TLS সংযোগ জড়িত: আপনার প্রক্সির সঙ্গে এবং প্রক্সির গন্তব্যের সঙ্গে। প্রতিটির যাচাই করার নিজস্ব পরিচয় আছে, আর যেকোনোটির জন্য যাচাই বন্ধ করা PAC সমাধান নয়, প্রথম সমস্যার সঙ্গে যোগ হওয়া দ্বিতীয় সমস্যা।
যাচাই চালু রাখুন এবং যে ব্যর্থতা পান তা পড়ুন। প্রক্সি প্রমাণীকরণ চ্যালেঞ্জ, অপ্রাপ্য প্রক্সি এবং ওয়েবসাইটের প্রত্যাখ্যান তিনটি ভিন্ন ফলাফল, এবং কেবল প্রথমটিই শংসাপত্র সম্পর্কে। VPN-কে এখনও একটি অনুমোদিত ব্যক্তিগত প্রক্সির পথ দিতে হবে, যার মধ্যে প্রক্সি হোস্টের নাম রেজল্যুশনও আছে, তার আগে এর কোনোটিই সফল হতে পারে না।
এন্ডপয়েন্ট, স্কিম, পোর্ট, প্রমাণীকরণ পদ্ধতি, বর্জন এবং প্রক্সি পর্যন্ত VPN পথ লিখে রাখুন। সেই রেকর্ডই পরের অনুরোধকে পুনরুৎপাদনযোগ্য করে, আর এটাই আপনার প্রক্সি জানা এবং তা অনুমান করার মধ্যে পার্থক্য।