ddclient خروجی VPN را منتشر می‌کند: منبع کشف را اصلاح کنید

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

تأیید کنید نام باید به چه چیزی برسد

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

نام خصوصی برای آدرس تونل یک کلاینت VPN مسئله دیگری با پاسخ دیگر است: جای آن DNS خصوصی است و به هیچ سرویس کشف عمومی نیاز ندارد. مخلوط کردن دو نیاز است که باعث می‌شود پیکربندی کارآمد شروع به انتشار آدرسی کند که کسی نخواسته است.

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

مقدار را پیش از هر تغییری بازتولید کنید

دو مسیر را جداگانه مشاهده کنید. با روشن بودن تونل، کاوشگر خروجی را گزارش می‌کند؛ با خاموش بودن تونل، یا با بسته‌شدن کاوشگر به واسط فیزیکی، آدرس خانه را گزارش می‌کند: curl --interface eth0 https://ifconfig.me. اگر این دو پاسخ متفاوت باشند، خطا را بدون دست زدن به به‌روزرسان بازتولید کرده‌اید.

سپس کلاینت را در حالتی اجرا کنید که پیکربندی را بدون انجام به‌روزرسانی بررسی می‌کند، مانند ddclient -verbose -noexec، و بخوانید کدام روش کشف را انتخاب کرده است. خروجی مفصل نام روش و مقدار به‌دست‌آمده را ذکر می‌کند و این همان واقعیتی است که پیش از هر ویرایشی لازم دارید.

کشف را به مسیر انتخاب‌شده هدایت کنید

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

برای مسیر وضعیت روتر، نسخه‌های جدیدتر ddclient از خانواده گزینه‌های usev4 و fwv4 استفاده می‌کنند، با یک الگوی ردکردن اختیاری برای متن اطراف صفحه. README نسخه نصب‌شده خود را بررسی کنید، زیرا نسخه‌های قدیمی همان ایده را با use و fw می‌نویسند و نام گزینه‌ای که از نسخه اشتباه کپی شده باشد در شروع به کار شکست می‌خورد.

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

رازها و نسخه‌ها را مرتب نگه دارید

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

ddclient README رویکردهای کشف و نام گزینه‌هایشان را مستند می‌کند. نتایج IPv4 و IPv6 را در یک رکورد مخلوط نکنید و فرض نکنید گزینه‌ای که در یک نسخه هست در نسخه دیگر هم وجود دارد.

مقدار را بررسی کنید، سپس دسترسی را

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

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