قطعی اینترنت بین‌الملل؛ سرور مجازی را چطور سرپا نگه داریم؟

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

در قطعی اینترنت بین‌الملل چه چیزی از کار می‌افتد؟

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

• کاربران داخلی هنوز می‌توانند به IP سرور برسند، به شرط آنکه دامنه برایشان resolve شود.
• هر سرویسی که سرور برای کار عادی از خارج می‌گیرد قطع می‌شود: DNS عمومی خارجی، سرورهای زمان، مخازن پکیج، Docker Hub، GitHub، APIهای خارجی، سرور ایمیل مقصد مثل Gmail و سرویس‌های مانیتورینگ خارجی.
• سرورهای خارج از کشور برای کاربران داخل در دسترس نیستند، حتی اگر کاملاً سالم باشند.

بنابراین هدف آمادگی این است که مسیر «کاربر داخلی ← سرور داخلی» هیچ وابستگی پنهانی به خارج نداشته باشد.

محل سرور؛ اولین تصمیم

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

DNS دامنه و Resolver سرور

DNS رایج‌ترین دلیل از دسترس خارج شدن سایتی است که خود سرورش داخلی است. دو بخش جدا را بررسی کنید:

۱. Nameserverهای دامنه (Authoritative)

اگر NSهای دامنه روی سرویسی خارجی مثل Cloudflare باشند، Resolverهای اپراتورهای داخلی در زمان قطعی نمی‌توانند رکوردهای شما را بپرسند و دامنه برای کاربر ایرانی resolve نمی‌شود. حتی رکوردهای کش‌شده هم پس از پایان TTL منقضی می‌شوند. راهکار، استفاده از DNS میزبانی‌شده در داخل کشور یا داشتن دست‌کم یک Nameserver داخلی (Secondary) است که رکوردها را از Primary دریافت می‌کند. مفاهیم پایه در DNS چیست.

۲. Resolver خود سرور

اگر در /etc/resolv.conf یا تنظیمات systemd-resolved فقط 8.8.8.8 یا 1.1.1.1 ثبت شده باشد، هر درخواستی که سرور به یک نام دامنه می‌فرستد (حتی به سرویس داخلی) ممکن است شکست بخورد. Resolver ارائه‌دهنده دیتاسنتر یا یک DNS داخلی را به‌عنوان گزینه اول قرار دهید:

# /etc/systemd/resolved.conf
[Resolve]
DNS=<DATACENTER-RESOLVER> <SECOND-IRAN-RESOLVER>
FallbackDNS=1.1.1.1 8.8.8.8

sudo systemctl restart systemd-resolved
resolvectl status

گواهی SSL و تمدید خودکار

گواهی‌های Let’s Encrypt حداکثر ۹۰ روز اعتبار دارند و Certbot معمولاً ۳۰ روز مانده به انقضا آن‌ها را تمدید می‌کند. سرور ACME در خارج از کشور است، پس در قطعی طولانی تمدید انجام نمی‌شود و اگر قطعی از ۳۰ روز فراتر برود، سایت با خطای گواهی منقضی روبه‌رو خواهد شد.

• تاریخ انقضای همه گواهی‌ها را پایش کنید: sudo certbot certificates
• وقتی نشانه‌های محدودیت دیده می‌شود، تمدید را زودتر انجام دهید: sudo certbot renew --force-renewal (به محدودیت تعداد صدور Let’s Encrypt توجه کنید و این کار را فقط برای گواهی‌های لازم انجام دهید).
• برای سرویس‌های حیاتی، گواهی تجاری با اعتبار طولانی‌تر هم گزینه‌ای است که وابستگی به تمدید مکرر را کم می‌کند.

بررسی اعتبار گواهی در مرورگر کاربر به ارتباط با صادرکننده نیاز ندارد؛ مشکل فقط صدور و تمدید است. مبانی در SSL چیست.

همگام‌سازی زمان (NTP)

سرورهای پیش‌فرض زمان مثل ntp.ubuntu.com خارج از کشورند. ساعت سرور بدون همگام‌سازی کم‌کم جابه‌جا می‌شود و پس از چند هفته روی کدهای یک‌بار مصرف (TOTP)، توکن‌ها، لاگ‌ها و تکثیر دیتابیس اثر می‌گذارد. سرور زمان داخلی یا سرور NTP دیتاسنتر را اضافه کنید:

# /etc/chrony/chrony.conf
server <DATACENTER-NTP> iburst prefer
pool ir.pool.ntp.org iburst

sudo systemctl restart chrony
chronyc sources -v

مخازن پکیج، Docker و Git

در قطعی، apt update، docker pull، pip install و npm install شکست می‌خورند. این یعنی نمی‌توانید سرور جدید بسازید، وصله امنیتی نصب کنید یا یک کانتینر را از نو بالا بیاورید. راهکارها:

• مخازن سیستم‌عامل را به یک میرور داخلی تغییر دهید یا میرور داخلی را به‌عنوان جایگزین آماده نگه دارید.
• Imageهای Docker که استفاده می‌کنید را روی Registry خصوصی خودتان نگه دارید تا وابسته به Docker Hub نباشید.
• مخزن کد را علاوه بر GitHub، در یک Gitea یا GitLab داخلی هم Mirror کنید تا Deploy متوقف نشود.

روش کامل تنظیم این میرورها و ساخت کش اختصاصی در میرور داخلی Docker، apt، pip و npm آمده است.

بکاپ و نسخه داخلی داده

بکاپ در خارج از کشور برای حفاظت در برابر حوادث بزرگ ارزشمند است، اما در زمان قطعی به آن دسترسی ندارید. یعنی اگر در همان روزها دیسک خراب شود یا داده‌ها حذف شوند، بازیابی ممکن نیست. طبق قانون ۳-۲-۱ دست‌کم یک نسخه بکاپ را روی ذخیره‌سازی جداگانه داخل کشور نگه دارید و بازیابی از آن را آزمایش کنید. توضیح بیشتر در بکاپ سرور چیست و تفاوت Snapshot و Backup.

مانیتورینگ و هشدار

سرویس‌های مانیتورینگ خارجی در زمان قطعی سرور شما را «Down» گزارش می‌کنند، در حالی که برای کاربران داخلی سالم است. از طرف دیگر، هشدارهایی که از طریق تلگرام، Slack یا ایمیل‌های خارجی ارسال می‌شوند، به شما نمی‌رسند. یک مانیتور داخلی (مثل Uptime Kuma یا Zabbix) روی سرور دیگری در داخل کشور راه بیندازید و یک کانال هشدار داخلی مثل پیامک یا پیام‌رسان داخلی برای آن تعریف کنید.

دسترسی مدیریتی به سرور

• اگر خودتان داخل کشور هستید، SSH مستقیم به IP سرور داخلی برقرار می‌ماند. Fail2ban و فایروال را طوری تنظیم کنید که IP دفتر یا اپراتور شما مسدود نشود؛ راهنما در امن‌سازی SSH.
• اگر مدیر سرور یا تیم پشتیبانی خارج از کشور است، در زمان قطعی دسترسی ندارد. یک نفر یا یک تیم پشتیبانی داخلی را با دسترسی مستند و آزمایش‌شده آماده داشته باشید.
• رمزها و کلیدهای دسترسی را فقط در سرویس‌های ابری خارجی نگه ندارید؛ نسخه امن و رمزنگاری‌شده‌ای در دسترس داخلی داشته باشید.

چک‌لیست آمادگی

بهترین زمان آزمایش این چک‌لیست، پیش از قطعی است. اگر برنامه بازیابی از حادثه دارید، سناریوی «قطع ارتباط بین‌الملل» را به آن اضافه کنید؛ راهنما در برنامه بازیابی از حادثه.

سوالات متداول