Apache AllowCONNECT এবং HTTPS গন্তব্য পোর্ট
ক্লায়েন্টরা Apache প্রক্সিতে পৌঁছাতে যে পোর্ট ব্যবহার করে এবং mod_proxy_connect টানেলের ভেতরে যে গন্তব্য পোর্ট অনুমোদন করে, তার পার্থক্য করুন।
আপনার Apache প্রক্সি পোর্ট 3128-এ শোনে। একটি ক্লায়েন্ট সফলভাবে এতে পৌঁছায়, কিন্তু পোর্ট 8443-এ একটি HTTPS সেবা ব্যর্থ হয়। প্রক্সির শোনার পোর্ট বদলালে সেই নির্দিষ্ট পার্থক্যের সমাধান হওয়ার সম্ভাবনা কম।
ক্লায়েন্ট প্রথমে প্রক্সি শ্রোতার সাথে সংযোগ করে। এরপর তার CONNECT অনুরোধ আলাদা একটি গন্তব্য হোস্ট ও পোর্টের নাম দেয়। Apache প্রথম সংযোগ গ্রহণ করে দ্বিতীয় কাজটি প্রত্যাখ্যান করতে পারে।
AllowCONNECT-কে গন্তব্য নীতি হিসেবে পড়ুন
Apache 2.4-এর জন্য mod_proxy_connect আগত CONNECT অনুরোধ পরিচালনা করে। এর AllowCONNECT নির্দেশ সেই অনুরোধগুলোর জন্য উপলব্ধ গন্তব্য পোর্ট নিয়ন্ত্রণ করে। নথিভুক্ত ডিফল্ট হলো 443 এবং 563।
AllowCONNECT 443 8443এই উদাহরণ সেই দুটি গন্তব্য পোর্ট বেছে নেয়। এটি ডিফল্ট নির্বাচন প্রতিস্থাপন করে; এটি 8443 যোগ করে প্রতিটি ডিফল্ট পোর্ট নীরবে ধরে রাখে না। প্রযোজ্য সার্ভার বা virtual-host কনফিগারেশনে নির্দেশটি ব্যবহার করুন।
প্রক্সির ক্লায়েন্ট অনুমোদন নিয়মগুলো যথাস্থানে রাখুন। অনুমোদিত গন্তব্য পোর্ট কোন ক্লায়েন্ট সেবাটি ব্যবহার করতে পারে সে বিষয়ে কিছুই বলে না, এবং গন্তব্য-হোস্ট নিষেধাজ্ঞার প্রয়োজন হলে এটি তার বিকল্প নয়।
একটি রিভার্স-প্রক্সি উদাহরণ ভিন্ন প্রশ্নের উত্তর দেয়
Apache ও HTTPS-এর সার্চ ফলাফলে প্রায়ই একটি পাবলিক ওয়েবসাইটকে নির্দিষ্ট ব্যাকএন্ডে ফরওয়ার্ড করতে দেখা যায়। সেই কনফিগারেশনটি এমন নয় যেভাবে একটি ব্রাউজার ফরওয়ার্ড প্রক্সিকে নির্বাচিত ওয়েবসাইটে CONNECT টানেল খুলতে বলে। এর রাউটিং নির্দেশনাগুলো কপি করলে মূল প্রক্সি সমস্যাটি অক্ষত থাকতে পারে।
ব্যর্থতা নির্ণয়ের সময়, ক্লায়েন্ট যে শ্রোতায় পৌঁছেছে, যে CONNECT authority অনুরোধ করেছে এবং প্রক্সির উত্তর লিপিবদ্ধ করুন। CONNECT সফল হলে এবং পরে TLS ব্যর্থ হলে, গন্তব্য-পোর্ট অনুমতি ইতিমধ্যে তার অংশ করেছে। AllowCONNECT বারবার প্রশস্ত করার বদলে TLS ব্যর্থতা নিয়ে এগিয়ে যান।