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

دو پرسش که شبیه یک پرسش به نظر می‌رسند

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

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

مرز کانتینر در واقع چه چیزی فراهم می‌کند

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

libertine-container-manager list
libertine-container-manager info -i <container-id>
libertine-launch -i <container-id> bash

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

وضعیت شبکهٔ گوشی کجا زندگی می‌کند

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

nmcli connection show
ip route get 10.42.0.10
ip -br addr show

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

یک گردش‌کار را سرتاسر بخوانید

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

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

وقتی پاسخ منفی است چه چیزی ثبت کنیم

گاهی نتیجهٔ صادقانه این است که این گوشی، در این انتشار، نمی‌تواند این گردش‌کار را حمل کند. آن را همراه با شواهد بنویسید: سکو چه نوع اتصال‌هایی عرضه می‌کند، کدام کارخواه‌ها آزموده شدند، و کدام گام شکست خورد.

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

در برابر وسوسهٔ دوباره سوار کردن سیستم پایه یا دادن امتیازهای توضیح‌نشده برای بازتولید یک دستور قدیمی مقاومت کنید. گوشی‌ای که راه می‌افتد همان گوشی‌ای نیست که شش ماه بعد هنوز می‌توانید دربارهٔ سیاست شبکه‌اش استدلال کنید.

مقالات مرتبط