فایروال ابری در برابر فایروال میزبان برای یک سرور VPN

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

از لبه شروع کنید و به سمت داخل بروید

ترتیب ثابت است: نقطهٔ پایانی عمومی، واسط منبع، سیاست ابری متصل، نشانی میزبان، شنوندهٔ فرایند، قواعد ورودی محلی. هر مرحله یا بسته را عبور می‌دهد یا بررسی را پایان می‌دهد، و به همین دلیل شروع از میزبان بیشترین وقت را تلف می‌کند.

ترافیک ارسال‌شدهٔ کارخواه مرحله‌ای جداست که پس از رمزگشایی تونل بررسی می‌شود. لایهٔ ابر فقط تونل بیرونی را می‌بیند، پس می‌تواند اتصالی را تأیید کند و در همان حال هیچ ارتباطی با درخواست یک سرویس داخلی نداشته باشد. تونلی که متصل می‌شود ولی به میزبان داخلی نمی‌رسد معمولاً به ارسال اشاره دارد، نه به پورت بسته.

پیش از دست زدن به میزبان، سیاست ابری را بخوانید

قاعدهٔ ورودی پورت VPN، پروتکل آن و دامنهٔ مبدأ که با کارخواه آزمایشی شما می‌خواند را تأیید کنید. فهرست کنترل دسترسی زیرشبکه را هم بررسی کنید: فیلتری دوم با قواعد و پیش‌فرض‌های خودش. هر دو باید پیش از رسیدن بسته به نمونه، جریان را مجاز کنند. مجاز بودن در یکی و رد شدن در دیگری شکل معمول این اشکال است.

دامنه را تا جایی که معنا پیدا کند تنگ کنید. باز کردن پورت VPN به روی تمام اینترنت آسان است اثبات و سخت است دفاع، در حالی که قاعده‌ای که به یک نشانی سنجاق شده با جابه‌جا شدن شبکهٔ کارخواه آزمایشی شما می‌شکند. شناسهٔ قاعده و مالک سیاست را یادداشت کنید تا تغییر بعدی به یک شخص قابل ردیابی باشد.

شنونده را تأیید کنید، سپس زنجیرهٔ ورودی را

روی نمونه بررسی کنید که فرایند VPN به نشانی و پورتی که انتظار دارید بسته شده باشد، برای نمونه با ss -lntp 'sport = :1194'. سرویسی که فقط به 127.0.0.1 بسته شده باشد کارخواهان محلی را می‌پذیرد و هیچ چیز را از تونل نه، که از بیرون دقیقاً مانند پورتی فیلترشده به نظر می‌رسد.

سپس قواعد محلی را با همان نحو که برای تغییرشان به کار می‌برید بخوانید، مانند iptables -S INPUT یا nft list chain inet filter input. قاعده‌ای که در فایلی نوشته شده ولی هرگز بارگذاری نشده، یا رد پیش‌فرض بدون مجاز بودن هیچ قاعدهٔ منطبقی، بسته‌ها را بی‌صدا دور می‌ریزد. برای دروازهٔ ارسال‌کننده، تنظیمات ارسال و مسیر بازگشت را هم بررسی کنید. آن‌ها تعیین می‌کنند با بسته‌هایی که از نمونه عبور داده می‌شوند و به آن نشانی ندارند چه می‌شود.

دارای حالت در یک لایه، بی‌حالت در لایهٔ بعد

گروه‌های امنیتی جریان‌هایی را که مجاز کرده‌اند به یاد می‌سپارند و پاسخ‌ها را باز می‌گردانند. فهرست‌های کنترل دسترسی زیرشبکه و بسیاری از فایروال‌های میزبان چنین حالتی نگه نمی‌دارند، پس قاعده‌ای که فقط جهت خروجی را پوشش می‌دهد درخواست را عبور می‌دهد و پاسخ را دور می‌ریزد. هرگز فرضی دربارهٔ ترافیک بازگشتی بین لایه‌ها نبرید بدون خواندن قاعدهٔ لایهٔ دوم (second layer's rule).

شمارنده‌ها این را سریع‌تر از خواندن هر قاعده در حساب روشن می‌کنند. شمارنده‌ای که بالا می‌رود یعنی بسته رسیده و همان‌جا دور ریخته شده، و شمارنده‌ای که روی صفر یخ زده یعنی هرگز تا آنجا نرسیده؛ iptables -vnL INPUT و nft list ruleset این شمارش‌ها را نشان می‌دهند وقتی قواعد با شمارنده بارگذاری شده باشند.

با نشست تازه آزمایش کنید، نه با نشست زنده

هنگام مقایسهٔ نماها شبکهٔ مبدأ و نمایهٔ آزمایشی را دست نزنید و پس از هر تغییر اتصال تازه‌ای باز کنید. رسیدن به کنسول وب روی 443 هیچ چیزی دربارهٔ بسته بودن سرویس VPN به 1194 نمی‌گوید، پس همان پورتی را که لازم دارید آزمایش کنید. نشست موجود بدترین شاهد در اینجا است. کار می‌کند در حالی که هر ورود تازه رد می‌شود.

پیش از ویرایش یک سیاست دوردست، راه بازگشتی داشته باشید که به مسیری که تغییر می‌دهید وابسته نباشد. سپس در کنار آزمایش VPN یک نشست مدیریتی دوم باز کنید: نشستی که پیش‌تر برقرار شده می‌تواند از قاعده‌ای که نشست‌های تازه را می‌بندد بیشتر دوام بیاورد. مالک هر دو سیاست را ثبت کنید تا هیچ بازسازی‌ای نیمی از مسیر را برنگرداند؛ اگر هر دو لایه هم‌نظرند و تونل هنوز کار نمی‌کند، روی واسط میزبان ضبط کنید و نشانی و پورتی را که کارخواه واقعاً به کار می‌برد بررسی کنید.