কীভাবে একটি পাবলিক প্রক্সি VPN-এর মাধ্যমে একটি প্রাইভেট উৎসে পৌঁছায়

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

ডায়াগ্রামে একই রকম দেখায় এমন দুটি মডেল

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

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

TLS কোথায় থামে, এবং এটি আসলে কী প্রমাণ করে

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

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

ফরওয়ার্ড করা হেডার কেবল প্রক্সির কাছ থেকেই বিশ্বাস করুন

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

curl -s -o /dev/null -w '%{http_code}
' -H 'X-Forwarded-For: 203.0.113.9' http://172.20.5.40/

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

উৎসকে ঠিক এক জায়গা থেকেই পৌঁছানোর যোগ্য রাখুন

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

ss -ltnp | grep -E ':(80|443)'

ম্যানেজমেন্ট ইন্টারফেসের জন্যও একই পর্যালোচনা করুন, কারণ আকস্মিক উন্মোচন সাধারণত ওখানেই ঘটে। তারপর দুটি মডেল আলাদা করে লিখে রাখুন: প্রক্সির মাধ্যমে পাবলিক সাইট, এবং কেবল টানেলের মাধ্যমে পৌঁছানো যায় এমন প্রশাসনিক ইন্টারফেস। সার্ভারটি VPN-এর পিছনে আছে—এই বাক্যটি এর কোনোটাই বলে না।