دروازه VPN به ارسال IP نیاز دارد: چه چیزی را بررسی کنیم

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

این دو نقش مستقل‌اند، و همچنین دو خانواده نشانی.

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

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

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

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

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

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

sysctl net.ipv4.ip_forward
sysctl -a --pattern 'net.ipv6.conf.(all|default).forwarding'
nft list ruleset | head -n 40

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

ارسال یکی از چهار الزام است

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

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

از کارساز آزمایش کنید، نه از دروازه

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

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

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