اجرای VPN و یک وب‌سایت روی یک میزبان بدون تداخل

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

تصمیم بگیرید چه چیزی روی کدام نشانی و کدام ترابری گوش می‌دهد

جدولی با سه ستون بنویسید، نشانی، ترابری و درگاه، و یک ردیف برای هر سرویس، از جمله رابط مدیریتی. TCP 443 برای سایت و UDP 443 برای VPN تعارض نیست حتی وقتی اعداد برابرند، چون ترابری متفاوت است. دو سرویس روی نشانی، ترابری و درگاه یکسان به ترتیبی نیاز دارند که پیاده‌سازی مستندش می‌کند، نه ترتیبی که شما هنگام یک قطعی اختراع می‌کنید. همان جدول، آن اثرگر است که تغییر بعدی را بازبینی‌پذیر می‌کند.

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

تصمیم بگیرید کدام هویت به کدام سرویس تعلق دارد

گواهی مرورگر و اعتبارنامه همتای VPN دو شیء متفاوت با مدل‌های اعتماد متفاوت‌اند. گواهی وب توسط مرجع عمومی اعتبارسنجی می‌شود و نام میزبان را مشخص می‌کند، در حالی که اعتبارنامه همتا یک دستگاه یا کاربر را نزد متمرکزکننده احراز هویت می‌کند و می‌تواند خودامضا یا درون‌سازمانی صادر شده باشد. استفاده دوباره از یکی به‌جای دیگری در موارد تنگ کار می‌کند و به‌ندرت ارزش این جفت‌شدگی را دارد. خاموش کردن بررسی تا یک گواهی مشترک جا بیفتد برنامه جداسازی نیست؛ همان بررسی‌ای را حذف می‌کند که به اعتبارنامه معنا می‌داد.

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

تصمیم بگیرید مدیریت کجا زندگی می‌کند

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

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

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

تصمیم بگیرید وقتی این دو رقابت می‌کنند چه کنید

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

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

از بیرون بررسی کنید، سپس دوباره پس از یک راه‌اندازی مجدد

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

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