دسترسی به LAN از طریق OpenVPN خراب شده؟ ناحیه‌ها، مسیرها و مسیر بازگشت را بررسی کنید
روتر پاسخ می‌دهد چون محلی است. برای رسیدن به ماشینی پشت آن به قاعدهٔ ارسال، یک پیشوند روی کارخواه و راهی برای بازگشت پاسخ نیاز است.
تونل اتصال موفق را گزارش می‌دهد، صفحهٔ خود روتر بارگذاری می‌شود، و نگاشت درایو به ماشینی پشت آن هنوز به پایان مهلت می‌رسد. هیچ چیز در این ترکیب متناقض نیست: روتر به‌عنوان خودش پاسخ می‌دهد، و رسیدن به هر چیزی پشت آن تصمیم دیگری است که در جای دیگری گرفته می‌شود. بررسی‌های زیر را به ترتیب انجام دهید و در نخستین شکست بایستید، چون هرکدام بر دیگری تکیه دارد. وقتی هر چهار مورد بگذرند، خطا بالای تونل است نه درون آن.
کدام فیلتر بسته‌ای را که به LAN می‌رود می‌بیند
بسته‌ای که به روتر نشانه رفته در همان‌جا مصرف می‌شود؛ بسته‌ای که به میزبان پشت آن نشانه رفته باید ارسال شود، و دیوارهای آتش این دو حالت را جداگانه داوری می‌کنند. پس اجازهٔ رسیدن به روتر هیچ چیزی دربارهٔ اجازهٔ گذر از آن نمی‌گوید. میان‌افزاری که مجموعه‌قاعده‌هایش را پنهان می‌کند باز هر دو را پیاده می‌کند، معمولاً به‌صورت گزینشگری که LAN، اینترنت یا هر دو را پیشنهاد می‌دهد. اگر گزینشگر LAN را جا بگذارد، هیچ بررسی بعدی اهمیتی ندارد.
OpenWrt این تفکیک را قابل بازرسی می‌کند و تفاوتش ارزش یک بار خواندن را دارد. ناحیه‌ای که تونل را پایان می‌دهد به قاعدهٔ ارسال به‌سوی ناحیهٔ LAN نیاز دارد، در حالی که قاعدهٔ ورودی فقط سرویس‌های روی خود روتر را می‌گرداند. صفحهٔ مدیریت سالم در کنار LAN مرده نتیجهٔ معمول همان قاعدهٔ ارسال غایب است.
uci show firewall | grep -E "zone\[[0-9]+\]\.(name|input|forward|output)"به هدف ارسال ناحیه‌ای که تونل را حمل می‌کند نگاه کنید: accept همان چیزی است که نردبان لازم دارد و reject هر مهلت پایین‌تر را توضیح می‌دهد. دو تنظیم همسایه همین نشانه را پدید می‌آورند، پس تا اینجا هستید آن‌ها را کنار بگذارید. جداسازی بی‌سیم میزبان‌های سیمی را از کارخواهان بی‌سیم پنهان می‌کند، و روتری که میزبان‌های بی‌کار LAN را آفلاین می‌پندارد می‌تواند پاسخ‌ها را حتی پس از کار کردن ارسال دور بریزد.
چرا تونل تقسیم‌شده به پیشوند هل‌داده‌شده نیاز دارد
کارخواهی که همهٔ ترافیک را از تونل می‌فرستد پیشوند LAN را از پیش با مسیر پیش‌فرضش دارد، پس چیزی برای افزودن نیست. تونل تقسیم‌شده همان حالتی است که پیشوند باید صریحاً ذکر شود، چون هیچ چیز دیگری در پیکربندی به آن اشاره نمی‌کند. دستور را به پیکربندی سرور بیفزایید و سرویس را دوباره بارگذاری کنید.
push "route 192.168.50.0 255.255.255.0"نمایه‌هایی که route-nopull را دارند مسیرهای هل‌داده‌شده را نادیده می‌گیرند، پس همان پیشوند به‌جای آن به پروندهٔ کارخواه تعلق دارد. در هر حال تأیید کنید که ورودی رسیده است نه اینکه فرض کنید، چون بازنویسی خاموش دقیقاً مانند مشکل دیوار آتش به نظر می‌رسد.
ip route show | grep 192.168.50همتای سایت‌به‌سایت بیش از یک هل دادن می‌خواهد. سرور باید بیاموزد کدام پیشوندها پشت آن همتا هستند، کاری که یک خط iroute در پروندهٔ client-config-dir آن انجام می‌دهد، و جدول خودش هم به مسیری هم‌خوان به درون تونل نیاز دارد.
پاسخ به نشانی نیاز دارد که بتواند به آن برسد
ارسال درخواست تنها نیمی از یک تبادل است، چون میزبان LAN باید به نشانی‌ای در استخر تونل پاسخ دهد. روترهای کوچک این کار را معمولاً با ترجمهٔ مبدأ در ناحیهٔ تونل ترتیب می‌دهند، پس پاسخ به روتر نشانه می‌رود و در جای دیگری پیکربندی لازم ندارد. آن ترجمه را بردارید و میزبان به مسیر خودش به استخر نیاز پیدا می‌کند، که وقتی روتر دروازهٔ پیش‌فرضش باشد رایگان به دستش می‌آید. میزبانی با نشانی دستی و دروازه‌ای دیگر به‌جای آن از همان دروازه پاسخ می‌دهد، و کارخواه می‌بیند نشستی باز می‌شود و بعد متوقف می‌ماند.
tcpdump -ni tun0 host 192.168.50.20این را روی روتر اجرا کنید در حالی که کارخواه درخواستش را تکرار می‌کند، و مقصد پاسخ را بخوانید نه خود درخواست را. پاسخی که به استخر نشانه رفته یعنی مسیر بازگشت کار می‌کند و خطا در عمق بیشتری است. نبود کامل پاسخ یعنی میزبان هرگز بسته را نپذیرفته است، که شما را به مجموعه‌قاعده‌ها برمی‌گرداند.
نردبانی که در جای درست پایان می‌یابد
چهار بررسی لایه را مشخص می‌کنند و هرکدام یک فرمان است نه یک قضاوت. آن‌ها را به ترتیب اجرا کنید و در نخستین شکست بایستید. ترتیب از فرمان‌ها مهم‌تر است، چون گامی بعدی که بگذرد دلیل شکست گام پیشین را پنهان می‌کند.
ping -c1 10.8.0.1
ping -c1 192.168.50.20
nc -vz 192.168.50.20 445
getent hosts nas.localنام‌ها به انتهای نردبان تعلق دارند، هرگز به آغاز آن. اشتراکی که به‌عنوان 192.168.50.20 پاسخ می‌دهد اما نه به‌عنوان nas.local، به تفکیک نام یا پسوند جستجو اشاره دارد، و ویرایش‌های دیوار آتش هیچ‌یک را تغییر نمی‌دهند.
نخستین گام شکست‌خورده را ثبت کنید، سپس به درگاه‌های سرویس گذر خودشان را بدهید، چون شنونده و اجازهٔ میزبان دو شرط جداگانه‌اند. اشتراک فایل، رومیزی دوردست و جریان دوربین هرکدام هر دو را لازم دارند، و دیوار آتش میزبانی که به زیرشبکهٔ LAN اعتماد دارد ولی به استخر تونل نه، کارخواه را می‌اندازد در حالی که ping هنوز موفق می‌شود. وقتی همهٔ بررسی‌ها بگذرند و برنامه هنوز شکست بخورد، خطا بالای تونل است: سرویسی بسته به یک رابط، یا پروکسی‌ای پیکربندی‌شده روی کارخواه.