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

دو دستگاه، دو تصمیم متفاوت دروازه

Pi پشته IP و مسیر پیش‌فرض خودش را دارد. گوشی هم پشته IP و مسیر پیش‌فرض خودش را دارد.

ConsumerWho chooses its gatewayWhat carries the traffic
Phone on the bridged APThe remote LAN router, delivered in its client configurationAn Ethernet frame toward that router crosses the AP and TAP bridge
Pi's encrypted connectionThe travel uplink's route toward the VPN peerThe Pi sends its own outer transport packets over the underlay

آن جدول تمام مدل است. دروازه گوشی نشانی روی LAN دور است و قاب‌هایش در لایه 2 به‌سوی آن مسیریاب فرستاده می‌شوند. مسیر پیش‌فرض Pi به ترابری بیرونی خود Pi مربوط است که باید از طریق uplink سفر به همتای VPN برسد.

پل قاب‌ها را هدایت می‌کند، بسته‌ها را مسیریابی نمی‌کند

پل لینوکس قاب‌های Ethernet را بر اساس MAC مقصد هدایت می‌کند و این تمام کاری است که میان پورت‌هایش انجام می‌دهد. قاب گوشی که به MAC مسیریاب دور نشانی شده، به پورت TAP سوئیچ می‌شود و بدون لمس جدول مسیریابی Pi از تونل می‌گذرد. به همین دلیل مسیر پیش‌فرض خراب Pi می‌تواند گوشی را کارا نگه دارد و به همین دلیل مسیر درست نمی‌تواند گوشی‌ای را که دروازه اشتباه گرفته درست کند.

TAP قاب‌های Ethernet را حمل می‌کند و می‌تواند پورت پل باشد. TUN بسته‌های IP را حمل می‌کند و نمی‌تواند. اگر طراحی شما یکی را جای دیگری گذاشته، پل دیگر پل نیست و بقیه این مطلب اعمال نمی‌شود.

تصمیم بگیرید چه کسی اجاره گوشی را می‌دهد

گزینه 3 در DHCP گزینه مسیریاب است و به کلاینت می‌گوید برای زیرشبکه‌اش از کدام دروازه استفاده کند. وقتی سرور DHCP در LAN دور تنها توزیع‌کننده است، گوشی دروازه دور می‌گیرد و طراحی سازگار است. وقتی چیز دیگری در سمت سفر اول پاسخ می‌دهد، گوشی دروازه محلی می‌گیرد، ترافیک اینترنتش از uplink سفر خارج می‌شود و ترافیکش به LAN دور هیچ مسیری ندارد.

برای آن دامنه پخش یک توزیع‌کننده اجرا کنید و ثبت کنید چه چیزی می‌دهد.

Pi حتی وقتی نشانی از همان اجاره می‌گیرد، موردی جداگانه است. آگاهانه تصمیم بگیرید که آیا باید مسیرهایی را که اجاره پیشنهاد می‌دهد نصب کند، زیرا پیش‌فرض دور واردشده می‌تواند ترابری VPN خود Pi را به تونلی بکشد که می‌خواهد زنده نگه دارد. با systemd-networkd آن تصمیم UseRoutes= در بخش DHCP است؛ با dhclient گزینه routers در فهرست درخواست است.

uplink را بیرون از LAN پل‌شده نگه دارید

رابطی که اتصال VPN بیرونی Pi را حمل می‌کند نباید پورت پل شود. اگر شود، ترابری رمزنگاری‌شده به LAN گسترده سوئیچ می‌شود و تونل در نهایت بسته‌های بیرونی خودش را حمل می‌کند، که به‌گونه‌ای شکست می‌خورد که شبیه افت بسته است نه حلقه. توانایی AP و پشتیبانی پل را نیز صریح نگه دارید. رابط بی‌سیم در حالت station معمولاً نمی‌تواند پورت پل باشد، زیرا سرآیند 802.11 جایی برای نشانی MAC دوم که پل لازم دارد ندارد.

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

وقتی خراب شد، چهار چیز را جداگانه آزمایش کنید

وقتی گوشی نمی‌تواند به LAN دور برسد، چهار مشاهده علت‌ها را جدا می‌کند. آنها را به این ترتیب اجرا کنید و در اولین موردی که شکست می‌خورد توقف کنید.

ip route show default
bridge link show
ip -4 neigh show dev br0
tcpdump -ni br0 arp or icmp

با اجاره شروع کنید: آیا گوشی نشانی و دروازه‌ای در زیرشبکه دور دارد؟ سپس پل را ببینید و تأیید کنید که پورت AP و پورت TAP هر دو هدایت می‌کنند. سپس جدول همسایه‌ها را بخوانید، زیرا ورودی حل‌نشده برای مسیریاب دور یعنی قاب‌ها خارج می‌شوند و چیزی پاسخ نمی‌دهد. در پایان قاب‌ها را روی پل در حالی که گوشی ping می‌کند تماشا کنید، که به شما می‌گوید آیا عیب اصلاً زیر IP است.

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

مقالات مرتبط