دو خط از گزارش OpenVPN با واژه‌های یکسان آغاز می‌شوند و تنها یکی از آنها از یک مشکل خبر می‌دهد. Could not determine IPv4/IPv6 protocol. Using AF_INET یک اعلان بازگشت است: پروفایل خانواده نشانی را باز گذاشته بود، پس سرویس‌گیرنده یکی را برگزید و ادامه داد. شاخه شکست اعلام می‌کند که هیچ سوکتی ساخته نشده و درخواست راه‌اندازی دوباره می‌کند. هر چیزی پس از پیشوند مشترک آنها را از هم جدا می‌کند، پس پیش از تغییر هر چیز، آن را تا آخر بخوانید.

اعلان بازگشت چه چیزی را گزارش می‌کند

OpenVPN خانواده صریح را از طریق proto udp4 یا proto udp6 می‌پذیرد و proto udp را زمانی می‌پذیرد که خانواده باید هنگام راه‌اندازی استخراج شود. در حالت دوم سرویس‌گیرنده اطلاعات اتصال محلی را بررسی و انتخاب می‌کند.

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

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

شاخه شکست چگونه است

بعدتر در همان کد سوکت شاخه‌ای هست که در آن هیچ سوکتی وجود ندارد. پیام کوتاه‌تر خانواده نشانی را ثبت می‌کند و درخواست راه‌اندازی دوباره می‌دهد، چون چیزی برای ادامه نمانده است. واژه‌های آغازین با بازگشت یکی است؛ نتیجه نه.

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

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

به جای هشدار، شنونده را بررسی کنید

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

ss -lunp | grep openvpn
ss -ltnp | grep openvpn

خانواده، نشانی و درگاه را با پروفایل مطابقت دهید. سطر 0.0.0.0:1194 تنها IPv4 است، در حالی که سطر [::]:1194 روی میزبان دوپشته بسته به تنظیم bindv6only می‌تواند هر دو خانواده را بپذیرد. اگر پروفایل udp بگوید و سوکت IPv4 باشد، کلاینت‌هایی که حل‌کننده آنها تنها رکورد AAAA برمی‌گرداند پیش از آنکه تونل حتی مذاکره شود شکست می‌خورند.

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

چه زمانی تحمیل خانواده درست است

میخ‌کوبی proto udp4 برای استقرار تنها IPv4 مناسب است: نام DNS تنها از نوع A، قواعد دیوار آتش برای یک نشانی v4، کلاینت‌های پشت اپراتورهایی که تنها نشانی v4 می‌دهند. ابهام را برمی‌دارد و مجموعه بعدی خطوط گزارش را پیش‌بینی‌پذیر می‌کند.

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

بر پایه نقطه‌های پایانی و کلاینت‌هایی که باید به آنها برسند انتخاب کنید. راهنمای OpenVPN 2.6 شکل‌های انتقال را مستند می‌کند و پیام برون‌داد آن انتخاب است، نه درون‌داد آن.

گزارش را باریک نگه دارید

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

پیشنهادهای بسته‌ای که همراه این هشدار می‌آیند بی‌ربط هستند تا زمانی که خطایی یک فایل اجرایی گمشده را نام ببرد.

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

مقالات مرتبط