TAP یا TUN؟ کلاینت‌های OpenVPN اندروید و سرورهای پل‌شده
TAP فریم‌های اترنت را حمل می‌کند، TUN بسته‌های IP را، و اپ اندروید فقط نوع دوم را می‌گیرد. این دو را مقایسه کنید، سپس سمت سرور را درست کنید.
پروفایلی که روی لپ‌تاپ کار می‌کند، روی گوشی شکست می‌خورد. قدم واضح تغییر یک کلمه در پیکربندی کلاینت است. آن کلمه کمکی نمی‌کند، چون دو سر درباره یک نوع ترافیک حرف نمی‌زنند.
TAP فریم‌های اترنت را حمل می‌کند. TUN بسته‌های IP را حمل می‌کند. به یک اپ VPN اندروید یک رابط IP داده میشود و این یکی از دو چیدمان را ممکن و دیگری را ناممکن می‌کند، فارغ از آنچه پیکربندی می‌گوید.
مقایسه کوتاه است، اما تعیین می‌کند که می‌توانید این را روی گوشی درست کنید یا باید سرویس را تغییر دهید.
دو نوع تونل با بارهای متفاوت
رابط TAP مانند یک آداپتور اترنت رفتار می‌کند. فریم‌ها را حمل می‌کند، یعنی ARP، پخش و هر چیز دیگری که یک LAN زیر IP حمل می‌کند. همین پل‌سازی را ممکن می‌کند: تونل یک دامنه پخش را گسترش می‌دهد و کلاینت‌ها طوری رفتار می‌کنند که گویی به یک سوئیچ وصل شده‌اند.
رابط TUN بسته‌های IP خطاب‌شده به خود را حمل می‌کند. هیچ لایه پیوندی برای چانه‌زنی نیست، نه ARP و نه پخش. مسیریابی تعیین می‌کند چه چیزی وارد تونل شود، و پیکربندی سمت سرور به‌جای پل از یک زیرشبکه استفاده می‌کند.
هر دو سر باید توافق کنند کدام یک از این دو را انجام می‌دهند. تغییر dev tap به dev tun در یک طرف سرویس را تبدیل نمی‌کند؛ نتیجه کلاینتی است که انتظار تونل مسیریابی‌شده دارد و سروری که هنوز فریم می‌فرستد، و دست‌دادن می‌تواند موفق شود در حالی که چیزی قابل استفاده عبور نمی‌کند.
اندروید واقعاً چه چیزی به اپ می‌دهد
اینترفیس VpnService پلتفرم به اپ یک رابط مجازی برای بسته‌های IP می‌دهد که با نشانی‌ها، مسیرها و MTU پیکربندی شده است. در آن اینترفیس هیچ آداپتور اترنتی نیست و اپ راهی برای ساختن یکی ندارد.
به همین دلیل OpenVPN Connect از اتصال‌های TUN مسیریابی‌شده در اندروید پشتیبانی مستند می‌کند، نه پل‌سازی TAP. پرسش‌های متداول اندروید بیان سمت کلاینت درباره این مرز است و با اینترفیس پلتفرم می‌خواند.
ابزارهای شبکه با دسترسی روت، فریم‌ویر سفارشی یا محصولی که یک لایه ترجمه صریح پیاده می‌کند چیدمان‌های دیگری هستند. حالت معمول همان است که باید برایش برنامه ریخت: اپی که می‌تواند فایل شما را وارد کند و به‌عنوان کاربر عادی اجرا شود، با یک رابط IP و هیچ چیز زیر آن.
وقتی باز هم تلاش می‌کنید چه شکلی است
اتصال معمولاً برقرار میشود. همین شکست را گیج‌کننده می‌کند: کلاینت اتصال را گزارش می‌دهد، گزارش سرور یک همتا نشان می‌دهد و هیچ برنامه‌ای کار نمی‌کند.
ترافیکی که به نشانی تخصیص‌یافته گوشی فرستاده میشود نمی‌رسد، چون سرور فریم‌ها را به یک نشانی MAC پل می‌زند که گوشی هرگز نداشته است. کشف وابسته به پخش خالی می‌ماند. اگر LAN از طریق پل به DHCP وابسته باشد، گوشی از این راه اجاره نمی‌گیرد، و نشانی دستی در زیرشبکه پل‌شده هم رابط گمشده را نمی‌سازد.
برخی کلاینت‌ها زودتر، هنگام وارد کردن پروفایل، شکست می‌خورند، وقتی نوع دستگاهی را می‌بینند که نمی‌توانند پیاده کنند. هر دو رفتار یک معنا دارد و هیچ‌کدام با افزودن مسیر، تغییر DNS یا گسترش محدوده نشانی تونل درست نمی‌شود.
سمت سرور چه چیزی باید تغییر کند
اصلاح کار کسی است که سرویس VPN را اداره می‌کند و معمولاً افزودنی است نه مهاجرت. یک نمونه دوم OpenVPN با دستگاه مسیریابی‌شده، زیرشبکه کلاینت خودش و پیکربندی سمت سرور که نشانی‌ها را تخصیص می‌دهد و مسیرهای مورد نیاز گوشی‌ها را می‌فرستد اجرا کنید. نمونه پل‌شده موجود به خدمت‌رسانی به دستگاه‌هایی که واقعاً اترنت لازم دارند ادامه می‌دهد.
دو جزئیات این را در عمل کارا می‌کند. LAN برای زیرشبکه جدید کلاینت‌ها به یک مسیر بازگشت نیاز دارد که به میزبان VPN اشاره کند، وگرنه پاسخ‌ها هرگز برنمی‌گردند. و فایروال روی میزبان تونل باید میان رابط تونل و LAN فوروارد کند، و این همان قدمی است که بیشتر از همه جا می‌افتد وقتی آزمایشی از خود میزبان موفق میشود.
اگر اپراتور نتواند سرویسی بیفزاید، جایگزین دستگاهی است که می‌تواند به پل بپیوندد، یعنی یک لپ‌تاپ یا روتر که به نیابت از گوشی عمل کند. این یک راه‌حل موقت با هزینه مدیریت خودش است، نه پیکربندی اندروید.
از اپ تصمیم بگیرید، نه از تونل
بپرسید گوشی واقعاً باید به چه چیزی برسد، سپس آن را نگاشت کنید. اشتراک فایل یا سایت اینترانتی که با نام یا نشانی در دسترس است یک نیاز IP است و تونل مسیریابی‌شده آن را برآورده می‌کند وقتی DNS نام را حل کند و مسیر وجود داشته باشد. ابزار کشفی که دامنه پخش محلی را مرور می‌کند نیاز IP نیست و هیچ مقدار مسیریابی آن را پر نمی‌کند.
| Requirement | Tunnel that satisfies it |
|---|---|
| File server or intranet by hostname | Routed TUN, with working DNS |
| Broadcast or ARP-based discovery | Ethernet bridging, so not an ordinary Android client |
| Multicast delivery | Bridging or an explicit multicast relay |
| One application to one address | Routed TUN, narrowest possible route |
آن جدول همان درخواستی است که می‌فرستید. اپ، نشانی یا نامی که استفاده می‌کند و اینکه آیا به کشف وابسته است را نام ببرید. اپراتور می‌تواند بر پایه آن توصیف عمل کند، کاری که هیچ‌کس با گوشی‌ای که وصل نمی‌شود نمی‌تواند بکند.
در پایان، سرویس TAP را برای دستگاه‌هایی که به آن نیاز دارند نگه دارید، به‌جای اینکه هر کلاینت را وادار کنید آداپتور LAN را تقلید کند. دو سرویس با هدف روشن آسان‌تر از یکی که برای همه نیمه‌کاره است پشتیبانی می‌شوند.