شنونده VPN را به رابط‌هایی که در نظر داشتید محدود کنید

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

همه چیز در ادامه فرض می‌کند که می‌توانید فرمان‌ها را روی میزبان با root یا sudo اجرا کنید.

پیش از تغییر هر چیزی سوکت‌ها را بخوانید

در Linux، ss -lunp شنونده‌های UDP را با نشانی محلی، پورت و فرایندشان فهرست می‌کند و ss -ltnp همین کار را برای TCP انجام می‌دهد. پورت VPN را پیدا کنید و ستون نشانی را با دقت بخوانید. 0.0.0.0:51820 و [::]:51820 یعنی همه رابط‌ها، در حالی که 10.0.0.5:51820 یعنی یک نشانی روی یک رابط. راهنمای ss ستون‌ها را مستند می‌کند اگر خروجی ناآشنا باشد. اگر نام فرایند نیست، همان فرمان را با sudo اجرا کنید، چون ستون مالک به امتیاز نیاز دارد.

نشانی را بنویسید. این همان واقعیتی است که بقیه این راهنما به آن وابسته است.

به یک نشانی متصل شوید، نه به یک آرزو

OpenVPN با دستور local شنونده را به نشانی مشخصی متصل می‌کند و این روش پشتیبانی‌شده برای محدود کردن آن در سطح فرایند است. هر پیاده‌سازی معادلی ارائه نمی‌دهد و پروتکلی که گزینه اتصال ندارد به این روش باریک نمی‌شود. اگر مال شما هیچ‌کدام را ندارد، فایروال تنها کنترل شماست و یادداشت‌های استقرار باید این را صریح بگویند. روی میزبانی با چند نشانی، به نشانی‌ای که رو به تونل است متصل شوید؛ اتصال به نشانی شناور معمولاً اشتباه است.

سرویسی که باید از تغییر نشانی جان سالم به در ببرد به برنامه‌ای برای اتصال کهنه نیاز دارد، نه فقط یک خط پیکربندی.

خانواده نشانی را جداگانه بررسی کنید

IPv4 و IPv6 سوکت‌های جداگانه‌اند. فرایندی که به 0.0.0.0 متصل است ممکن است هنوز IPv6 را از طریق سوکت دوپشته بپذیرد یا نپذیرد، بسته به گزینه سوکت و پیش‌فرض پلتفرم. خواندن فقط خط IPv4 بیش از یک بازبینی استقرار را فریب داده است. پیش از نتیجه‌گیری اینکه شنونده باریک است، هر دو خانواده را فهرست کنید.

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

فایروال را روی اتصال لایه‌بندی کنید

اتصال باریک جایگزین قاعده فایروال نمی‌شود، و قاعده فایروال اتصال wildcard را باریک نمی‌کند. از هر دو استفاده کنید: جایی که پیاده‌سازی پشتیبانی می‌کند متصل شوید، سپس پورت را فقط از منابعی مجاز کنید که باید به آن برسند. گروه‌های امنیتی ابری جلوی فایروال میزبان قرار دارند، پس وقتی مسیر از مرز VPC می‌گذرد هر دو را بررسی کنید. قاعده مؤثر اشتراک آن دو است و هر لایه فقط می‌تواند دسترسی را کم کند.

از یک منبع مجاز و از یک منبع عمداً حذف‌شده آزمایش کنید. اتصال از localhost چیزی درباره مرز عمومی ثابت نمی‌کند.

ثبت کنید چه چیزی را انتخاب کردید

نشانی متصل، رابطی که مالک آن است، قاعده فایروال و هدفش را بنویسید. یک NIC جایگزین یا نشانی ابری تخصیص‌داده‌شده می‌تواند بدون ویرایش پروفایل توسط کسی، میزان مواجهه را تغییر دهد. یادداشت را تاریخ بزنید، چون نشانی‌های ابری بین بازبینی‌ها بیشتر از آنچه مردم انتظار دارند جابه‌جا می‌شوند.

همین یادداشت است که بازبینی بعدی را به مقایسه تبدیل می‌کند، نه به یک پروژه باستان‌شناسی.