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

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

خرابی را از یک میزبان شبکه محلی بخوانید

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

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

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

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

sysctl net.ipv4.ip_forward
ip -4 address show br-lan
ip route get 203.0.113.9
nft list ruleset | grep -A 6 'chain forward'

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

مسیر بازگشت هم باید وجود داشته باشد

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

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

DNS کلاینت به همان بازبینی تعلق دارد. حل‌کننده روتر می‌تواند پاسخ دهد در حالی که کلاینتی که به سرور دیگری اشاره می‌کند هیچ چیز نمی‌گیرد.

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

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

curl -sS --max-time 8 https://api.ipify.org
ip route get 203.0.113.9
dig +short intranet.example.net

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

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