Nextcloud فقط از طریق VPN: نخست همه ورودی‌ها را فهرست کنید

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

سیاهه بازبینی را به ترتیب پیش ببرید. نخستین بند تعریف می‌کند که خصوصی برای این استقرار چه معنایی دارد؛ بندهای بعدی بررسی می‌کنند که آیا استقرار واقعاً با آن تعریف می‌خواند.

پیش از تغییر محیط، خصوصی را تعریف کنید

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

نشانی پشتیبان خصوصی برنامه را خصوصی نمی‌کند. اگر یک نگاشت عمومی، یک نام میزبان دوم یا یک شنونده IPv6 هنوز به همان نمونه Nextcloud می‌رسد، ورودی وجود دارد بی‌آنکه مهم باشد پشتیبان کجاست. پیش از اعلام خصوصی بودن سرویس، هر نام را از بیرون بیازمایید. نبودِ یک رکورد DNS همانند بسته بودن درگاه نیست.

درباره مخاطب موردنظر نیز توافق کنید: کارمندان، یک خانواده، یک سازمان شریک یا زیرمجموعه‌ای از حساب‌ها. پاسخ تعیین می‌کند که آیا پیوند اشتراکی عمومی یک ویژگی است یا تناقض. آن مخاطب را در طرح دسترسی بنویسید. این معیار هر استثنایی است که در پی می‌آید.

همه ورودی‌ها و همه نام‌ها را فهرست کنید

نگاشت‌های نشانی عمومی، پراکسی‌های معکوس، نام‌های میزبان جایگزین، شنونده‌های IPv6 و هر نشانی تونل یا مش که به سرویس می‌رسد را برشمارید. نام‌هایی را که به این نشانی‌ها تفکیک می‌شوند نیز بگنجانید، زیرا رکورد DNS فراموش‌شده ورودی‌ای با برچسب دوستانه است.

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

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

به هر کلاینت یک نام سرویس بدهید

DNS خصوصی را به سرویس اشاره دهید، آن نام را از VPN عبور دهید و گواهی آن را صادر کنید. نام باید از مسیر خصوصی تفکیک شود و بدون هشدار معتبر شناخته شود. کلاینتی که مستقیماً به IP می‌رسد باز هم به کارکردن نام نیاز دارد.

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

اعتبارسنجی گواهی را فعال نگه دارید. شبکه خصوصی مواجهه را کم می‌کند اما اتصال TLS بدون اعتبارسنجی را پذیرفتنی نمی‌سازد و کلاینتی که نادیده گرفتن هشدارها را آموخته در شبکه‌های دیگر نیز آن‌ها را نادیده می‌گیرد.

دسترسی شبکه را محدود کنید، نه کل LAN را

به کاربران ثبت‌نام‌شده اجازه دهید به سرویس Nextcloud و وابستگی‌های لازم آن برسند و مدیریت سرور را در مسیری جدا نگه دارید. VPNی که کلاینتی را به تمام شبکه خانه یا دفتر راه می‌دهد به آن کلاینت بسیار بیشتر از نیاز برنامه می‌دهد.

ورود به VPN جای حساب‌ها، مجوزها یا احراز هویت اضافی Nextcloud را نمی‌گیرد. برنامه همچنان تعیین می‌کند کدام کاربر کدام پرونده را بخواند و لایه شبکه نباید تنها کنترل باشد.

محدوده مبدأ تأییدشده و درگاه‌های سرویس را ثبت کنید. مالک هدف به مبدأ مشاهده‌شده نیاز دارد و NAT یا پراکسی می‌تواند آن را پیش از رسیدن درخواست به برنامه بازنویسی کند.

هر جریان کاری بیرون از مرورگر را بازبینی کنید

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

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

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

فدراسیون و یکپارچه‌سازی‌های سرور به سرور به همان رفتار نیاز دارند. آن‌ها روابط دسترس‌پذیری میان نصب‌ها هستند و استقراری که فقط خصوصی است باید بگوید آیا پشتیبانی می‌شوند.

هم حالت مجاز و هم حالت ردشده را بپذیرید

از یک کلاینت تأییدشده، رابط وب و یک بارگذاری یا بارگیری معمول پرونده را بررسی کنید. سپس یک کلاینت همگام‌سازی و یک جریان کاری بیرون از مرورگر را بررسی کنید. موفقیت تنها در مرورگر پذیرش نیست.

از مسیری تأییدنشده تأیید کنید که برنامه از هیچ ورودی فهرست دسترس‌پذیر نیست. نام میزبان جایگزین و نشانی IPv6 را بیازمایید، نه فقط URL اصلی را.

سرانجام تنظیمات برنامه را که به‌آسانی با سیاست شبکه اشتباه می‌شوند بازبینی کنید. trusted_domains نام‌هایی را که نمونه می‌پذیرد برمی‌شمارد؛ این فهرست مجاز IP کلاینت نیست. اگر پراکسی معکوس اطلاعات نشانی را تأمین کند، trusted_proxies باید پراکسی واقعی را نام ببرد و سرآیندهای ارسال‌شده را فقط از آن باید پذیرفت.

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