وان سرور | هاست، سرور و آموزش

⚠️ اطلاعیه اختلال سرویس از سمت رسپینا کاربران گرامی وان‌سرور، طبق اطلاعیه دریافتی از شرکت داده‌پردازی رسپینا، به دلیل انجام عملیات ارتقا و به‌روزرسانی تجهیزات شبکه رسپینا، در روز چهارشنبه ۲۲ مهر ۱۴۰۵ از ساعت ۰۲:۰۰ الی ۰۷:۰۰ بامداد، برخی سرویس‌هایی که از زیرساخت این شرکت استفاده می‌کنند ممکن است با قطعی یا اختلال موقت مواجه شوند. این اختلال از سمت زیرساخت شرکت رسپینا بوده و ارتباطی با شبکه و تجهیزات وان‌سرور ندارد. از صبر و همراهی شما سپاسگزاریم. 🌹 وان‌سرور | One Server 🌐 one3erver.com

گاهی Load Average بالاست ولی از روی CPU، RAM یا دیسک به‌تنهایی نمی‌فهمی سیستم دقیقاً کجا گیر کرده؛ اینجا Linux PSI می‌تونه سرنخ خیلی خوبی بده. PSI میزان زمانی رو نشان می‌دهد که پردازش‌ها به‌خاطر کمبود CPU، Memory یا I/O منتظر مانده‌اند. برای یک بررسی سریع این سه فایل رو ببین:

cat /proc/pressure/cpu
cat /proc/pressure/memory
cat /proc/pressure/io

اگر مقدار avg10 در یکی از بخش‌ها بالا می‌رود، یعنی در ۱۰ ثانیه اخیر فشار واقعی همان منبع بیشتر شده. نکته مهم اینه که PSI جای بررسی top یا iostat رو نمی‌گیره؛ کمک می‌کنه قبل از عیب‌یابی عمیق بفهمی باید دنبال CPU، حافظه یا دیسک بگردی. 🔗 کانال وان سرور #VPS #Linux

گاهی یک مجوز اشتباه روی فایل یا پوشه، بیشتر از چیزی که فکر می‌کنی دردسر می‌سازه؛ مخصوصاً وقتی برای رفع سریع Permission Error از 777 استفاده شده و بعد همون‌طور باقی مونده. برای یک ممیزی ساده، فایل‌ها و پوشه‌های world-writable رو پیدا کن:

find /etc /var/www /opt -xdev -perm -0002 -ls 2>/dev/null

بعد نتیجه‌ها رو کورکورانه chmod نکن؛ اول Owner، Group و نیاز واقعی سرویس رو بررسی کن. برای مسیرهای وب معمولاً مجوز حداقلی و مالکیت درست بهتر از بازکردن دسترسی برای همه است. مجوز موقت اگر جمع نشه، خیلی زود تبدیل به تنظیم دائمی می‌شه. 🔗 کانال وان سرور #امنیت #Linux

گاهی تونل WireGuard بین Entry و Exit کاملاً Up است و Handshake هم تازه می‌شود، اما بخشی از ترافیک برگشتی بی‌صدا Drop می‌شود. در معماری چندنودی، یکی از چیزهایی که باید چک کنی rp_filter است؛ چون مسیر نامتقارن می‌تواند Reverse Path Check را حساس کند. برای بررسی اولیه این مقادیر را ببین:

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.default.rp_filter
sysctl net.ipv4.conf.wg0.rp_filter

اگر رفت و برگشت از مسیرهای متفاوت انجام می‌شود، قبل از خاموش‌کردن سراسری این کنترل، Route و Policy Routing را بررسی کن و تغییر را فقط روی Interface لازم تست کن. اینجا هدف حذف یک کنترل امنیتی نیست؛ هدف پیدا کردن Drop ناشی از طراحی مسیر است. 🔗 کانال وان سرور #WireGuard #VPN

گاهی سرویس روی VPS بالا و CPU هم عادیه، ولی اتصال‌ها مکث می‌کنن یا سرعت نوسانی می‌شه. قبل از دست‌کاری اپلیکیشن، بد نیست TCP Retransmission رو بررسی کنی؛ چون Packet Loss، مسیر بد یا مشکل MTU می‌تونه باعث ارسال مجدد بسته‌ها بشه. برای یک بررسی سریع این دو دستور مفیدن:

ss -ti
nstat -az | grep -E 'TcpRetransSegs|TcpExtTCPLostRetransmit'

اگر Retransmit در زمان اختلال سریع بالا می‌ره، بعدش مسیر رو با mtr و MTU رو بررسی کن. نکته مهم اینه که Retransmission خودش علت نهایی نیست؛ یک نشونه‌ست که کمک می‌کنه مشکل شبکه رو از CPU، RAM یا خود سرویس جدا کنی. 🔗 کانال وان سرور #VPS #Linux

گاهی سایت وردپرسی کند می‌شود ولی CPU و RAM در نگاه اول عادی‌اند؛ اینجا حدس‌زدن درباره افزونه‌ها معمولاً وقت تلف می‌کند. برای پیدا کردن درخواست PHP که واقعاً گیر کرده، PHP-FPM slowlog خیلی کاربردی است. برای Pool مربوط به سایت، این تنظیم‌ها را فعال کن: request_slowlog_timeout = 5s slowlog = /var/log/php-fpm/www-slow.log بعد PHP-FPM را Reload کن و هنگام کندی Slowlog را بررسی کن. اگر یک Plugin، Theme یا تابع PHP مرتب در Stack Trace تکرار شود، سرنخ واقعی داری؛ بدون اینکه کورکورانه کش را پاک یا افزونه‌ها را یکی‌یکی خاموش کنی. نکته مهم اینه که مسیر فایل و نام سرویس بین توزیع‌ها و نسخه‌های PHP فرق می‌کند؛ قبل از Reload حتماً کانفیگ را تست کن. 🔗 کانال وان سرور #WordPress #Hosting

گاهی VPS کُند می‌شه ولی CPU در ظاهر بیکار است؛ اینجا قبل از متهم کردن پردازنده، I/O Wait رو چک کن. وقتی دیسک دیر جواب می‌ده، پردازش‌ها منتظر I/O می‌مونن و سرور حس سنگینی می‌ده، حتی اگر مصرف CPU پایین باشه. برای شروع این دو تست کوتاه رو بزن:

vmstat 1 5
iostat -xz 1 5

توی vmstat ستون wa رو ببین؛ اگر بالا می‌مونه، سراغ دیسک برو. بعد در iostat به await و %util نگاه کن تا مشخص بشه تأخیر واقعاً از Storage میاد یا نه. نکته مهم اینه که یک عدد لحظه‌ای ملاک نیست؛ چند نمونه پشت‌سرهم بگیر و هم‌زمان ببین کدوم پروسه بیشترین I/O رو ایجاد می‌کنه. 🔗 کانال وان سرور #VPS #Linux

فرض کن ساعت دو شب مانیتورینگ هشدار می‌ده و یک VPS ناگهان کند شده؛ هنوز نمی‌دونی مشکل از CPU، RAM، دیسک یا شبکه است. اولین دستوری که می‌زنی کدومه؟ 👇 گزینه خودت رو انتخاب کن و بعد با این چک سریع مقایسه کن:

uptime
free -h
vmstat 1 5
df -h

نکته اینجاست که از روی یک عدد نباید حکم بدی؛ Load بالا می‌تونه از CPU باشه، ولی I/O wait یا فشار حافظه هم می‌تونه همون ظاهر رو بسازه. برای Incident واقعی، اول وضعیت کلی رو بگیر و بعد برو سراغ ابزار تخصصی‌تر. 🔗 کانال وان سرور #Linux #VPS

گاهی خطرناک‌ترین دسترسی روی سرور نه پورت بازه، نه یک سرویس عجیب؛ یک خط فراموش‌شده در sudoers می‌تونه کاربر عادی رو عملاً به root برسونه. مخصوصاً وقتی برای اسکریپت یا مانیتورینگ، NOPASSWD گذاشتی و بعد یادت رفته جمعش کنی. برای یک بررسی سریع، دسترسی‌های sudo رو این‌طور ببین:

sudo -l -U USERNAME
grep -R "NOPASSWD" /etc/sudoers /etc/sudoers.d 2>/dev/null

بهتره به‌جای دسترسی کلی، فقط همان command لازم را با مسیر کامل مجاز کنی و بعد از تغییر هم فایل را با visudo -c اعتبارسنجی کنی. دسترسی موقت اگر جمع نشه، خیلی راحت تبدیل به مسیر دائمی Privilege Escalation می‌شه. 🔗 کانال وان سرور #امنیت #Linux

گاهی تو معماری چندنودی VPN تونل سالمه و حتی Ping هم رد می‌شه، ولی ترافیک بعضی کاربرها از Exit اشتباه بیرون می‌ره. اینجا معمولاً مشکل خود تونل نیست؛ Policy Routing و markها رو باید چک کرد. برای شروع ببین Rule و Route واقعاً با mark موردنظر هماهنگ‌اند یا نه:

ip rule show
ip route show table all | grep -E 'default|wg|tun'
nft list ruleset | grep -i mark

نکته مهم اینه که mark کردن Packet به‌تنهایی کافی نیست؛ باید Rule متناظر به جدول درست اشاره کنه و مسیر برگشت هم با معماری Entry/Exit سازگار باشه. وگرنه تونل Up می‌مونه ولی بخشی از Sessionها نامتقارن می‌شن و بی‌دلیل Drop می‌خورند. 🔗 کانال وان سرور #VPN #Routing

گاهی VPS ظاهراً بدون دلیل یک سرویس رو می‌کُشه؛ نه CPU پره، نه دیسک مشکل داره، ولی پروسه ناگهان ناپدید می‌شه. یکی از مظنون‌های اصلی OOM Killer لینوکسه؛ وقتی RAM و Swap جواب نمی‌دن، کرنل برای زنده نگه داشتن سیستم یک پروسه رو قربانی می‌کنه. 😅 برای چک سریع، این لاگ‌ها رو ببین:

journalctl -k | grep -Ei 'oom|out of memory|killed process'

بعد مصرف حافظه رو با این دو دستور بررسی کن:

free -h
ps aux --sort=-%mem | head

نکته مهم اینه که صرفاً RAM رو بیشتر نکنی؛ اول ببین کدوم سرویس نشت حافظه داره، Swap اصلاً فعاله یا نه و محدودیت Memory سرویس/کانتینر درست تنظیم شده یا نه. 🔗 کانال وان سرور #VPS #Linux

گاهی کش Cloudflare روشنه، ولی صفحه هنوز هر بار مستقیم از سرور جواب می‌گیره. قبل از اینکه سراغ Purge و تنظیمات عجیب بری، هدر پاسخ رو ببین؛ معمولاً خودش سرنخ رو لو می‌ده. برای بررسی سریع این دستور کافیه:

curl -I https://example.com

اگر CF-Cache-Status: HIT دیدی، پاسخ از کش لبه آمده. مقدار MISS یعنی این درخواست در کش نبوده و DYNAMIC معمولاً یعنی Cloudflare آن پاسخ را برای کش‌کردن واجد شرایط ندیده. نکته مهم اینه که قبل از دست‌کاری Cache Rules، کوکی‌ها، Cache-Control و نوع URL رو هم بررسی کنی؛ وگرنه Purge کردن فقط چند دقیقه حس پیروزی می‌ده! 😄 🔗 کانال وان سرور #Cloudflare #هاستینگ

گاهی روی نودهای VLESS/REALITY همه‌چیز از نظر کانفیگ درست به‌نظر می‌رسه، ولی بخشی از اتصال‌ها ناپایدار می‌شن. قبل از دست‌کاری Core، مقصدی که برای Reality انتخاب کردی رو از خود سرور بررسی کن؛ چون مسیر، SNI و TLS مقصد باید واقعاً قابل اتکا باشن. برای یک چک ساده، هندشیک TLS و گواهی مقصد رو از همان نود ببین:

openssl s_client -connect example.com:443 -servername example.com </dev/null

اگر اتصال به مقصد timeout می‌شه، گواهی غیرمنتظره می‌بینی یا مسیر آن از دیتاسنتر ناپایداره، عوض‌کردن UUID و پورت معمولاً درمان مسئله نیست. اول خود مقصد و دسترسی نود به آن را پایدار کن، بعد سراغ تنظیمات Reality برو. 🔗 کانال وان سرور #VLESS #Reality

گاهی بعد از ریبوت VPS می‌بینی سرور بالا آمده، ولی یکی از سرویس‌ها با تأخیر آماده می‌شود و کل استک چند ده ثانیه منتظر می‌ماند. به‌جای حدس‌زدن، زنجیره بوت systemd را ببین. برای پیدا کردن سرویس‌هایی که مسیر بوت را کند کرده‌اند این دو دستور خیلی کاربردی‌اند:

systemd-analyze blame
systemd-analyze critical-chain

نکته اینجاست که blame فقط زمان هر واحد را نشان می‌دهد؛ اما critical-chain وابستگی‌هایی را پیدا می‌کند که واقعاً مسیر بوت را عقب انداخته‌اند. پس صرفاً طولانی‌ترین عدد را مقصر اعلام نکن؛ اول زنجیره وابستگی را ببین، بعد سراغ همان سرویس برو. 🔗 کانال وان سرور #Linux #VPS

خیلی وقت‌ها Fail2ban نصب شده و همه خیال‌شون راحته؛ ولی چند ماه بعد می‌بینی سرویس بالا بوده و عملاً هیچ IPای را Ban نمی‌کرده. برای یک چک سریع اول وضعیت Jail مربوط به SSH رو ببین:

fail2ban-client status sshd

بعد حتماً Backend فایروال رو هم بررسی کن؛ روی سیستم‌های جدید ممکنه انتظار iptables داشته باشی ولی سرور با nftables کار کنه. برای دیدن Ruleهای فعال:

nft list ruleset | grep -i f2b

نکته مهم اینه که «Active بودن سرویس» با «واقعاً Block شدن مهاجم» یکی نیست. بعد از هر تغییر فایروال یا مهاجرت سیستم‌عامل، مسیر Ban رو دوباره تست کن. 🔗 کانال وان سرور #امنیت #VPS

گاهی دیسک VPS بی‌سروصدا پر می‌شه و وقتی سراغ فایل‌های معمولی می‌ری چیز عجیبی پیدا نمی‌کنی؛ یکی از جاهایی که ارزش بررسی داره لاگ‌های systemd journal ـه. اول ببین journal واقعاً چقدر فضا گرفته:

journalctl --disk-usage

اگر حجمش غیرعادی بود، به‌جای پاک‌کردن دستی فایل‌های /var/log/journal می‌تونی خود journal رو کنترل‌شده جمع‌وجور کنی. مثلاً نگه داشتن حداکثر ۷ روز اخیر:

journalctl --vacuum-time=7d

یا محدود کردن حجم آرشیوها به حدود 500 مگابایت:

journalctl --vacuum-size=500M

نکته: قبل از vacuum کردن، اگر سرور مشکل یا سرویس ناپایداری داره اول لاگ موردنیازت رو بررسی یا ذخیره کن؛ چون لاگی که حذف شد برای عیب‌یابی بعدی برنمی‌گرده. 😄 اگر journal دوباره خیلی سریع بزرگ شد، پاکسازی درمان اصلی نیست؛ باید ببینی کدام سرویس مدام خطا می‌نویسه و ریشه همون رو درست کنی. 🔗 کانال وان سرور #لینوکس #VPS

گاهی سرور زیر بار شبکه هنوز CPU و RAM بدی نداره، ولی اتصال‌های جدید Timeout می‌شن، بعضی درخواست‌ها رندوم می‌پرن یا NAT رفتار عجیب پیدا می‌کنه. اینجا یکی از چیزهایی که ارزش چک‌کردن داره conntrack ـه. کرنل لینوکس برای Connection Tracking تعداد اتصال‌های در حال رهگیری رو نگه می‌داره. اول ببین الان چند Entry داری و سقف چقدره:

sysctl net.netfilter.nf_conntrack_count
sysctl net.netfilter.nf_conntrack_max

مثلاً اگر nf_conntrack_count مدام خیلی نزدیک nf_conntrack_max باشه، احتمالاً جدول تحت فشاره. برای دیدن هشدارهای کرنل هم این تست سریع بد نیست:

dmesg | grep -i conntrack

اگر پیامی مثل nf_conntrack: table full, dropping packet دیدی، دیگه سرنخ خیلی جدی داری؛ پکت‌های جدید واقعاً دارن Drop می‌شن. نکته: سریع nf_conntrack_max رو چند برابر نکن و خیال خودت رو راحت نکن 😄 اول ببین این حجم اتصال طبیعیه یا یک سرویس، NAT شلوغ، اسکن یا ترافیک غیرعادی جدول رو پر کرده. بالا بردن سقف، مصرف RAM رو هم بیشتر می‌کنه و ممکنه فقط اصل مشکل رو عقب بندازه. 🔗 کانال وان سرور #لینوکس #شبکه

هشدار امنیتی جدید برای کاربران MikroTik جدی است. زنجیره MikroTrick در RouterOS می‌تواند روی دستگاه‌هایی که SSH آن‌ها از اینترنت در دسترس است، در شرایط مشخص به تصرف کامل روتر منجر شود. نسخه‌های اصلاح‌شده شامل 7.24.2، 7.23.4، 7.25 beta 3 و 6.49.21 هستند. اقدام فوری این است که RouterOS را به نسخه اصلاح‌شده ارتقا بدهید و دسترسی SSH را فقط به IPهای مورد اعتماد، شبکه مدیریت یا VPN محدود کنید. بعد از آپدیت هم کاربران، Scriptها، Scheduler، Firewall و Logها را برای نشانه‌های مشکوک بررسی کنید. 🔗 کانال وان سرور #هشدار_وان_سرور

گاهی GRE رو می‌سازی، اینترفیس هم UP ـه و دو سر تونل ظاهراً همه‌چیز مرتب به نظر می‌رسه؛ ولی ترافیک ازش رد نمی‌شه. اینجا معمولاً خود GRE آخرین متهمه، نه اولین نفر. 😄 برای عیب‌یابی سریع، این سه مورد رو به‌ترتیب چک کن: ۱) Route واقعاً از تونل رد می‌شه؟

ip route get 10.20.0.10

اگر خروجی مسیر یا اینترفیس دیگری را نشان داد، اول Route را درست کن. ۲) اگر قرار است سرور ترافیک را عبور دهد، Forwarding روشن است؟

sysctl net.ipv4.ip_forward

مقدار 1 یعنی فعال است. ۳) rp_filter بسته برگشتی را دور نمی‌اندازد؟

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.gre1.rp_filter

روی مسیرهای نامتقارن و بعضی سناریوهای Tunnel، Reverse Path Filtering می‌تواند بسته سالم را مشکوک تشخیص دهد و Drop کند. قبل از اینکه rp_filter را کورکورانه خاموش کنی، Route رفت و برگشت و Firewall را بررسی کن؛ چون خاموش‌کردنش بدون دلیل می‌تواند کنترل ضد spoofing را ضعیف کند. اگر GRE بالا بود ولی پکت رد نمی‌شد، ترتیب ذهنی خوب اینه: Route → Forwarding → Firewall → rp_filter. 🔗 کانال وان سرور #شبکه #GRE

اگر DNS رو هنوز فقط یک درخواست ساده روی پورت 53 می‌بینی، DoH یه لایه مهم به ماجرا اضافه می‌کنه. در MikroTik می‌تونی درخواست‌های DNS رو از داخل HTTPS عبور بدی تا مسیر بین روتر و Resolver رمزگذاری بشه؛ اما فقط گذاشتن آدرس DoH کافی نیست. نکته مهم مقاله امروز اینه که قبل از تغییر، از تنظیمات DNS بکاپ بگیری، CA/Certificate معتبر رو وارد کنی، use-doh-server رو درست ست کنی و verify-doh-cert رو روشن نگه داری. بعد هم با cache، resolve و لاگ‌ها مطمئن بشی واقعاً DoH کار می‌کنه. اگر Certificate یا زمان سیستم مشکل داشته باشه، اتصال می‌تونه بی‌سروصدا fail بشه. #آکادمی_وان_سرور