শুধু VPN-এর জন্য NGINX সাইট: লিসেনার, ফায়ারওয়াল ও HTTP অনুমতি তালিকা

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

এই উদাহরণে tun0-তে 10.90.0.1-এ একটি Linux OpenVPN গেটওয়ে, 10.90.0.0/24-এ ক্লায়েন্ট, সংরক্ষিত সোর্স এবং এই প্রবেশের জন্য সংরক্ষিত TCP 8443 ব্যবহার করা হয়েছে। মানগুলি বদলান, স্তরগুলি রাখুন।

হোস্টনেম নয়, সকেট দিয়ে শুরু করুন

HTTPS লিসেনারকে টানেল ঠিকানা ও একটি নির্দিষ্ট পোর্টে বাঁধুন। নির্দিষ্ট ঠিকানা নিয়ে ভাবা ওয়াইল্ডকার্ড সকেট ও নাম-পরীক্ষার চেয়ে সহজ, কারণ কার্নেল পোর্টটি অন্য লোকাল ঠিকানাকে দেবে না।

server {
    listen 10.90.0.1:8443 ssl;
    server_name admin.corp.example;

    ssl_certificate     /etc/nginx/tls/admin-fullchain.pem;
    ssl_certificate_key /etc/nginx/tls/admin-key.pem;

    root /srv/private-site;

    allow 10.90.0.0/24;
    deny all;

    location / {
        try_files $uri $uri/ =404;
    }
}

সার্টিফিকেটে ক্লায়েন্টরা যে সার্ভিস হোস্টনেম টাইপ করে তা থাকতে হবে, এবং ব্যক্তিগত DNS ভিউকে সেই হোস্টকে বাঁধা ঠিকানায় রিজলভ করতে হবে। server_name কেবল একটি ভার্চুয়াল হোস্ট বেছে নেয়; এটি কাউকে প্রমাণায়ন করে না। DNS এন্ট্রি না থাকলে এমন একটি সার্টিফিকেট ত্রুটি হয় যা TLS সমস্যার মতো দেখায়। সার্টিফিকেট বদলানোর আগে নামটি যাচাই করুন।

ফাইলটি যোগ করার আগে কার্যকর কনফিগারেশন পড়ুন। ইনক্লুড ও ওয়াইল্ডকার্ড লিসেনার অন্যত্র একই রুট পরিবেশন করতে পারে, এবং ডিফল্ট সার্ভার এমন অনুরোধের উত্তর দিতে পারে যা নতুন ব্লক কখনো দেখে না।

ওই কনটেন্টের জন্য অন্য সব লিসেনার বন্ধ করুন

listen নির্দেশিকাগুলি তালিকাভুক্ত করুন এবং তারা যে রুট পরিবেশন করে তা তুলনা করুন। ভিন্ন অ্যাপ্লিকেশনের জন্য যোগ করা ব্লক একই আপস্ট্রিমে প্রক্সি করতে পারে, এবং নতুনটি বসানোর পরেও পুরোনো ডিফল্ট সার্ভার উত্তর দিতে পারে। ওই আউটপুটই আসল তালিকা, আপনি এইমাত্র সম্পাদিত ফাইলটি নয়। একই কনটেন্ট পরিবেশন করে এমন প্রতিটি রুট তুলনা করুন।

sudo nginx -T | grep -n "listen\|server_name\|root\|proxy_pass"

উভয় ঠিকানা পরিবার পরীক্ষা করুন। IPv4 বাইন্ড IPv6 সকেটকে অপরিবর্তিত রাখে, এবং নতুন A রেকর্ড পুরোনো AAAA উত্তর অবসর দেয় না যা এখনো একটি পাবলিক পথে নির্দেশ করে।

পুরোনো ভার্চুয়াল হোস্টকে আলাদা পরিবর্তন হিসেবে অবসর দিন। নতুন ব্লকের পাবলিক যমজ সরানোই সাধারণত সেই ধাপ যা সত্যিই প্রবেশপথ বন্ধ করে; ব্যক্তিগত লিসেনার কেবল অভীষ্ট প্রবেশ যোগ করে।

হোস্টে আগত পথের পরিধি নির্ধারণ করুন

লিসেন ঠিকানা সকেটকে সীমিত করে, ইনগ্রেস ইন্টারফেসকে নয়। অন্য কোথাও থেকে সেই ঠিকানায় রুট করা প্যাকেটও লোকাল ইনপুট হিসেবে আসে, তাই হোস্ট ফায়ারওয়ালের নিজস্ব বিবৃতি দরকার সংযোগ কোথা থেকে আসতে পারে। তাই কেবল বাইন্ড করলে অডিট সন্তুষ্ট হয় না।

ডিফল্ট-ডিনাই ইনকামিং নীতি এবং এই সার্ভিসের জন্য বড় অনুমতি না থাকলে, একটি সীমিত নিয়ম টানেল, সোর্স রেঞ্জ, গন্তব্য ও পোর্ট একসাথে নাম দেয়:

sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 8443

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

ওই নিয়ম হোস্ট ইনপুট, অন্য LAN মেশিনে রুট নয়, এবং গেটওয়ের বাইরের OpenVPN লিসেনার আলাদা সার্ভিসই থাকে। সাইট আগে পাবলিক থাকলে পরিকল্পনা করুন পুরোনো প্রবেশ কীভাবে অবসর নেবে এবং চলমান সেশন কীভাবে সামলানো হবে।

লোকেশন বদলালেও HTTP তালিকা অক্ষত রাখুন

NGINX allow ও deny এন্ট্রিগুলি ক্রম অনুসারে মূল্যায়ন করে, আর উপরের সার্ভার-স্তরের তালিকা চূড়ান্ত deny-এর আগে ঘোষিত পুলকে প্রবেশ করতে দেয়। অ্যাক্সেস মডিউল এও লিপিবদ্ধ করে যে কোনো অ্যাক্সেস এন্ট্রি সংজ্ঞায়িত করা লোকেশন প্যারেন্ট তালিকার বদলে নিজের তালিকা ব্যবহার করে। ক্রম এন্ট্রিগুলির মতোই গুরুত্বপূর্ণ।

এই রিসেটই সাধারণ রিগ্রেশন। একটি এন্ট্রি যোগ করা নতুন আপলোড, API বা হেলথ লোকেশন নীরবে সার্ভার-স্তরের বিধিনিষেধ প্রতিস্থাপন করে, আর সাইটটি সবচেয়ে সম্প্রতি যোগ করা পথে আরও প্রশস্ত হয়ে যায়।

প্রতিটি লোকেশন, অ্যালিয়াস ও বিকল্প ব্লককে একই নীতির অংশ হিসেবে পর্যালোচনা করুন। IP পরীক্ষা যদি NGINX প্রমাণীকরণের সঙ্গে মিলিত হয়, satisfy বুঝুন: any সেটিং একটি ব্যবস্থার মাধ্যমে ক্লায়েন্টকে ঢুকতে দিতে পারে যখন অন্যটি এখনো পাস করেনি। অ্যাক্সেস তালিকাটি লোকেশন পর্যালোচনা চেকলিস্টে রাখুন।

HTTP অস্বীকৃতি ঘটে TCP সংযোগ NGINX-এ পৌঁছানোর পরে। এটি নেটওয়ার্ক বিধিনিষেধের পরিপূরক, এবং অ্যাপ্লিকেশনের নিজস্ব অনুমোদন প্রতিটি ব্যবহারকারীর জন্য এখনো প্রযোজ্য।

সরাসরি পথ ও ব্যর্থতার ক্ষেত্রটি যাচাই করুন

কনফিগারেশন পার্সার চালান, শোনা সকেটগুলি পরিদর্শন করুন, তারপর অভীষ্ট ক্লায়েন্ট থেকে একটি নতুন নামযুক্ত অনুরোধ করুন। নিশ্চিত করুন সার্টিফিকেট বৈধ হয়, DNS নাম বাঁধা ঠিকানায় রিজলভ হয় এবং উত্তর প্রত্যাশিত রুট থেকে আসে।

এরপর একটি বাদ দেওয়া সোর্স ও একটি বিকল্প প্রবেশ পরীক্ষা করুন। সফল অনুমোদিত অনুরোধ আপনি যে পথ বন্ধ করতে চেয়েছিলেন তা নিয়ে কিছুই বলে না, আর বাদ দেওয়া পরীক্ষাতেই অবশিষ্ট লিসেনার বা বিস্তৃত ফায়ারওয়াল অ্যাকসেপ্ট দেখা যায়।

বুট বা VPN পুনরুদ্ধারের ঘটনাটি পুনরাবৃত্তি করুন। টানেল ঠিকানা তৈরির আগে NGINX শুরু হলে নিখুঁত ফাইল থাকলেও বাইন্ড ব্যর্থ হতে পারে। ঠিকানার প্রস্তুতি সমন্বয় করুন এবং শেয়ার করা ওয়েব সার্ভার বদলানোর আগে স্থানীয় পুনরুদ্ধার পথ রাখুন।

যে সকেট, পোর্ট, সোর্স রেঞ্জ ও HTTP তালিকা পাস করেছে তা লিখে রাখুন। পরের VPN বা DNS পরিবর্তন এদের যেকোনোটি সরাতে পারে, আর চারটি নামযুক্ত মান কাজ করা ব্রাউজার ট্যাবের চেয়ে তুলনা করা সহজ।