دو پرش VPN روی یک Pi: کدام مسیر کدام همتا را حمل می‌کند
دو آدرس تونل روی یک Pi خطا نیست. هر مقصد به حامل خودش، اثبات خودش و یک طرح بازگشتی اعلام‌شده نیاز دارد وقتی پرش بیرونی می‌میرد.
دو آدرس تونل روی یک برد کوچک مثل اشتباه به نظر می‌رسند و رفلکس این است که یکی را حذف کنید. همان رفلکس چیزی را می‌شکند که قرار بود مرتبش کند. میزبان دارای دو پرش برای هر اتصال یک آدرس نگه می‌دارد و هر آدرس را مسیر متفاوتی انتخاب می‌کند. پرسشی که ارزش پرسیدن دارد این است که کدام مسیر کدام حامل را برای کدام مقصد برمی‌گزیند، نه اینکه چند آدرس وجود دارد.
سه مقصد که به حامل‌های متفاوت نیاز دارند
زنجیره دو پرشی سه کلاس مقصد روی هم چیده‌شده است و هر یک را اتصال متفاوتی حمل می‌کند. همتای بیرونی باید از طریق پیوند فیزیکی به دست آید. همتای درونی باید از طریق تونل بیرونی به دست آید. مقصد برنامه پوشش‌داده‌شده باید از طریق تونل درونی به دست آید که حمل‌ونقل خودش را تونل بیرونی حمل می‌کند.
| Destination class | View that names the carrier | Command that proves it | Symptom when the wrong carrier wins |
|---|---|---|---|
| Outer peer, 198.51.100.10 | the main table, by destination | ip route get 198.51.100.10 | the outer handshake never completes |
| Inner peer, 203.0.113.7 | the main table once the outer tunnel is up | ip route get 203.0.113.7 | the inner handshake leaves over the physical link |
| Application destination, 172.30.9.1 | the table the inner client's traffic is selected into | ip route get 172.30.9.1 from 10.8.0.2 | the exit address looks right and the traffic never crossed the outer hop |
| Parallel tunnels, one per source group | one policy per group, not the main table | ip rule show beside a marked test connection | both tunnels are up and one steals the other's traffic |
پیش از دست زدن به هر مسیر، ردیف‌ها را با آدرس‌های واقعی خواننده پر کنید، چون جدول تنها زمانی سودمند است که مشخص باشد. زنجیره سالم هر چهار ردیف را همزمان برآورده می‌کند و زنجیره نیمه‌سالم معمولاً یکی از آن‌ها را با حامل اشتباه برآورده می‌کند. خواندن ردیف اشتباه به‌عنوان خرابی همان چیزی است که یک مشکل مسیریابی را به یک بعدازظهر کامل ویرایش تبدیل می‌کند.
آدرس‌ها نقش دارند، نه شمار
لینوکس چندین آدرس روی یک رابط و چندین تونل روی یک میزبان را مجاز می‌داند، پس شمار چیزی درباره درستی نمی‌گوید. آنچه اهمیت دارد این است که کدام آدرس به کدام اتصال تعلق دارد و آیا مسیر برای یک همتای معین همان اتصالی را برمی‌گزیند که منظورتان بود. سه نما از سه جهت به آن پاسخ می‌دهند و ارزش دارد هر بار به همان ترتیب خوانده شوند.
فهرست آدرس‌ها نشان می‌دهد چه چیزی وجود دارد و کدام اتصال مالک آن است. جدول مسیرها به پرسش حامل برای ترافیک معمول مقاصد پاسخ می‌دهد. نمای سیاست‌ها دوباره برای ترافیکی که با منبع یا نشانه انتخاب شده پاسخ می‌دهد، که چیدمان عادی است وقتی دو کلاینت یک میزبان را شریک می‌شوند.
ip -4 addr show
ip -4 route show table all
ip rule showحذف یک آدرس چون فهرست بلند به نظر می‌رسد می‌تواند بخشی از مسیر را بردارد، و حذف یک مسیر چون اضافی به نظر می‌رسد همان کار را بی‌صداتر می‌کند. هیچ‌کدام خطا تولید نمی‌کند؛ همتا به‌سادگی پاسخ دادن روی مسیری را که منظورتان بود متوقف می‌کند در حالی که از راه دیگری قابل دسترسی می‌ماند. برنامه‌ای که آدرس خروج همتای درونی را گزارش می‌کند ثابت نمی‌کند که ترافیک از تونل بیرونی گذشته است، چون دسترسی مستقیم همان مشاهده را تولید می‌کند. همان شکاف میان مشاهده و اثبات دلیل آن است که حامل در لایه مسیریابی بررسی می‌شود.
ترتیب فعال‌سازی بر خواب ثابت پیروز می‌شود
اگر کلاینت درونی به آدرس یا مسیری وابسته باشد که کلاینت بیرونی فراهم می‌کند، فعال‌سازی باید به‌جای مهلت منتظر همان منبع بماند. خواب ثابت تا روزی کار می‌کند که تونل بیرونی کند شود و آن‌گاه به شکلی گاه‌به‌گاه شکست می‌خورد که هیچ‌کس نمی‌تواند بازتولیدش کند. ترتیب مبتنی بر وابستگی حدس را حذف می‌کند و چیزی جز یک بار توصیف وابستگی هزینه ندارد. نام‌های رابط هم سازوکار ترتیب نیستند.
هسته نام‌هایی مانند tun0 و tun1 را به ترتیب ایجاد می‌دهد و این ترتیب می‌تواند میان راه‌اندازی‌های مجدد یا اتصال‌های دوباره تغییر کند. پیکربندی را به هویتی که ابزار فراهم می‌کند یا به نامی که آگاهانه انتخاب می‌کنید گره بزنید. نامی که شما برمی‌گزینید پیمان است؛ نامی که هسته برمی‌گزیند تصادف است.
حمل‌ونقل هر کلاینت را بیرون از مسیر برنامه دیگری نگه دارید و دقیق باشید درباره آنچه گزینه‌های مسیریابی OpenVPN 2.6 واقعاً وعده می‌دهند. سازوکار مستند تغییرمسیر پیش‌فرض کلاینت را قادر نگه می‌دارد که همتای راه دور خودش را از طریق دروازه‌ای که از پیش وجود داشت برسد، و این یک حلقه بازگشتی مشخص را قطع می‌کند. این سازوکار یک کلاینت را حامل کلاینت دیگر نمی‌کند، پس بقیه زنجیره طراحی خودتان می‌ماند. جایی که زنجیره به‌جای مسیر به سیاست نیاز دارد، قاعده منبع یا نشانه صریح بنویسید و آن را با ترافیکی که باید با آن منطبق شود بیازمایید.
وقتی پرش بیرونی می‌میرد چه می‌شود
پیش از آنکه زنجیره کامل شمرده شود، تصمیم بگیرید وقتی پرش بیرونی ناپدید می‌شود چه اتفاقی می‌افتد. حمل‌ونقل کلاینت درونی با آن می‌میرد و گام بعدی مسئله سیاست است نه مسئله فنی: شکست، تلاش دوباره یا اتصال مجدد مستقیم از طریق پیوند فیزیکی. همان نتیجه سوم است که ارزش اندیشیدن دارد. این نتیجه بی‌صدا طراحی دو پرشی را در لحظه‌ای به طراحی یک پرشی تبدیل می‌کند که کاربر باور دارد پوشش هنوز دست‌نخورده است.
اگر دو پرش اجباری باشند، کلاینت درونی نباید بتواند وقتی بیرونی رفته مسیر مستقیم برقرار کند، و راه دانستن آن شکستن پرش بیرونی و تماشای کار درونی است. طرح بازگشتی تأییدشده پاسخ مشروعی است، اما باید نوشته، آزموده و اعلام شود. طرح بازگشتی که هیچ‌کس مستندش نکرده در بازبینی یک رخداد از یک نشت قابل تشخیص نیست.
DNS و خانواده آدرس دیگر به همان تصمیم تعلق دارند. جست‌وجوی تولیدشده به‌صورت محلی از سیاست خود میزبان پیروی می‌کند نه سیاست کلاینت ارسال‌شده، پس حل‌کننده‌ای که برای ترافیک ارسال‌شده کار می‌کند ممکن است همانی نباشد که خود میزبان استفاده می‌کند.
هر لایه را به همان ترتیبی که ساختی بپذیر
به همان ترتیبی که زنجیره ساخته شد بیازمایید: نخست تونل بیرونی تنها، سپس حمل‌ونقل کلاینت درونی از طریق تونل بیرونی، سپس برنامه از طریق تونل درونی. هر پذیرش باید اتصال تازه باشد نه صفحه‌ای که از پیش باز بود. سپس هر لایه را جداگانه بشکنید و بازگردانید و ببینید لایه بعدی چه می‌کند.
نتیجه طرح بازگشتی ارزشمندترین مشاهده اینجاست و همانی که صفحه IP عمومی هرگز نشان نمی‌دهد. مسیرهای همتا، آدرس‌هایی که استفاده می‌کنند و آن نتیجه را کنار پیکربندی ذخیره کنید، چون مسیر خوشبخت همان بخشی نیست که بعداً زیر سؤال می‌رود.