گزارش‌هایی که می‌گویند VPN روی پورت 53 مسدود شده است، سه مشاهده را با هم اشتباه می‌گیرند که به دلایل مختلف شکست می‌خورند. حل نام نقطه پایانی پیش از وجود هر تونلی رخ می‌دهد، انتقال رمزگذاری‌شده گفت‌وگویی جداست و پرس‌وجوهای DNS که پس از آن انجام می‌شود سومین است. هر یک امضای شکست خودش را دارد و تنها یکی از آن‌ها اصلاً مربوط به DNS است.

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

سه گفت‌وگو، یک شماره پورت

نخستین گفت‌وگو جست‌وجوی نام برای نقطه پایانی است: دستگاه شما از resolver پیکربندی‌شده خود می‌پرسد که vpn.example.com کجاست و این پاسخ پیش از آن‌که کلاینت حتی یک بسته تونل بفرستد، از طریق DNS معمولی می‌رسد. دومی خود انتقال OpenVPN است که به نشانی حاصل از جست‌وجو، با هر پروتکل و پورتی که پروفایل نام می‌برد، متصل می‌شود. سومی پس از برپا شدن تونل رخ می‌دهد، هنگامی که برنامه‌ها نام می‌خواهند و تنظیمات resolver که فرستاده شده تعیین می‌کند چه کسی پاسخ دهد.

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

ConversationWhen it happensWhat has to be true
Endpoint lookupBefore the client contacts a hostnameAn underlying resolver path can answer for the endpoint name
OpenVPN transportDuring tunnel establishmentThe gateway listens on its configured transport, address and port, and nothing filters it
Application DNSDuring or after the protected sessionA resolver the client can reach, plus routing that carries its queries

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

شماره پورت نام برنامه را نمی‌گوید

پورت 53 بر اساس عرف DNS را حمل می‌کند و اپراتور OpenVPN نیز می‌تواند شنونده‌ای آنجا منتشر کند، و دقیقاً به همین دلیل شماره شناسه ضعیفی است. نشست OpenVPN روی UDP 53 هنوز یک نشست OpenVPN است و پرس‌وجوی DNS به سروری روی پورت 53 چیزی درباره مجاز بودن تونل نمی‌گوید. خطوط proto و remote پروفایل نقطه پایانی بیرونی را تعریف می‌کنند؛ شماره پورت به‌تنهایی چیزی را تعریف نمی‌کند.

این هنگام عیب‌یابی دو طرفه است: یک کاوش UDP عمومی به پورت 53 ثابت می‌کند که پورتی پاسخ می‌دهد، نه این‌که سرویس VPN پاسخ می‌دهد. با کلاینت واقعی و پروفایل واقعی آزمایش کنید، زیرا تنها این همان دست‌دادنی را تمرین می‌کند که سرویس انتظار دارد.

پیش از سرزنش شبکه، وجود شنونده را ثابت کنید

روی سرور با ss -lunp | grep 53 تأیید کنید چه چیزی مقید شده است و آن را با پروتکل و پورت پروفایل مقایسه کنید. از شبکه کلاینت، کلاینت را با جزئیات بیشتر اجرا کنید تا گزارش نشان دهد کدام نشانی و انتقال را امتحان کرده است. اگر سرور گوش می‌دهد و بسته‌های کلاینت نمی‌رسند، مسیر یا سیاست آن‌ها را رد می‌کند و این گفت‌وگویی برای مالک شبکه است نه دلیلی برای تغییر پورت.

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

DNS را پس از تونل، جداگانه بررسی کنید

پس از برپا شدن تونل، وضعیت resolver را روی رابط VPN بررسی کنید و یک نام داخلی و یک نام عمومی را پرس‌وجو کنید. اگر نام‌های داخلی شکست بخورند در حالی که تونل ترافیک حمل می‌کند، تنظیمات DNS فرستاده‌شده اعمال نشده است، که مسئله یکپارچه‌سازی کلاینت است نه انتقال. اگر نام‌های عمومی شکست بخورند و نام‌های داخلی کار کنند، سیاست تونل تفکیک‌شده همان کاری را می‌کند که برایش پیکربندی شده است.

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

مقالات مرتبط