NGINX stream প্রসঙ্গে TLS পাসথ্রু সংযোগ গ্রহণ
NGINX TLS সমাপ্ত না করেই TCP TLS রিলে প্রত্যাখ্যান করতে পারে। অনুমতি নিয়মটি HTTP location-এ নয়, stream-এ রাখুন, এবং কোন peer ঠিকানা আসছে তা যাচাই করুন।
এনক্রিপ্টেড বাইট এগিয়ে দেওয়া কিন্তু সার্টিফিকেট কখনও ধরে না রাখা — এটাই TLS পাসথ্রু রিলের কাজ, এবং ব্যবস্থাটি সুবিধাজনক ও কিছুটা বিভ্রান্তিকর। যেহেতু কিছুই ডিক্রিপ্ট হয় না, ফিল্টার করার মতো HTTP আকৃতির কিছু থাকে না, তাই সাধারণ location ব্লক ও তার অ্যাক্সেস নিয়ম এখানে কাজে আসে না। NGINX-এর সামনে থাকা সিদ্ধান্তটি সংযোগটির নিজের বিষয়ে: কোন নেটওয়ার্ক peer নক করল, এবং সেই peer-কে আদৌ পাস করা উচিত কি না।
সিদ্ধান্ত stream-এ, HTTP-তে নয়
stream প্রসঙ্গে NGINX TCP সেশন নিয়ে কাজ করে। এটি সংযোগের peer ঠিকানা দেখে এবং কোনো বাইট backend-এ পৌঁছানোর আগেই তার উপর ক্রমবদ্ধ allow ও deny নিয়ম প্রয়োগ করতে পারে। এটি সম্পূর্ণ প্রবেশ-সিদ্ধান্ত এবং এর জন্য কোনো প্রাইভেট কী, সার্টিফিকেট বা HTTP পার্সিং লাগে না।
| Mechanism | What it decides | Where it lives |
|---|---|---|
| stream allow/deny | Whether this TCP peer is relayed | stream server block |
| ssl_preread map | Which backend a named connection goes to | stream, with the preread module |
| HTTP location rule | Whether an HTTP request is served | http server block |
ওই তিনটি সারি কখনও একে অপরের বিকল্প নয়। 443 পোর্ট উল্লেখ করা যে ফাইলেই হোক, সেখানে HTTP অ্যাক্সেস নির্দেশ কপি করলে কিছুই বদলায় না, কারণ stream সার্ভার কখনও http প্রসঙ্গ পড়ে না।
পাস করার আগে সংযোগটি গ্রহণ করুন
ধরে নিন একটি বিদ্যমান ইনস্টলেশন যেখানে stream ও stream-access মডিউল আছে, VPN ক্লায়েন্টরা উৎস ঠিকানা 10.90.0.0/24-এ রাখে, এবং 192.168.50.20:443-এ একটি backend আছে যা ইতিমধ্যেই কাঙ্ক্ষিত HTTPS পরিচয় পরিবেশন করে।
stream {
server {
listen 443;
allow 10.90.0.0/24;
deny all;
proxy_pass 192.168.50.20:443;
}
}এটি একটি নতুন listener খণ্ড হিসেবে পড়ুন, চালু কনফিগারেশনের সরাসরি প্রতিস্থাপন হিসেবে নয়। আগে বিদ্যমান listener ও include পর্যালোচনা করুন, কারণ ইতিমধ্যে বাঁধা পোর্টে দ্বিতীয় listener অনুরোধের সময়ে নয়, reload-এ ব্যর্থ হয়।
কী নেই তা লক্ষ্য করুন: listen ... ssl নেই, সার্টিফিকেট নির্দেশ নেই। NGINX এনক্রিপ্টেড স্ট্রিম পাস করে, backend TLS সমাপ্ত করে এবং ক্লায়েন্ট যে সার্টিফিকেট যাচাই করে তা উপস্থাপন করে। allowlist-এ ব্যর্থ ক্লায়েন্টের TCP সেশন প্রত্যাখ্যাত হয়, HTTP 403 পৃষ্ঠা নয়, এবং status code প্রত্যাশা করা যেকোনো টুল অসহায় কিছু দেখাবে।
allowlist কী ঢাকে এবং কী ঢাকে না
যদি রিলে ইতিমধ্যেই সার্ভার নাম দিয়ে backend বেছে নেয়, মডিউলটি থাকলে ssl_preread ও map সেই কাজ চালিয়ে যেতে পারে। নামটি এখনও ক্লায়েন্টই দেয়, এবং নাম দেওয়া ক্লায়েন্টের VPN-এ যোগ দেওয়ার প্রমাণ নয়।
উদাহরণের নিয়মটি পুরো stream listener ঢাকে। তাই পাবলিক ও শুধু-VPN সাইটের মিশ্রণ পরিবেশন করা একক প্রবেশবিন্দুর জন্য এটি অনুপযুক্ত, যেখানে প্রতি নামে ব্যতিক্রম দরকার হতো; কেউ পড়তে না পারা নাম-নির্ভর নীতির চেয়ে আলাদা listener সাধারণত বেশি স্পষ্ট।
আরও দুটি ফাঁক উল্লেখযোগ্য। prefix মিল প্যাকেটটি কোন ইন্টারফেস দিয়ে এল তা বলে না, এবং অন্য জায়গার HTTP নিয়ম এই listener-কে সীমাবদ্ধ করতে পারে না। দুটোই একটি allow লাইনকে পুরো সীমা ভাবার বদলে host-স্তরের ingress নীতি চালু রাখার কারণ। সীমাটি দুটি নিয়ন্ত্রণ হিসেবে লিখুন যাদের একমত হতে হবে, যাতে যেকোনো একটির পরিবর্তন পর্যালোচিত হয়।
NGINX আসলে কার ঠিকানা দেখে?
লোড ব্যালেন্সার, অন্য proxy বা সোর্স NAT NGINX-এর সামনে একটি মধ্যস্থতাকারী রাখতে পারে, তাই এটি যে peer দেখে তা VPN ক্লায়েন্টের ভেতরের ঠিকানা নয়। prefix বাছাই করার আগে প্রকৃত পথ পরীক্ষা করুন, কারণ ভুল ঠিকানার জন্য লেখা allowlist হয় অনুবাদকের পেছনের সবাইকে ঢোকার দেয়, নয় কাউকেই নয়।
PROXY প্রোটোকল ও প্রকৃত IP হ্যান্ডলিং বৈধ উত্তর, এবং তা কেবল সামঞ্জস্যপূর্ণ, স্পষ্টভাবে বিশ্বস্ত প্রেরকের জন্য কনফিগার করা উচিত। দুই পদ্ধতিই প্রেরক যা বলে তা বিশ্বাস করে, তাই প্রেরকের তালিকা ছোট হওয়া জরুরি। যেকোনো ইন্টারনেট ক্লায়েন্টের পরিচয় হেডার বিশ্বাস করা উৎস তথ্যকে আবার বিশ্বাসযোগ্য করে না; এটি সঠিক প্রত্যাখ্যানকে জাল গ্রহণে রূপান্তর করে।
reload-এর আগে দুই ফলাফলই পরীক্ষা করুন
কনফিগ যাচাই করুন, reload করুন, তারপর দুইবার পরীক্ষা করুন: কাজ করতে হবে এমন একটি নতুন অনুমোদিত সেশন, এবং কাজ করা উচিত নয় এমন একটি প্রত্যাখ্যাত সেশন। অনুমোদিত পরীক্ষায় স্বাভাবিক backend সার্টিফিকেট যাচাই রাখুন, কারণ যে রিলে সংযোগ করে কিন্তু backend যাচাই করতে পারে না, সে এক সমস্যা মিটিয়ে আরেকটি তৈরি করেছে।
nginx -t
ss -tnp | grep ':443'backend রুট ও উত্তর আলাদাভাবেও পরীক্ষা করুন। allowlist পাস শুধু প্রমাণ করে NGINX সেশনটি গ্রহণ করেছে; এটি অগম্য backend-কে উত্তর দিতে বাধ্য করতে পারে না, এবং আপনি শুরুর আগে অনুপস্থিত ছিল এমন ফেরত পথ মেরামত করতে পারে না।