پرش بعدی در مسیر VPN: چرا دروازه باید به‌صورت محلی قابل دسترسی باشد

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

این راهنما حالت معمول را پوشش می‌دهد: یک لپ‌تاپ روی 192.168.20.0/24، یک دروازه VPN با آدرس LAN برابر 192.168.20.5 و یک شبکه راه دور 10.70.0.0/24 پشت آن دروازه. همه دستورهای زیر فرض می‌کنند که روی لپ‌تاپ هستید مگر اینکه خلاف آن گفته شود.

دو آدرس، یک مسیر

ورودی مورد نظر 10.70.0.0/24 via 192.168.20.5 است. پیشوند می‌گوید بسته به کجا می‌رود؛ آدرس via می‌گوید چه کسی آن را به آنجا می‌برد. هسته از نصب مسیری خودداری می‌کند که نتواند دروازه‌اش را از طریق رابطی که نام می‌برید برساند، و همین خودداری تمام نکته است: پرش بعدی که برای قابل دسترس بودن به تونل نیاز دارد نمی‌تواند همان پرش بعدی باشد که تونل را می‌سازد.

پس بررسی اول این نیست که «آیا دروازه روشن است» بلکه «آیا دروازه روی این پیوند است». زیرشبکه خود لپ‌تاپ، ورودی ARP یا همسایه آن و رابط موجود در مسیر همه باید هماهنگ باشند. آدرسی که فقط داخل 10.70.0.0/24 وجود دارد می‌تواند مقصد مسیر دومی باشد، اما هرگز via مسیر اول نیست.

پرش بعدی دروازه را به چه چیزی متعهد می‌کند

نصب مسیر روی لپ‌تاپ فقط تحویل اول را تعیین می‌کند. سپس دروازه به مسیر خودش نیاز دارد: ارسال به جلو فعال، یک مسیر تونل برای 10.70.0.0/24 و هر سیاست دسترسی که تعیین می‌کند چه کسی می‌تواند از آن استفاده کند. در Linux این net.ipv4.ip_forward=1 به‌همراه یک مسیر تونل است؛ دیوار آتشی که جلوی آن است به قاعده‌ای نیاز دارد که جریان ارسال‌شده را مجاز کند.

جهت برگشت همان بخشی است که مردم فراموش می‌کنند. طرف دور باید مسیری برای برگشت به 192.168.20.0/24 داشته باشد، یا طراحی باید مبدأ لپ‌تاپ را به چیزی ترجمه کند که طرف دور آن را می‌شناسد. یک ping موفق از دروازه ثابت می‌کند که دروازه می‌تواند به شبکه دور برسد؛ درباره اینکه بسته‌های لپ‌تاپ از سفر برگشت جان سالم به در می‌برند یا نه چیزی نمی‌گوید.

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

از هسته بپرسید کدام پرش بعدی را انتخاب می‌کند و رابط موجود در پاسخ را بخوانید:

ip route get 10.70.0.10
ip route show 10.70.0.0/24
ip neigh show 192.168.20.5

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

سپس آزمایش را از جای درست تکرار کنید. درخواستی که روی دروازه ساخته می‌شود از آدرس مبدأ خود دروازه استفاده می‌کند، که می‌تواند مسیر برگشت گمشده یا سیاستی را که فقط مبدأهای خاصی را مجاز می‌کند پنهان کند. راهنمای ip-route مقصد، دروازه و بازنویسی onlink را جدا می‌کند، و بازنویسی پیش از استفاده ارزش فهمیدن دارد.

از onlink برای جعل دسترسی‌پذیری استفاده نکنید

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

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

تونل‌های نقطه‌به‌نقطه Ethernet نیستند

دستگاه تونل ARP انجام نمی‌دهد و اغلب زیرشبکه معناداری از همسایه‌ها ندارد. مسیرهایش اغلب شبیه 10.70.0.0/24 dev tun0 هستند، بدون هیچ via، چون همتا تنها نقطه پایانی دیگر است. کپی کردن یک via به سبک LAN در آن جدول مسیری تولید می‌کند که هسته ممکن است رد کند یا بدتر، مسیری که به آدرسی اشاره می‌کند که همتا هرگز به آن پاسخ نمی‌دهد.

دو مدل را در راهنما از هم جدا نگه دارید: مسیر LAN دروازه قابل دسترسی دارد، مسیر تونل یک رابط و یک همتا دارد. WireGuard، OpenVPN و IPsec همگی شکل‌های کمی متفاوتی ارائه می‌دهند، پس شکلی را که واقعاً استفاده کرده‌اید ثبت کنید نه اینکه از یک میزبان تعمیم دهید.

افزودن، تأیید، بازگرداندن

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

sudo ip route add 10.70.0.0/24 via 192.168.20.5
ip route get 10.70.0.10
ping -c 3 10.70.0.10
sudo ip route del 10.70.0.0/24 via 192.168.20.5

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