প্রক্সি ও প্যাকেজ সার্ভারের জন্য Cargo CA বান্ডল
Cargo-এর cainfo ও proxy-cainfo সঠিক TLS সংযোগে প্রয়োগ করুন; প্রক্সির সব সার্টিফিকেট ব্যর্থতাকে একই বিশ্বাসের সমস্যা ভাববেন না।
HTTPS প্রক্সি ও HTTPS প্যাকেজ উৎসের জন্য Cargo আলাদা CA বান্ডল দিয়ে দুটি TLS সংযোগ যাচাই করতে পারে:
[http]
proxy = "https://proxy.example:8443"
proxy-cainfo = "/path/to/proxy-ca.pem"
cainfo = "/path/to/origin-ca.pem"এন্ডপয়েন্ট ও পথ অনুমোদিত মান দিয়ে বদলান। এই প্রক্সিতে ইচ্ছাকৃতভাবে TLS লিসেনার আছে; সাধারণ HTTP প্রক্সি প্যাকেজ উৎস HTTPS ব্যবহার করে বলেই HTTPS হয়ে যায় না।
| ব্যর্থতার ধাপ | যে বিশ্বাসের সেটিং পরীক্ষা করতে হবে |
|---|---|
| গন্তব্যে টানেল হওয়ার আগের প্রক্সি TLS | http.proxy-cainfo; আলাদাভাবে নির্ধারণ না করা হলে http.cainfo ব্যবহার করে। |
| টানেল তৈরির পর গন্তব্যের সার্টিফিকেট | গন্তব্যের বিশ্বাসের পথের জন্য http.cainfo। |
সংশ্লিষ্ট ভেরিয়েবল হলো CARGO_HTTP_PROXY_CAINFO ও CARGO_HTTP_CAINFO। উপযুক্ত অনুমোদিত সার্টিফিকেট কর্তৃপক্ষ ব্যবহার করুন; যেকোনো সার্টিফিকেট দুটি ফাইলে কপি করলে কোন সংযোগে সমস্যা তা বোঝা যায় না।
CONNECT বহনকারী এনক্রিপশনহীন HTTP প্রক্সিতে যাচাই করার মতো প্রক্সি লিসেনারের TLS সার্টিফিকেট থাকে না। সেই ক্ষেত্রে গন্তব্যের ত্রুটি একটি মনগড়া প্রক্সি CA ফাইল দিয়ে সারে না। নির্ধারিত পথ প্রকৃত কনটেইনার বা CI কাজের ভেতরে আছে কি না দেখুন এবং পরিবেশ তুলনার সময় অপারেটিং সিস্টেম ও TLS ব্যাকএন্ডের আচরণ বিবেচনা করুন।
যাচাই চালু রাখুন। এটি অভীষ্ট পরিষেবাকে শুধু চলতে থাকা স্থানান্তর থেকে আলাদা করার জন্য প্রয়োজনীয় পরিচয় পরীক্ষা দেয়।