یک VPS پیش از میزبانی VPN شما باید چه چیزهایی را مجاز کند

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

رابطی را که پروتکل نیاز دارد تأیید کنید

OpenVPN روی TUN به دستگاه نویسه و ماژول هسته‌ای پشت آن نیاز دارد؛ WireGuard به پشتیبانی هسته خود یا پیاده‌سازی فضای کاربر با انتظارات متناظر نیاز دارد. کانتینرهای مدیریت‌شده ممکن است هسته میزبانی را به اشتراک بگذارند که هرگز دستگاه را نمایان نمی‌کند، و برخی پلتفرم‌ها ساخت رابط‌های تونل را کاملاً ممنوع می‌کنند، صرف‌نظر از آنچه نصب شده است.

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

sudo ip tuntap add dev tun9 mode tun
sudo ip tuntap del dev tun9 mode tun
sudo ip link add wgtest type wireguard && sudo ip link del wgtest

رد شدن در جفت اول یعنی TUN در دسترس نیست و حالت پیش‌فرض OpenVPN نمی‌تواند شروع شود؛ رد شدن در خط آخر یعنی رابط هسته‌ای WireGuard وجود ندارد. مستندات هسته درباره TUN/TAP دستگاهی را که بررسی اول می‌آزماید توصیف می‌کند. هیچ یک از این دو خطا با نصب دوباره بسته VPN برطرف نمی‌شود.

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

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

UDP قربانی معمول است: بسیاری از پلتفرم‌ها به‌طور پیش‌فرض TCP را مجاز می‌کنند و قواعد UDP را ورودی جداگانه می‌دانند. اگر نمونه پشت NAT ارائه‌دهنده باشد نه اینکه نشانی عمومی داشته باشد، ارسال درگاه در سمت ارائه‌دهنده سومین پیکربندی می‌شود که باید هماهنگ شود.

مسیر بازگشت را برنامه‌ریزی کنید، نه فقط خروج را

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

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

sysctl -n net.ipv4.ip_forward
sudo nft list ruleset | head -n 40
ip -4 route show default

درباره IPv6 صریح تصمیم بگیرید

IPv6 از چند سازوکار می‌آید که برای یک دروازه رفتار متفاوتی دارند: نشانی روی نمونه، پیشوند مسیریابی‌شده یا هیچ چیز. تنها پیشوند مسیریابی‌شده به سرور اجازه می‌دهد نشانی‌ها را به روش معمول به کارخواهان بدهد. این فرض که نشانی IPv6 کارآمد روی میزبان به معنای پیشوند کارخواه قابل استفاده است اشتباهی است که بعداً به‌صورت اتصال نیمه‌شکسته ظاهر می‌شود. این همان نوع خطایی است که از هر آزمایشی که فقط با IPv4 انجام شود جان سالم به در می‌برد.

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

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

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

sudo wg show wg0 latest-handshakes
ip -4 route get 203.0.113.44
sudo journalctl -u wg-quick@wg0 -n 15 --no-pager

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