OpenVPN اندروید بدون نشانی تونل مسیر اضافه نمی‌کند

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

خطا را به همان ترتیبی بخوانید که کارخواه اجرا می‌کند

‏VpnService.Builder در اندروید این دو مفهوم را جدا نگه می‌دارد: addAddress() نشانی را روی رابطی می‌گذارد که برنامه می‌سازد، addRoute() یک پیشوند مقصد می‌افزاید، و establish() تا زمانی که دست‌کم یک نشانی افزوده نشده باشد از ساخت رابط سرباز می‌زند. کارخواه OpenVPN نمایه و گزینه‌هایی را که کارساز می‌فرستد دقیقاً بر همان فراخوانی‌ها نگاشت می‌کند، پس پیوندی که هرگز نشانی‌ای را تجزیه نکند اصلاً نمی‌تواند رابط را بسازد.

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

بررسی 1: آیا کارساز نشانی‌ای در پاسخ می‌گذارد؟

برای یک خدمت مسیریابی‌شدهٔ OpenVPN نشانی از استخر کارساز یا از تخصیص هر کارخواه می‌آید و توپولوژی شکل آن را تعیین می‌کند. روی کارساز OpenVPN 2.4 یا تازه‌تر، خدمتی با توپولوژی زیرشبکه چنین است:

topology subnet
server 10.8.0.0 255.255.255.0
client-config-dir ccd

با این شکل کارساز چیزی مانند ifconfig 10.8.0.6 255.255.255.0 می‌فرستد. استقرار قدیمی‌تر topology net30 به‌جای آن نشانی همتا می‌فرستد، مثلاً ifconfig 10.8.0.6 10.8.0.5، پس نمایه‌ای که میان دو مدل جابه‌جا شده می‌تواند درست به نظر برسد در حالی که ماسک شبکهٔ نادرست را حمل می‌کند.

در گزارش پیوند کارخواه مجموعهٔ گزینه‌های فرستاده‌شده را جست‌وجو کنید. اگر هیچ سطر ifconfig نداشته باشد، کارساز هرگز نشانی نفرستاده یا کارخواه گزینه را رد کرده است. روی کارسازی که از client-config-dir استفاده می‌کند، پرونده‌ای که به نام common name گواهی نام‌گذاری شده باید وجود داشته باشد و تخصیص را حمل کند:

# ccd/phone-anna
ifconfig-push 10.8.0.6 255.255.255.0

بررسی 2: آیا کارخواه نشانی داده‌شده را نگه می‌دارد؟

پالایه‌ای که بیش از اندازه گسترده باشد دومین علت رایج است. pull-filter در OpenVPN 2.4 و تازه‌تر وجود دارد و وقتی چند پالایه با یک گزینه هم‌خوان باشند آخرین هم‌خوان برنده است، پس یک catch-all در انتها نشانی را بی‌خطا حذف می‌کند:

# removes every pushed option, including the address
pull-filter ignore "ifconfig"
pull-filter ignore "route"

پالایه را به گزینه‌ای که واقعاً می‌خواهید حذف شود محدود کنید و نشانی را به حال خود بگذارید:

# keeps the pushed address, drops one unwanted LAN route
pull-filter ignore "route 10.60.0.0"

توصیه به خاموش‌کردن همهٔ pullها معمولاً از کسی می‌آید که می‌خواهد از یک مسیر تنها خلاص شود. route-nopull کلید محدودتر است: ifconfig و دیگر گزینه‌های فرستاده‌شده را نگه می‌دارد و در همان حال مسیرهای فرستاده‌شده و گزینه‌های شبیه DHCP را رد می‌کند. وقتی واقعاً همین را می‌خواهید به کارش ببرید و پرسش نشانی را جداگانه پاسخ دهید.

بررسی 3: آیا نشانی از آنِ شماست که بنویسید؟

نشانی‌گذاری دستی تنها هنگامی موجه است که بهره‌بردار مقدار را به شما بدهد. اگر خودتان یکی بنویسید باید از زیرشبکهٔ کارخواه VPN بیاید، میان نشست‌های فعال یکتا باشد و با توپولوژی‌ای که کارساز اجرا می‌کند هم‌خوان باشد. رونوشت نشانی یک پل رومیزی یا میزبان موجود در LAN دوردست هر دو شرط را نقض می‌کند: گوشی نشانی‌ای را ادعا می‌کند که جای دیگر وجود دارد و دروازه هیچ راه بازگشتی به آن نخواهد داشت.

پیشوند LAN دوردست در یک مسیر مقصد است، هرگز هویت گوشی. مسیری برای 10.60.0.0/24 می‌گوید آن شبکه از راه تونل در دسترس است؛ دربارهٔ اینکه گوشی باید کدام نشانی 10.60.0.x را داشته باشد چیزی نمی‌گوید و گوشی نباید هیچ‌یک را داشته باشد. تخصیص‌های ایستا به سمت کارساز تعلق دارند، جایی که نمی‌توانند با استخر پویا برخورد کنند.

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

بررسی 4: آیا چیز دیگری جایگاه تونل را گرفته است؟

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

خدمتی که بر پل‌زدن اترنت پافشاری می‌کند بن‌بست دیگر است. برنامهٔ اندروید بدون root می‌تواند تونل IP بسازد، نه قطعهٔ اترنت پل‌شده، پس هیچ نشانی‌ای که بنویسید کارساز dev tap را به کار نمی‌اندازد؛ بهره‌بردار باید خدمت مسیریابی‌شده عرضه کند. هنگام گزارش مشکل، نام و نگارشهٔ کارخواه، مجموعهٔ گزینه‌های فرستاده‌شده، توپولوژی و گام دقیقی را که نشانی باید در آن پدیدار می‌شد بنویسید.

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