VPN Pi چندمسیره: هر مسیر را روی دستگاهی بگذارید که تصمیم می‌گیرد
یک روتر پایین‌دستی یک زیرشبکه دوم کلاینت اضافه می‌کند و هر یک از چهار دستگاه صاحب یک تصمیم است. مسیرها را بگذارید، منبع را بررسی کنید و سپس از یک کلاینت واقعی آزمایش کنید.
گذاشتن یک جعبه Wi-Fi پشت Pi یک تصمیم مسیریابی را به چهار تبدیل می‌کند و وقتی هر چهار تصمیم روی یک دستگاه گرفته شود طرح می‌شکند. پرسش اول این نیست که کدام مسیر را اضافه کنیم. بلکه این است که جعبه جدید پل می‌زند یا مسیریابی می‌کند، زیرا این پاسخ تعیین می‌کند چند زیرشبکه وجود دارد و کدام دستگاه‌ها باید درباره آن‌ها بدانند. نخست مدل اتصال را انتخاب کنید؛ هر مسیر از آن پیروی می‌کند.
پل یا مسیریابی: انتخابی که تعداد را تعیین می‌کند
یک پل کلاینت‌های جدید را در همان زیرشبکه‌ای می‌گذارد که Pi از پیش سرویس می‌دهد. یک زیرشبکه، یک مرجع DHCP و هیچ تحویلی برای مسیریابی. این چیدمان ساده‌تر و انتخاب درست است وقتی شبکه کلاینت جداگانه هرگز الزام نبوده است. پیوند مسیریابی‌شده طراحی دیگری است: جعبه زیرشبکه خودش را نگه می‌دارد و آن پیشوند باید به هر جایی که ترافیک می‌رود حمل شود.
بقیه این طرح روتر پایین‌دستی را نگه می‌دارد و نشانی‌های مبدأ کلاینت را حفظ می‌کند. هدف یک شبکه VPN خصوصی است، نه خروج کامل اینترنت. مدل را پیش از نشانی‌ها بنویسید، زیرا فهرست زیر فقط نمونه‌ای از اتصال مسیریابی‌شده است.
client subnet 10.41.0.0/24
client gateway 10.41.0.1
router-to-Pi link 192.168.71.2
Pi on that link 192.168.71.1
private target 10.72.9.0/24چه کسی چه چیزی را تصمیم می‌گیرد
| Decision owner | Entry that encodes the decision | Failure when the entry is missing |
|---|---|---|
| Pi VPN host | Return route for 10.41.0.0/24 via 192.168.71.2, and a tunnel route for 10.72.9.0/24 | Replies to downstream clients die at the Pi |
| Owner of the remote network | A path for 10.41.0.0/24 over the permitted tunnel | Replies stop at the first unaware hop |
| LAN router behind the Pi | Specific route for 10.72.9.0/24 via 192.168.71.1, or a suitable default | Clients never send private traffic to the Pi |
| Client machine | Default via 10.41.0.1, or a specific entry for 10.72.9.0/24 | The private network is unreachable from the client |
هر دستگاه یک تصمیم می‌گیرد و هیچ‌کدام نمی‌تواند تصمیم دیگری را به جای آن بگیرد. Pi به دو ورودی نیاز دارد نه یکی، و مسیر بازگشت همان چیزی است که مردم فراموش می‌کنند. ترافیک فورواردشده به‌درستی به شبکه خصوصی می‌رسد و سپس در راه بازگشت می‌میرد، زیرا Pi هیچ ایده‌ای ندارد 10.41.0.0/24 کجا زندگی می‌کند. این شبیه مشکل فایروال است و در واقع یک مسیر گمشده است.
طرف دور هم به مسیر خودش نیاز دارد. اگر سرویس در انتهای دور نداند که 10.41.0.0/24 از تونل شما قابل دسترسی است، پاسخ‌ها در نخستین گامی که پاسخی ندارد متوقف می‌شوند. پیش از خواندن فیلترهای بسته، هر دو جهت را اضافه کنید.
گام‌های بعدی از اتصال می‌آیند
گام بعدی باید نشانی‌ای در شبکه‌ای باشد که دستگاه واقعاً بتواند به آن برسد. نشانی عمومی همتای VPN گام بعدی برای یک زیرشبکه خصوصی نیست، و شبکه سرویس دور به‌هیچ‌وجه گام بعدی نیست. مسیر به دروازه‌ای دسترس‌ناپذیر در یک فهرست درست به نظر می‌رسد و هر بسته را می‌اندازد. پیش از سرزنش مقصد بررسی کنید که دروازه پاسخ می‌دهد.
همتای VPN بیرونی Pi را از طریق مسیر لایه زیرین خودش در دسترس نگه دارید. آن ورودی از مسیرهای محموله جدا است و آمیختن آن‌ها تونلی می‌دهد که پس از تغییر مسیر نمی‌تواند دوباره برقرار شود.
مستندات مسیرهای ایستا تفاوت میان مقصد و دروازه را روشن می‌کند، هرچند هر پلتفرم منوهایش را متفاوت نام می‌گذارد. مستندات دستگاه مقابل خود را بخوانید نه اینکه صفحه فروشنده دیگری را کپی کنید. دستورهای زیر شکل ورودی‌ها را در Linux نشان می‌دهند.
# on the Pi
ip route add 10.41.0.0/24 via 192.168.71.2
ip route add 10.72.9.0/24 dev tun0
# on the downstream router
ip route add 10.72.9.0/24 via 192.168.71.1ترجمه با مبدأ چه می‌کند
اگر روتر پایین‌دستی از پیش کلاینت‌هایش را به نشانی گذرگاه ترجمه می‌کند، Pi یک مبدأ ترجمه‌شده می‌بیند نه نشانی خود هر کلاینت. این طراحی متفاوتی از طراحی حفظ‌کننده مبدأ در بالاست. سیاست مبتنی بر مبدأ، ثبت رویداد و اینکه کدام طرف می‌تواند اتصال را آغاز کند تغییر می‌کند. هر دو طراحی کار می‌کنند؛ آن‌ها به پرسش‌های متفاوتی پاسخ می‌دهند.
وقتی یک سرویس VPN بالادستی از مسیریابی پیشوند کلاینت به عقب امتناع می‌کند، ترجمه باریک در خروجی تونل Pi می‌تواند راه‌حل موقت مشروعی باشد. این شاهدی بر غیرضروری بودن مسیر گمشده نیست. ثبت کنید شبکه دور واقعاً کدام نشانی را می‌بیند و چه مسیر بازگشتی حاصل می‌شود.
انتخاب مسیر، اجازه فوروارد کردن و ترجمه مبدأ سه کار جدا باقی می‌مانند. پاک کردن یک زنجیره NAT مشترک یا اجازه دادن به هر رابط چون یک کلاینت سیمی کار می‌کند همان راهی است که یک آزمایش کارآمد به یک فورواردر باز تبدیل می‌شود.
اثبات آن از یک ماشین کلاینت
از ماشینی در LAN پایین‌دستی درخواستی بفرستید، سپس مبدأ آن را به بیرون و بازگشت دنبال کنید. پینگی که Pi می‌فرستد هرگز مسیر بازگشت پایین‌دستی را تمرین نمی‌کند، به همین دلیل یک پینگ موفق کمتر از آنچه به نظر می‌رسد اثبات می‌کند. آزمایش دومی از یک کلاینت سیمی در LAN خود Pi اضافه کنید تا دو مسیر قابل مقایسه باشند. هر دو را پس از راه‌اندازی مجدد هر یک از دستگاه‌ها تکرار کنید.
مسیرهایی که دستی اضافه شده‌اند و ترجمه‌هایی که هرگز ذخیره نشده‌اند با هم ناپدید می‌شوند. آن‌گاه این جفت شبیه یک نقص جدید به نظر می‌رسد نه کاری ناتمام.
مدل اتصال را همراه با مسیرها، سرویس خصوصی مجاز و هر ترجمه در یک یادداشت ذخیره کنید. همان یادداشت مانع می‌شود شخص بعدی جای‌گذاری بی‌سیم را پرسشی از سیاست مسیریابی بداند.