کلاینت‌های هات‌اسپات روی Pi از طریق VPN از نوع TUN به LAN خانه نمی‌رسند

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

کلاینت‌های محلی Wi-Fi و Ethernet به هات‌اسپات Pi وصل می‌شوند، نشانی را از محدوده DHCP آن می‌گیرند و صفحه‌های اینترنت را بی‌شکایت بارگذاری می‌کنند. سپس همان کلاینت‌ها وقتی اشتراک فایل یا رابط وب روی LAN خانه را باز می‌کنند مهلتشان تمام می‌شود، در حالی که خود Pi از طریق تونل به آن LAN می‌رسد. هیچ چیز در لایه بی‌سیم خراب نیست. آنچه کم است یک قرارداد مسیریابی‌شده است: پیشوند هات‌اسپات باید به رابط TUN برده شود و چیزی در سمت خانه باید بداند چگونه پاسخ‌ها را به آن بازگرداند. هر دو نیمه باید وجود داشته باشند تا یک بسته بتواند سفر رفت و برگشت را کامل کند.

سه اتصال با سه کار متفاوت

پل Ethernet لینوکس فریم‌ها را بر اساس نشانی MAC مقصد ارسال می‌کند. OpenVPN در حالت TUN بسته‌های IP را حمل می‌کند و اصلاً لایه MAC ندارد، بنابراین افزودن پل محلی هرگز تونل را به‌عنوان پورت ثبت نمی‌کند. مستندات هسته درباره TUN/TAP همین تفکیک را توضیح می‌دهد: دستگاه TAP شبیه رابط Ethernet است، دستگاه TUN نه. طرحی که دو پورت محلی را پل می‌کند و سپس مسیریابی می‌کند یک مسیریاب است، هر چه نام رابط‌ها بگویند.

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

مودم را هم بیرون از پل کلاینت نگه دارید. اتصال PPP یک دستگاه Ethernet با برچسب دیگر نیست و منطق مسیر پیش‌فرض مستند pppd پس از مذاکره IPCP اجرا می‌شود و وقتی آن پیوند قطع شود مسیرش را پس می‌گیرد. کپی کردن یک الگوی DHCP و تغییر نام هر usb0 به ppp0 چیزی درباره دروازه، متریک یا چرخه عمر ثابت نمی‌کند.

پیشوندها را قبل از ویرایش هر تنظیمی انتخاب کنید

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

ip -4 addr show scope global
ip -4 route show table main
ip -4 route get 192.168.77.10

استخر اول نشانی underlay است که اپراتور به مودم داده؛ باید بیرون از هر طرح رو به کلاینت بماند. دومی زیرشبکه تونل است که سرور انتخاب کرده، اغلب یک /24 خصوصی از خودش. سومی پل هات‌اسپات است و چهارمی پیشوند خانه است که می‌خواهید به آن برسید. در این مسیر هات‌اسپات 172.28.90.0/24 را با پل روی 172.28.90.1 می‌گیرد و LAN خدمات خانه 192.168.77.0/24 را نگه می‌دارد، که از پیش‌فرض‌های 192.168.1.0/24 و 10.0.0.0/24 که مسیریاب‌های مصرفی می‌آورند و محدوده اپراتور 100.64.0.0/10 دوری می‌کند.

نشانی پل را به‌عنوان دروازه در محدوده DHCP هات‌اسپات اعلام کنید و نه چیز دیگر. هرگز به کلاینت‌های هات‌اسپات نشانی خانه را به‌عنوان دروازه ندهید؛ آن‌ها هیچ مسیری در لایه پیوند به آن بخش ندارند.

هر جهت را در سمتی که مالک آن است مسیریابی کنید

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

sysctl net.ipv4.ip_forward
ip route add 192.168.77.0/24 dev tun0
ip -4 route get 192.168.77.10

اگر ip route get هنوز رابط underlay را گزارش می‌کند، همان‌جا بایستید؛ هیچ چیز پایین‌تر در مسیر نمی‌تواند جستجوی اشتباه را تعمیر کند.

دستگاه‌های خانه هیچ مسیری به 172.28.90.0/24 ندارند، بنابراین پاسخ‌هایشان از دروازه پیش‌فرض پیروی می‌کند و در مسیریاب می‌میرد. دو تعمیر پشتیبانی‌شده وجود دارد. یا یک مسیر ایستا روی مسیریاب خانه اضافه کنید که پیشوند هات‌اسپات را به نشانی LAN سرور VPN اشاره دهد، یا وقتی سرور خودش دروازه است، پیشوند کلاینت را در جدول مسیریابی خود سرور ثبت کنید. در حالت چندکلاینتی OpenVPN پوشه مخصوص کلاینت این ارتباط را حمل می‌کند: فایلی به نام نام مشترک گواهی کلاینت که iroute 172.28.90.0 255.255.255.0 به‌همراه خط route مطابق را دارد و آن را در هسته سرور نصب می‌کند. یک مسیر هسته حدسی روی سرور همان گزاره گفتن به سرور نیست که کدام کلاینت مالک پیشوند است.

برای اینکه این کار کند سرویس DHCP شبکه خانه را به سرور VPN منتقل نکنید. جایگزین کردن دروازه پیش‌فرض یک خانه کامل بسیار بزرگ‌تر از افزودن یک مسیر بازگشت خصوصی است و DNS، رزروهای نشانی و هر دستگاهی را که اجاره جدید را نادیده می‌گیرد به خرابی می‌کشد.

ارسال به جلو را بدون حدس زدن درباره فایروال باز کنید

روشن بودن ارسال به جلو به معنای مجاز بودن بسته نیست. ترافیک از پل به تونل هنوز به قواعد فیلتر برخورد می‌کند و سیاست ارسال به جلوی پیش‌فرض drop ترافیک هات‌اسپات را می‌اندازد در حالی که ترافیک خود Pi کار می‌کند، که دقیقاً همان نشانه دوتایی بالا را تولید می‌کند.

iptables -S FORWARD
iptables -t nat -S POSTROUTING
nft list ruleset

به دنبال یک قاعده پذیرش از br0 به tun0 و جهت پاسخ مطابق، و یک قاعده postrouting باشید که ممکن است مبدأ را بازنویسی کند. اگر سیاست زنجیره drop است و هیچ قاعده‌ای مطابقت ندارد، پذیرش‌های باریک را اضافه کنید و دوباره آزمایش کنید، نه اینکه سیاست را به accept برگردانید.

ترجمه یک انتخاب سیاست است نه یک الزام. NAT مبدأ به سمت LAN خانه هر کلاینت هات‌اسپات را شبیه نشانی تونل Pi می‌کند، که انتساب هر کلاینت را در گزارش‌های خانه از دست می‌دهد و سرویس‌هایی را که مبدأ اصلی را انتظار دارند می‌شکند. مسیریابی بدون NAT نشانی کلاینت‌ها را قابل مشاهده نگه می‌دارد اما به مسیر بازگشت بالا وابسته است. یکی را انتخاب کنید و DNS و IPv6 را به همان شکل اداره کنید، زیرا مسیر IPv4 سالم در کنار مسیر IPv6 خراب هنوز در مرورگر نیمه‌خراب خوانده می‌شود.

سفر رفت و برگشت را بررسی کنید، سپس عمداً آن را بشکنید

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

tcpdump -ni br0 host 192.168.77.10
tcpdump -ni tun0 host 192.168.77.10
ping -c 3 192.168.77.10

دو ضبط را با هم بخوانید. درخواست‌های روی br0 که هرگز روی tun0 ظاهر نمی‌شوند یعنی Pi ارسال به جلو نمی‌کند یا مسیر جای دیگری را نشان می‌دهد. درخواست‌های روی tun0 بدون پاسخ یعنی سمت خانه مسیر بازگشت ندارد یا سرور بسته را فیلتر کرده است. پاسخ‌های روی tun0 که هرگز دوباره روی br0 ظاهر نمی‌شوند یعنی قاعده فیلتر معکوس گم شده است، جایی که تونل بی‌عیب به نظر می‌رسد و کلاینت هنوز هیچ نمی‌بیند.

سپس مسیر را عمداً بشکنید. اتصال مودم را پایین و دوباره بالا بیاورید و بررسی‌های مسیر و ضبط را دوباره اجرا کنید؛ مسیری که از تونل جان سالم به در می‌برد اما هنگام اتصال دوباره ناپدید می‌شود به پروفایل اتصال تعلق دارد، نه به یک فرمان یک‌باره. تأیید کنید که حمل‌ونقل تونل هنوز از underlay بیرون می‌رود و نه از خودش، حلقه کلاسیک وقتی یک مسیر پیش‌فرض هل‌داده بدون مسیر میزبان به همتا پذیرفته می‌شود.

طرح را فقط وقتی بپذیرید که یک کلاینت هات‌اسپات بتواند نام خانه را حل کند، سرویس TCP باز کند و یک نشست را در طول یک اتصال دوباره مودم زنده نگه دارد. اگر برنامه‌ای واقعاً به کشف در سطح Ethernet در بخش خانه نیاز دارد، یک طرح پشتیبانی‌شده Layer 2 انتخاب کنید نه اینکه پل محلی را پل‌شده توصیف کنید و منتظر ظاهر شدن پخش بمانید.

مقالات مرتبط