OpenVPN TAP در macOS: پیش از عیب‌یابی، مشتری را بررسی کنید

یک نمایه قدیمی روی یک Mac امروزی می‌رسد، مشتری آن را بدون هیچ اعتراضی وارد می‌کند، و اتصال قطع می‌شود یا هرگز ترافیکی از آن عبور نمی‌کند. پیش از آنکه یک بعدازظهر را صرف گواهی‌ها کنید، خط دستگاه را در نمایه بخوانید. اگر در آن dev tap نوشته شده باشد، شما از مشتری یک رابط به سبک Ethernet می‌خواهید و در macOS بیشتر این نشست‌ها دقیقاً همین‌جا تمام می‌شوند.

گام 1: تأیید کنید که نمایه واقعاً TAP می‌خواهد

نمایه‌ها تغییر نام می‌دهند، بسته‌بندی می‌شوند و دوباره صادر می‌شوند، پس همان فایلی را بررسی کنید که واقعاً وارد کرده‌اید. دستورالعمل دستگاه و هر include را که ممکن است آن را بازنویسی کند جستجو کنید. دو خط خروجی در بیشتر موارد این پرسش را حل می‌کند. وقتی هم dev و هم dev-type ظاهر شوند، دستورالعمل بعدی برنده است، و این دقیقاً همان جزئیاتی است که یک نمایه کپی‌شده پنهان می‌کند.

grep -nE "^[[:space:]]*(dev|dev-type)[[:space:]]" client.ovpn
ls -l ~/Library/Application\ Support/ 2>/dev/null

اگر فایل شامل dev tap یا dev tap0 باشد، مشتری باید یک رابط TAP پیاده‌سازی کند. اگر شامل dev tun باشد، بقیه این مقاله اعمال نمی‌شود و خرابی جای دیگری است.

نام و نسخه مشتری، نسخه macOS و اینکه نمایه از کجا آمده را یادداشت کنید. این سه واقعیت تعیین می‌کند که کدام‌یک از دو مسیر زیر اصلاً ممکن است.

گام 2: بدانید حالت دستگاه واقعاً چه چیزی را تغییر می‌دهد

یک رابط TUN بسته‌های IP را حمل می‌کند. مشتری بسته‌هایی را که به یک همتای IP نشانی داده شده‌اند می‌خواند و می‌نویسد، و سیستم‌عامل آن‌ها را مانند هر رابط دیگری مسیریابی می‌کند.

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

هزینه‌اش این است که TAP به درایوری نیاز دارد که یک رابط Ethernet را به سیستم ارائه دهد. Apple مدل افزونه هسته را که درایورهای قدیمی TAP برای Mac به آن تکیه داشتند منسوخ کرده است، و API جانشینش به‌طور جادویی در مشتری‌هایی که هرگز برای استفاده از آن به‌روز نشده‌اند ظاهر نمی‌شود. قابلیت یک پلتفرم و یک محصول عرضه‌شده دو چیز متفاوت‌اند.

گام 3: بین مشتری سازگار و مهاجرت یکی را انتخاب کنید

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

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

آنچه کار نمی‌کند این است که tap را در نسخه محلی خود به tun تغییر دهید و امیدوار باشید. سرور هنوز پل می‌زند، مشتری حالا IP حرف می‌زند، و هیچ چیز با هم نمی‌خواند.

گام 4: پیش از تغییر یک سرویس در حال کار، واقعیت‌ها را جمع کنید

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

سه پرسش از مالک دروازه بپرسید. آیا سرور با توپولوژی پل‌شده کار می‌کند یا مسیریابی‌شده؟ کدام پیشوندهای دور باید قابل دسترس باشند؟ و آیا پنجره نگهداری برای تغییر پیکربندی وجود دارد، یا انتظار می‌رود بدون دست زدن به سرور کار کند؟

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

گام 5: مهاجرت را از هر دو سر بررسی کنید

وقتی سرور پیکربندی مسیریابی‌شده دارد و شما نمایه‌ای متناسب دارید، به این ترتیب آزمایش کنید: تونل برقرار می‌شود، مشتری نشانی از استخر جدید می‌گیرد، میزبانی در سمت دور پاسخ می‌دهد، و نامی از طریق تنظیم DNS هل‌داده‌شده تفکیک می‌شود.

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

با یک بار اتصال دوباره و یک بار راه‌اندازی مجدد تمام کنید، زیرا نمایه‌ای که فقط در اولین تلاش کار می‌کند معمولاً یعنی مسیرهای هل‌داده‌شده یا تنظیم DNS هنگام اتصال دوباره اعمال نمی‌شوند.

وقتی باز هم شکست خورد، اولین خطا را بخوانید

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

نمایه اصلی و پیکربندی کارآمد را تا اثبات جانشین نگه دارید. برگرداندن یک تغییر مشتری سریع است؛ بازسازی یک شبکه پل‌شده که کسی بر اساس حدس از هم باز کرده، چنین نیست.