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

خطای اتصال نشانی محلی را نام می‌برد

وقتی OpenVPN گزارش می‌دهد که نمی‌تواند نشانی محلی را متصل کند، از سوکت انتقال صحبت می‌کند: نقطه پایانی UDP یا TCP که اتصال رمزگذاری‌شده را به peer می‌برد.

دستور صریح local از daemon می‌خواهد که آن سوکت را به یک نشانی محلی مشخص متصل کند. نشانی باید در فضای نام شبکه‌ای که فرایند در آن اجرا می‌شود وجود داشته باشد و در لحظه‌ای که کلاینت شروع می‌شود قابل تخصیص باشد.

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

local و remote در واقع چه چیزی را انتخاب می‌کنند

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

هیچ‌یک از این دو دستور هیچ ارتباطی با نشانی داخل تونل ندارد.

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

ip -brief address show
ip route get 203.0.113.10

نشانی درونی از سرور می‌آید

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

نوشتن local با یک نشانی درونی از سرور نمی‌خواهد که آن نشانی را تخصیص دهد. در بهترین حالت اتصال شکست می‌خورد؛ در بدترین حالت کلاینت نشانی میزبانی نامرتبط با همان مقدار پیدا می‌کند و آن را برای انتقال به کار می‌گیرد.

رابط‌هایی هم که باید خوانده شوند متفاوت‌اند. پارامترهای ifconfig و پیکربندی استخر درون را توصیف می‌کنند، در حالی که remote، local، proto و nobind بیرون را توصیف می‌کنند. جدا نگه داشتن این دو فهرست تقریباً هر مثال گیج‌کننده‌ای را که در یک انجمن پیدا می‌کنید توضیح می‌دهد. راهنمای OpenVPN 2.6 به همین دلیل آن‌ها را در بخش‌های جداگانه مستند می‌کند.

تله: تونل کاملی که انتقال خودش را می‌گیرد

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

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

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

عادتی که از سردرگمی جلوگیری می‌کند

هر نشانی در یک پروفایل را بخوانید و پیش از ویرایش تصمیم بگیرید به کدام لایه تعلق دارد.

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

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

مقالات مرتبط