چرا یک میزبان LAN برای نشانی یک مشتری OpenVPN درخواست ARP می‌فرستد

مشکلات دسترس‌پذیری میان یک میزبان LAN و یک مشتری VPN غالباً به خود طرح نشانی بازمی‌گردد. به آن میزبان یک واسط روی 10.0.100.0/22 بدهید تا هر نشانی از 10.0.100.0 تا 10.0.103.255 را مستقیماً متصل بداند، از جمله استخری از مشتریان که بی‌صدا روی 10.0.101.0/24 قرار گرفته است. پاسخ هرگز به یک مسیریاب نمی‌رود، زیرا از دید میزبان هیچ مسیریابی درگیر نیست. بسته به یک همسایه نشانی‌دهی می‌شود و روی سیم درخواست می‌شود.

این سازوکار پشت یک خانواده کامل از گزارش‌ها ایستاده است: تونل بالاست، سرور مسیر دارد و میزبان LAN هنوز به مشتری نمی‌رسد.

پیشوند /22 که /24 را می‌بلعد

پیشوند را به‌عنوان یک بازه بخوانید، نه یک رشته. یک /22 دارای 1024 نشانی است و 10.0.100.0/22 از 10.0.100.0 تا 10.0.103.255 کشیده می‌شود، پس استخری روی 10.0.101.0/24 کاملاً درون آن قرار دارد. خطا از بازبینی جان سالم به در می‌برد زیرا اکتت‌های نخست استخر با اکتت‌های نخست LAN متفاوت به نظر می‌رسند و تنها اکتت سوم است که دربرگیری را آشکار می‌کند. هر دو بازه را عددی بنویسید پیش از آنکه آن‌ها را جدا اعلام کنید.

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

اتصال مستقیم یعنی ARP، نه مسیریابی

وقتی میزبانی با واسط /22 به 10.0.101.25 می‌فرستد، هسته مقصد را با پیشوند واسط مقایسه می‌کند و تطابقی می‌یابد. بسته به جست‌وجوی همسایه تبدیل می‌شود نه بسته مسیریابی‌شده، و در اترنت جست‌وجوی همسایه یک درخواست ARP برای آن نشانی است. اگر نشانی به مشتری VPN پشت یک دروازه مسیریابی‌شده تعلق داشته باشد، هیچ میزبانی در LAN مالک آن نیست، پس درخواست بی‌پاسخ می‌ماند و بسته‌ها دور ریخته می‌شوند. تونل مقصر نیست و مشتری هرگز ترافیک را نمی‌بیند.

به همین دلیل خرابی نامتقارن و گاهی متناوب به نظر می‌رسد. میزبان VPN غالباً به LAN می‌رسد چون مسیرهای خودش در جهت درست اشاره می‌کنند، در حالی که میزبان LAN نمی‌تواند پاسخ دهد، و هر چیزی که یک ورودی ARP کهنه را در حافظه نهان نگه دارد باعث سوسو زدن نشانه می‌شود.

TUN، TAP و آنچه هر یک حمل می‌کند

دستگاه TUN بسته‌های IP و دستگاه TAP قاب‌های اترنت را حمل می‌کند. پیوند TUN مسیریابی‌شده برای فراهم کردن دسترس‌پذیری IP نیازی به حمل ARP ندارد، و دقیقاً به همین دلیل درخواست بی‌پاسخ بالا مورد انتظار است و نه خراب. TAP با یک پل عامدانه می‌تواند دامنه پخش را گسترش دهد و ARP را کار بیندازد، اما آنچه مشتری می‌تواند ببیند را تغییر می‌دهد، به نقاط پایانی نیاز دارد که همان قاب‌بندی را پشتیبانی کنند و بازطراحی مدل شبکه است نه تعمیر یک پیشوند هم‌پوشان. تغییر یک استقرار مسیریابی‌شده به TAP برای درمان خطای طرح نشانی، مشکل کوچکی را با مشکل بزرگ‌تری عوض می‌کند.

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

استخری طراحی کنید که نتواند هم‌پوشانی داشته باشد

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

Source NAT روی سرور می‌تواند استخر را پشت نشانی قابل مسیریابی از LAN پنهان کند، و ابزار مهاجرت مشروعی است. همچنین مبدأ را بازنویسی می‌کند، پس LAN توانایی نسبت دادن اتصال‌ها به مشتریان فردی و اعمال قواعد برای هر مشتری را از دست می‌دهد.

برای پذیرش، از نشانی واقعاً تخصیص‌یافته مشتری واقعی و یک درخواست واقعی برنامه از میزبان LAN استفاده کنید، سپس تأیید کنید که پاسخ به دروازه برنامه‌ریزی‌شده می‌رود نه سیم.