معماری دومسیره با DNS هوشمند: هدایت کاربر داخلی و خارجی به سرور درست

اگر مطلبِ «در دسترس ماندن سایت هنگام قطعی اینترنت بین‌الملل» را خوانده باشید، می‌دانید که سه معماری روی میز است. این راهنما وارد جزئیاتِ فنیِ گزینهٔ دوم می‌شود: چطور یک دامنه را طوری تنظیم کنیم که کاربر ایرانی به سرورِ داخلی برود، کاربر خارجی به سرورِ خارجی، و اگر یکی از دو سرور خوابید، ترافیک خودکار به دیگری منتقل شود.

سه سطحِ متفاوت که همه «هوشمند» صدا زده می‌شوند

فروشندگان هر سه را با یک نام می‌فروشند، اما رفتارشان کاملاً متفاوت است:

اشتباهِ خیلی رایج: گذاشتنِ دو رکورد A با دو آی‌پی، به این امید که اگر یکی خوابید کاربر به دیگری برود. این Round Robin است، نه Failover. سرورِ نام از خواب بودنِ آی‌پی خبر ندارد و همان را هم پاسخ می‌دهد؛ نتیجه اینکه نیمی از کاربران خطا می‌گیرند.

چرا در ایران GeoDNS مهم‌تر از Failover است

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

این تفاوت، جهتِ طراحی را عوض می‌کند: به‌جای تکیه بر Failover، از ابتدا بر اساسِ موقعیتِ درخواست‌کننده تصمیم بگیرید و Failover را فقط برای خرابیِ واقعیِ سرور نگه دارید.

اگر می‌خواهید بررسیِ سلامت واقعاً کار کند

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

#!/bin/bash
# اگر سه بار پشت سر هم پاسخ نگرفتیم، رکورد را به آی‌پی داخلی ببر
FAILS=0
for i in 1 2 3; do
  curl -fsS --max-time 8 https://example.com/health.txt >/dev/null || FAILS=$((FAILS+1))
  sleep 5
done
[ "$FAILS" -ge 3 ] && /usr/local/bin/dns-switch.sh internal

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

واقعیتِ TTL: عددی که وعده می‌دهد و همیشه عمل نمی‌کند

TTL به درخواست‌کننده‌ها می‌گوید پاسخ را چند ثانیه نگه دارند. تصورِ رایج این است که با TTL برابر ۶۰، جابه‌جایی حداکثر یک دقیقه طول می‌کشد. در عمل چند لایه این عدد را نقض می‌کنند:

• درخواست‌کنندهٔ اپراتور: برای کاهشِ بار، گاهی مقدارِ کمینه‌ای برای خودش می‌گذارد و TTLهای کوتاه را کشدار می‌کند.
• مرورگر: کش داخلی خودش را دارد و مستقل از سیستم‌عامل عمل می‌کند.
• اتصالِ باز: کاربری که همین حالا اتصالِ فعالی به آی‌پیِ قبلی دارد، تا بسته شدنِ آن اتصال جابه‌جا نمی‌شود.

راهکارِ عملی: ۲۴ ساعت پیش از هر تغییرِ معماری، TTL را روی ۳۰۰ ثانیه بیاورید. تغییر را انجام دهید، چند ساعت پایدار بمانید، سپس به مقدارِ عادی برگردید. کاهشِ TTL در لحظهٔ بحران فایده‌ای ندارد، چون پاسخِ قبلی با TTLِ بلند از قبل کش شده است.

معماریِ پیشنهادی برای سایتِ ایرانی با مخاطبِ دوگانه

1. سرورِ نام: دست‌کم دو سرورِ نام که یکی روی زیرساختِ داخلی باشد. بی این کار، در اختلال حتی تبدیلِ نام به آی‌پی هم انجام نمی‌شود.
2. رکوردِ ریشه با تفکیکِ جغرافیایی: درخواست‌کنندهٔ ایرانی آی‌پیِ داخلی بگیرد، بقیه آی‌پیِ خارجی.
3. یک زیردامنهٔ ثابت برای هر مقصد: مثلاً ir.example.com و eu.example.com. این کار عیب‌یابی را از حالتِ حدس‌وگمان بیرون می‌آورد؛ می‌توانید هر مقصد را جدا آزمایش کنید.
4. Failover فقط برای خرابیِ واقعی با نقطهٔ پایشِ داخلی.
5. گواهیِ امنیتی روی هر دو سرور برای همان دامنه. اگر یکی گواهی نداشته باشد، کاربر به‌جای سایت، هشدارِ امنیتی می‌بیند — که از خطای شبکه هم بدتر است، چون اعتماد را می‌شکند.

چطور بفهمیم درست کار می‌کند؟

بررسیِ پاسخِ سرورهای نام برای هر منطقه، ساده‌ترین آزمون است:

# پاسخ برای درخواست‌کنندهٔ عمومی
dig +short example.com @8.8.8.8

# پاسخ مستقیم از سرورِ نامِ خودتان
dig example.com @ns1.example.com

# دیدنِ TTLِ واقعیِ باقی‌مانده
dig example.com | grep -A1 "ANSWER SECTION"

اگر دو خروجیِ اول با هم فرق داشتند، تفکیکِ جغرافیایی فعال است. برای اطمینان از سمتِ کاربرِ ایرانی، از یک سرورِ داخلی همان دستور را تکرار کنید.

از سرویسِ DNS چه چیزهایی بپرسید

پیش از خرید یا مهاجرت، این پنج مورد را روشن کنید — نبودِ هر کدام می‌تواند کلِ طرح را بی‌اثر کند:

• تفکیکِ جغرافیایی با دقتِ کشور: برخی سرویس‌ها فقط در سطحِ قاره تفکیک می‌کنند که برای تفکیکِ ایران از بقیه بی‌فایده است.
• رابطِ برنامه‌نویسی برای تغییرِ رکورد: بدونِ آن، جابه‌جایی خودکار ممکن نیست و باید دستی وارد پنل شوید.
• کمینهٔ TTLِ مجاز: اگر سرویس اجازهٔ TTLِ کمتر از ۳۰۰ ثانیه نمی‌دهد، سرعتِ جابه‌جایی محدود می‌شود.
• موقعیتِ سرورهای نام: دست‌کم یکی باید از داخل ایران قابلِ دسترس باشد.
• تعدادِ درخواستِ مجاز: برای سایتِ پربازدید، سقفِ ماهانهٔ درخواست را بررسی کنید.

چهار اشتباهی که این معماری را بی‌اثر می‌کند

1. گواهیِ نصب‌نشده روی سرورِ دوم: کاربر به‌جای سایت هشدارِ امنیتی می‌بیند.
2. ماندنِ نشانیِ فایل‌ها روی دامنهٔ سرورِ اصلی: صفحه از سرورِ داخلی می‌آید اما تصاویر و شیوه‌نامه از سرورِ خارجی خوانده می‌شوند. از نشانیِ نسبی استفاده کنید.
3. فراموش کردنِ رکوردهای MX: اگر ایمیلِ دامنه را هم جابه‌جا کنید، نامه‌ها به سرورِ اشتباه می‌روند.
4. نبودِ پایشِ داخلی: بدونِ آن هرگز نمی‌فهمید مسیرِ ایرانی خراب شده است.

فهرستِ بازبینیِ راه‌اندازی

• دو سرورِ نام فعال است و یکی از داخل قابلِ دسترس است.
• TTLِ رکوردهای اصلی پیش از تغییر روی ۳۰۰ آمده است.
• هر دو سرور گواهیِ معتبر برای همان دامنه دارند.
• دو زیردامنهٔ آزمایشی برای دسترسیِ مستقیم به هر مقصد ساخته شده است.
• نقطهٔ پایش داخل ایران است و اسکریپتِ جابه‌جایی آزمایش شده است.
• محتوای دو سرور با فرایندِ خودکار همگام می‌شود.
• فایلِ سلامت سبک است و به پایگاه داده دست نمی‌زند.

هزینه و پیچیدگی را دستِ‌کم نگیرید

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

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