بیشتر ساخت‌های VPN روی Raspberry Pi با دستور کار سرور شروع می‌شود و با گوشی‌ای تمام می‌شود که نمی‌تواند وصل شود. ترتیب برعکس است. کلاینت گوشی یک پروتکل مشخص را با یک تبادل احراز هویت مشخص پیاده می‌کند و سرور باید با همان تبادل هم‌خوان باشد، نه برعکس. اگر اول اپلیکیشن را تعیین کنید، یک بعدازظهر عیب‌یابی به یک فهرست بررسی کوتاه تبدیل می‌شود.

ترتیبی که بازسازی را حذف می‌کند

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

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

وقتی اپلیکیشن ثابت شد، انتخاب سرور باریک‌تر می‌شود و بقیه ساخت هدف پیدا می‌کند.

اپلیکیشن گوشی در واقع چه چیزی پیاده می‌کند

یک فهرست منتشرشده از کلاینت‌ها یک برنامه را توصیف می‌کند، نه یک سرویس. اپلیکیشن OpenVPN Connect برای Android انتظار یک سرور OpenVPN دارد؛ سمت سرور را فراهم نمی‌کند. همچنین وقتی پروفایل شبیه به نظر می‌رسد، به کلاینت IPsec یا L2TP تبدیل نمی‌شود.

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

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

توافق چهاربخشی

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

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

اعتبارنامه‌ها کارهای جداگانه دارند

تصمیم بگیرید که پروفایل از گواهی‌های کلاینت، نام کاربری و گذرواژه یا ترکیبی پشتیبانی‌شده استفاده می‌کند و هر دو طرف را هم‌خوان کنید. هویت سرور و مواد CA مورد اعتماد نیز باید با آنچه کلاینت می‌پذیرد هم‌خوان باشد.

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

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

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

دسترسی‌پذیری یک قرارداد جداگانه است

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

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

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

مقالات مرتبط