سایت NGINX فقط برای VPN: شنونده، دیوار آتش و فهرست مجاز HTTP

سه تصمیم مستقل میان یک سایت خصوصی و اینترنت قرار دارند: کدام سوکت اتصال را می‌پذیرد، کدام مسیر می‌تواند آن را برساند و سرور انتخاب‌شده به کدام کلاینت‌های HTTP پاسخ می‌دهد. بلوک سرور فقط تصمیم نخست را می‌گیرد. دو تصمیم دیگر را کنترل‌های جداگانه بدانید، وگرنه سایت خصوصی به نظر می‌رسد در حالی که یک ورودی قدیمی باز می‌ماند. بیشتر خرابی‌های NGINX مخصوص VPN از آزمایش تنها لایه نخست می‌آید.

مثال کاربردی از دروازه OpenVPN لینوکس در 10.90.0.1 روی tun0، کلاینت‌ها در 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 را فهرست کنید و ریشه‌هایی را که ارائه می‌کنند مقایسه کنید. بلوکی که برای برنامه دیگری افزوده شده می‌تواند به همان upstream پروکسی کند، و یک سرور پیش‌فرض قدیمی می‌تواند پس از استقرار سرور جدید همچنان پاسخ دهد. آن خروجی فهرست واقعی است، نه فایلی که همین حالا ویرایش کردید. هر ریشه‌ای را که همان محتوا را ارائه می‌کند مقایسه کنید.

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 می‌تواند هر یک از آن‌ها را جابه‌جا کند، و چهار مقدار نام‌دار آسان‌تر از یک زبانه مرورگر کارآمد قابل مقایسه‌اند.