TKC

#network_time

‏🌐 چرا یه سرور شلوغ یهو نمی‌تونه connection جدید برقرار کنه؟

‏تا حالا شده یه سرور که ترافیکش زیاده، یهو با خطاهایی مواجه بشه که انگار دیگه نمی‌تونه به دیتابیس یا یه سرویس دیگه وصل بشه، در حالی که CPU و RAM کاملاً آزادن؟ این مشکل معمولاً به خاطر تموم شدن چیزی به اسم Ephemeral Ports اتفاق می‌افته؛ portهای موقتی که kernel برای هر اتصال خروجی به صورت خودکار انتخاب می‌کنه تا بتونه جواب‌های برگشتی رو به برنامه درست برسونه.

‏وقتی یه برنامه می‌خواد یه connection بسازه، kernel باید یه source port تعیین کنه تا یه 4-tuple منحصر‌به‌فرد (شامل Source IP, Source Port, Destination IP, Destination Port) ایجاد بشه. چون portهای پایین رزرو شده‌ان، kernel از یه بازه خاصی از portهای بالا استفاده می‌کنه که بهشون ephemeral port می‌گن. نکته اینجاست که هر socket برای شناسایی دقیق توی stack شبکه، نیاز به این ترکیب چهارگانه داره؛ پس اگه سرور بخواد هزاران اتصال همزمان به یه IP و port خاص (مثلاً دیتابیس) بزنه، به سرعت تمام portهای اون بازه تموم می‌شه.

‏این وضعیت باعث می‌شه پدیده Port Exhaustion رخ بده و kernel دیگه port آزاد برای باز کردن socket جدید نداشته باشه. این مشکل معمولاً با افزایش بازه portهای موقت یا فعال کردن قابلیت‌هایی مثل TCP reuse حل می‌شه تا سیستم بتونه از portهایی که هنوز توی حالت TIME_WAIT هستن دوباره استفاده کنه.

‏❓ به نظرتون برای جلوگیری از Port Exhaustion بهتره بازه portهای موقت رو زیاد کنیم یا روی تنظیمات TCP reuse متمرکز بشیم؟ دلیل انتخابتون رو تو کامنتا برامون بگین

@things_to_know_channel

#network_time

‏🧐 وقتی می‌دونیم IP طرف چیه، سیستم چطور می‌فهمه باید packet رو دقیقاً به کدوم کارت شبکه بفرسته؟

‏تا حالا شده فکر کنی وقتی می‌خوای یه packet رو توی شبکه محلی بفرستی، صرفاً داشتن IP طرف مقابل کافیه؟ در واقع IP فقط یه Logical Address هست و برای اینکه داده‌ها واقعاً روی سیم یا Wi-Fi جابجا بشن، سیستم باید بدونه MAC address اون دستگاه چیه. اینجاست که پروتکل ARP وارد بازی می‌شه تا این پل ارتباطی بین L3 و L2 رو بسازه.

‏وقتی kernel می‌خواد یه packet رو بفرسته و MAC مقصد رو نداره، یه ARP Request می‌فرسته که به صورت broadcast هست؛ یعنی به همه دستگاه‌های توی اون subnet اعلام می‌کنه که «هر کسی این IP رو داره، MAC address خودش رو به من بگه». تمام دستگاه‌ها این درخواست رو می‌بینن، اما فقط اون دستگاهی که IP مورد نظر با مالش یکی باشه، با یه ARP Reply جواب می‌ده و MAC خودش رو می‌فرسته. بعد از این، سیستم این mapping رو توی یه جدول موقتی به اسم ARP cache ذخیره می‌کنه تا برای packetهای بعدی مجبور نباشه دوباره کل شبکه رو صدا بزنه.

‏این مکانیزم باعث می‌شه ترافیک شبکه بیخودی اشغال نشه، اما چون ARP هیچ سیستم احراز هویتی نداره، به شدت در برابر حملاتی مثل ARP Spoofing حساسه. توی این حالت، یه مهاجم می‌تونه با فرستادن جواب‌های دروغین، ARP cache دستگاه‌های دیگه رو مسموم کنه و ترافیک رو به سمت خودش منحرف کنه.

‏❓ نظرتون راجب این پست چیه ؟ برامون تو کامنتا بنویسین :)

@things_to_know_channel

#linux_time

‏🤝 چطور میشه روی یه راز مشترک توافق کرد، وقتی همه دارن گوش می‌دن؟

‏تا حالا شده فکر کنی وقتی با یه سایت ارتباط امن برقرار می‌کنی، چطور طرفین روی یه key مشترک توافق می‌کنن بدون اینکه اون key رو مستقیم روی شبکه بفرستن؟ اینجاست که Diffie-Hellman key exchange وارد می‌شه؛ روشی که به دو نفر اجازه می‌ده روی یه راز مشترک توافق کنن، حتی اگه یه نفر وسط راه تمام پیام‌هاشون رو شنود کنه.

‏داستانش اینه که از ریاضیات ماژولار استفاده می‌شه. هر دو طرف روی یه عدد اول بزرگ و یه base عمومی توافق می‌کنن و بعد هر کدوم یه private key برای خودشون انتخاب می‌کنه. اونا خروجی یه توان‌رسانی خاص رو برای هم می‌فرستن که برای یه شنودکننده، پیدا کردن private key از روی اون خروجی (به دلیل سخت بودن Discrete Logarithm Problem) از نظر محاسباتی غیرممکنه. اما هر دو طرف می‌تونن با ترکیب اون مقدار دریافتی و private key خودشون، به یه مقدار نهایی یکسان برسن که همون shared secret می‌شه.

‏این مکانیزم پایه و اساس مفهومی به اسم Perfect Forward Secrecy هست. یعنی حتی اگه long-term keyهای سرور در آینده لو بره، sessionهای قبلی باز هم امن می‌مونن چون برای هر ارتباط یه key exchange موقت و جدید اتفاق افتاده. امروزه این روش توی پروتکل‌هایی مثل TLS و SSH برای امن کردن کانال ارتباطی استفاده می‌شه.

‏❓ نظرتون راجب این پست چیه ؟ برامون تو کامنتا بنویسین :)

@things_to_know_channel

#linux_time

‏💿 dd — کپی سطح پایین دیسک

‏در ادامه چند تا مثال کاربردی ازش میبینیم:

‏📌 تنظیم اندازه هر بلاک برای سرعت بیشتر

$ dd if=/dev/zero of=testfile bs=4M

‏📌 تعیین تعداد بلاک‌های کپی شده

$ dd if=/dev/zero of=testfile count=10

‏📌 نمایش پیشرفت عملیات در لحظه

$ dd if=/dev/sda of=/dev/sdb status=progress

‏📌 تضمین نوشتن کامل داده‌ها روی دیسک

$ dd if=image.iso of=/dev/sdX conv=fsync

‏❓ شما برای cloning دیسک‌ها هنوز از dd استفاده می‌کنید یا ابزارهای راحت‌تر رو ترجیح می‌دید؟ تو کامنتا برامون بگید چرا

@things_to_know_channel

#linux_time

‏🤝 دو تا سیستم چطور توافق می‌کنن که ترتیب packetها رو گم نکنن؟

‏تا حالا شده فکر کنی وقتی یه browser می‌خواد به یه سرور وصل شه، چطور اول با هم یه توافق می‌کنن تا دیتای رد و بدل شده قاطی نشه؟ این فرآیند شروع ارتباط توی TCP رو بهش می‌گن three-way handshake که یه جورایی مثل یه handshake رسمی بین دو تا سیستم برای شروع یه مکالمه‌ست.

‏داستان از اینجا شروع می‌شه که کلاینت یه packet با SYN flag می‌فرسته که توش یه عدد تصادفی به اسم ISN هست؛ این عدد در واقع نقطه شروع شماره‌گذاری بایت‌های ارسالیه. سرور در جواب یه SYN-ACK می‌فرسته که هم عدد کلاینت رو تایید می‌کنه و هم ISN تصادفی خودش رو می‌فرسته تا هر دو طرف بدونن بایت‌های بعدی از کجا شروع می‌شه. نکته مهم اینجاست که kernel این اعداد رو تصادفی انتخاب می‌کنه تا هم جلوی حملات sequence prediction گرفته بشه و هم اگه packetهای قدیمی از یه connection قبلی توی شبکه سرگردون بودن، با شماره‌های جدید قاطی نشن. در نهایت کلاینت با یه ACK آخرین تاییدیه رو می‌فرسته و هر دو طرف وارد حالت established می‌شن.

‏اگه این فرآیند درست انجام نشه یا مثلاً یه مهاجم کلی SYN بفرسته و جواب SYN-ACK رو نده، سرور توی حالت syn received می‌مونه و منابعش اشغال می‌شه که بهش می‌گن SYN flood. برای همین توی kernelهای مدرن مکانیزم‌هایی مثل SYN cookies وجود داره تا بدون رزرو کردن حافظه، این handshake رو مدیریت کنن.

‏❓ نظرتون راجب این پست چیه ؟ برامون تو کامنتا بنویسین :)

@things_to_know_channel

📌 systemctl Cheat Sheet

اگر با Linux Server و DevOps سر و کار دارید، systemctl یکی از دستورهایی است که احتمالاً هر روز با آن کار خواهید کرد. این چند دستور از پرکاربردترین موارد برای مدیریت سرویس‌ها هستند:

🔹 مشاهده وضعیت یک سرویس
systemctl status nginx

🔹 Start / Stop / Restart
systemctl start nginx
systemctl stop nginx
systemctl restart nginx

🔹 برای Reload تنظیمات بدون Restart کامل سرویس
systemctl reload nginx

🔹 فعال/غیرفعال کردن اجرای خودکار هنگام Boot
systemctl enable nginx
systemctl disable nginx

🔹 Enable و Start همزمان
systemctl enable --now nginx

🔹 لیست سرویس‌های در حال اجرا
systemctl list-units --type=service --state=running

🔹 لیست تمام Unitهای سرویس
systemctl list-units --type=service

🔹 مشاهده سرویس‌های Failed
systemctl --failed

🔹 بررسی اینکه یک سرویس در Boot فعال است یا نه
systemctl is-enabled nginx

🔹 بررسی اینکه سرویس در حال اجراست یا نه
systemctl is-active nginx

🔹 مشاهده Logهای یک سرویس
journalctl -u nginx

🔹 مشاهده Logهای سرویس به‌صورت Live
journalctl -u nginx -f

🔹 مشاهده Logهای Boot فعلی
journalctl -b

💡 نکته: systemctl فقط برای Start و Stop کردن سرویس‌ها نیست؛ در Troubleshooting سرورها، ترکیب systemctl status و journalctl معمولاً یکی از اولین جاهایی است که باید سراغش برویم.

کدام دستور systemctl بیشتر از همه در کار روزمره‌تان استفاده می‌شود؟

وقتی یک سرور لینوکسی را Boot می‌کنیم، اولین Process سیستم چیست و چه کسی مسئول زنده نگه داشتن سرویس‌هاست؟

در لینوکس، Process با PID 1 نقش ویژه‌ای دارد. این Process بعد از Kernel اجرا می‌شود و مسئولیت‌هایی مثل راه‌اندازی User Space، مدیریت برخی Processهای orphan شده و واکنش به وضعیت سرویس‌های سیستم را بر عهده دارد. در سیستم‌های قدیمی‌تر، این نقش معمولاً توسط init و پیاده‌سازی‌هایی مثل SysVinit انجام می‌شد.

در SysVinit، سرویس‌ها عمدتاً با اسکریپت‌های موجود در مسیرهایی مثل /etc/init.d/ مدیریت می‌شدند و ترتیب اجرای آن‌ها با Runlevelها و لینک‌های مختلف مشخص می‌شد. این مدل ساده و قابل فهم بود، اما با بزرگ‌تر شدن سیستم‌ها، مدیریت dependencyها، اجرای موازی سرویس‌ها و تشخیص وضعیت واقعی سرویس‌ها می‌توانست پیچیده شود.

اینجاست که systemd وارد می‌شود. systemd علاوه بر اینکه PID 1 است، یک سیستم مدیریت سرویس و dependency هم ارائه می‌کند. سرویس‌ها در قالب Unit تعریف می‌شوند؛ مثلاً یک فایل nginx.service می‌تواند مشخص کند سرویس چگونه اجرا شود، به چه سرویس‌هایی وابسته باشد، در صورت Crash چه اتفاقی بیفتد و چه زمانی Start شود. ابزارهایی مثل systemctl و journalctl هم مدیریت سرویس و بررسی Logها را ساده‌تر می‌کنند.

برای یک DevOps، تفاوت فقط در دستور systemctl به‌جای service خلاصه نمی‌شود. مفاهیمی مثل dependency graph، socket activation، service supervision، restart policy، targetها و journald باعث می‌شوند systemd عملاً بخشی از معماری Runtime یک Linux Server باشد. به همین دلیل وقتی یک سرویس روی سرور بالا نمی‌آید، فهمیدن اینکه PID 1 چه نقشی دارد و systemd دقیقاً چه تصمیمی گرفته، می‌تواند بخش مهمی از فرآیند Troubleshooting باشد.

حالا سؤال جالب این است: اگر قرار بود امروز یک سیستم‌عامل Unix/Linux جدید طراحی کنید، برای PID 1 همچنان یک init ساده انتخاب می‌کردید یا چیزی شبیه systemd؟

@things_to_know_channel

#linux_time

‏🌐 چرا بعضی وقتا ارسال پیام‌های کوتاه توی شبکه یه لگ عجیب داره؟

‏تا حالا شده توی یه برنامه یا بازی، وقتی پیام‌های خیلی کوتاهی می‌فرستی، حس کنی یه تأخیر یا لگ غیرمنطقی وجود داره، انگار سیستم منتظره یه چیزی اتفاق بیفته تا داده‌ها رو بفرسته؟ این اتفاق معمولاً به خاطر یه مکانیزم به اسم Nagle's Algorithm اتفاق می‌افته که هدفش اینه که از ارسال تعداد زیادی packetهای ریز با payload کم جلوگیری کنه تا ترافیک شبکه بیهوده اشغال نشه.

‏داستان از اینجا شروع می‌شه که Nagle's Algorithm می‌گه تا وقتی که ACK مربوط به packet قبلی برنگشته، اجازه نداره packet جدیدی با اندازه کوچکتر از MSS بفرسته. اما از اون طرف، سیستم‌های مدرن از Delayed ACK استفاده می‌کنن؛ یعنی گیرنده بلافاصله ACK نمی‌فرسته و یه مدت کوتاه منتظر می‌مونه تا شاید بتونه ACK رو روی یه payload پاسخ قرار بده یا منتظر می‌مونه تا packetهای بیشتری برسن. حالا اگه فرستنده طبق قانون Nagle منتظر ACK باشه و گیرنده طبق Delayed ACK منتظر داده‌های بیشتر، یه بن‌بست موقت ایجاد می‌شه و هر دو طرف تا زمان انقضای timer منتظر می‌مونن، که باعث یه جهش شدید توی latency می‌شه.

‏برای حل این مشکل، توی اکثر برنامه‌هایی که به پاسخ سریع نیاز دارن مثل SSH یا بازی‌های آنلاین، گزینه‌ای برای غیرفعال کردن Nagle's Algorithm وجود داره تا داده‌ها بدون معطلی ارسال بشن. با این کار، هر مقدار داده‌ای که توی buffer باشه بلافاصله ارسال می‌شه و دیگه منتظر ACK نمی‌مونه، هرچند که این کار ممکنه باعث افزایش تعداد packetهای ریز توی شبکه بشه.

‏❓ نظرتون راجب این پست چیه ؟ برامون تو کامنتا بنویسین :)

@things_to_know_channel

#network_time

‏🤔 اگه چند تا مسیر مختلف به یه IP اشاره کنن، سیستم کدوم رو انتخاب می‌کنه؟

‏تا حالا شده توی routing table کلی مسیر مختلف ببینی که انگار با هم تداخل دارن و همگی یه محدوده از IPها رو پوشش می‌دن؟ اینجاست که بحث Longest Prefix Match مطرح می‌شه؛ مکانیزمی که kernel ازش استفاده می‌کنه تا وقتی یه packet می‌خواد بره به یه مقصد مشخص، دقیق‌ترین مسیر رو بین اون همه گزینه پیدا کنه.

‏ماجرا از این قراره که وقتی یه packet به دستگاه می‌رسه، kernel نگاه می‌کنه ببینه مقصد با کدوم ردیف از routing table مطابقت داره. مشکل اینجاست که ممکنه یه IP همزمان توی چند تا subnet مختلف قرار بگیره؛ مثلاً یه مسیر رو برای یه محدوده بزرگ مثل /16 تعریف کرده باشیم و یه مسیر دیگه هم برای یه محدوده کوچیک‌تر و دقیق‌تر مثل /24. kernel برای حل این تداخل، بیت‌هایی که توی اولِ آدرس IP مقصد با mask اون مسیر مشترک هستن رو می‌شماره؛ هر مسیری که تعداد بیت‌های مشترک بیشتری داشته باشه، یعنی mask طولانی‌تر یا دقیق‌تر، برنده می‌شه و به عنوان next hop انتخاب می‌شه.

‏این دقیقاً همون دلیلیه که می‌تونیم توی شبکه، مسیرهای عمومی مثل default gateway رو با مسیرهای خیلی خاص‌تر و اختصاصی‌تر جایگزین کنیم. بدون این قانون، مدیریت routing table توی شبکه‌های بزرگ که پر از subnetهای مختلف هستن، عملاً غیرممکن می‌شد چون سیستم نمی‌تونست بفهمه کدوم مسیر واقعاً به مقصد نزدیک‌تره.

‏❓ تا حالا شده یه تنظیم اشتباه توی subnet یا mask باعث بشه traffic از یه مسیر غیرمنتظره رد بشه؟ تجربه‌تون رو برامون تو کامنتا بنویسین

@things_to_know_channel

#network_time

‏🤔 فایروال‌ها چطوری می‌فهمن یه packet باید اجازه عبور داشته باشه یا نه؟

‏تا حالا شده فکر کنی وقتی یه فایروال یا ابزار NAT روی یه لینوکس اجرا می‌شه، چطوری می‌تونه وسط مسیر یه packet رو بگیره، تغییرش بده یا اصلاً جلوی رفتنش رو بگیره؟ این کار از طریق مکانیزمی توی kernel به اسم Netfilter hooks انجام می‌شه که در واقع نقاط حساس و مشخصی توی مسیر حرکت یه packet هستن.

‏وقتی یه packet از کارت شبکه وارد سیستم می‌شه، kernel اون رو پردازش می‌کنه، اما در مراحل مختلف، مثل لحظه‌ای که تازه وارد شده یا درست قبل از اینکه از سیستم خارج بشه، این مکانیزم اجازه می‌ده که ما یه rule خاص رو اونجا اجرا کنیم. این ۵ تا نقطه اصلی شامل مرحله‌ی prerouting برای تغییر آدرس قبل از routing، مرحله‌ی input برای packetهایی که مستقیم به خود سیستم می‌رسن، مرحله‌ی forward برای packetهایی که فقط دارن از سیستم عبور می‌کنن، مرحله‌ی output برای packetهایی که خود سیستم تولید کرده، و مرحله‌ی postrouting برای اعمال تغییراتی مثل NAT دقیقاً قبل از خروج از interface هستن. در واقع در هر کدوم از این hookها، kernel مسیر پردازش رو موقتاً متوقف می‌کنه تا ببینه آیا باید اون packet رو drop کنه یا اجازه بده به مرحله بعد بره.

‏این ساختار دقیق همون چیزیه که ابزارهای مدیریت فایروال ازش استفاده می‌کنن تا بتونن کنترل کاملی روی ترافیک داشته باشن. بدون این hookها، نوشتن یه فایروال یا سیستم NAT خیلی سخت می‌شد چون دیگه نمی‌تونستیم بدون دستکاری خودِ kernel، دقیقاً مشخص کنیم که در چه مرحله‌ای از پردازش IP، چه تغییری باید روی header یا مقصد packet اعمال بشه.

‏❓ تا حالا شده موقع تنظیم فایروال با مشکلی برخورد کنین که نتونین بفهمین packet دقیقاً توی کدوم مرحله از این hooks drop شده؟ تجربه‌تون رو برامون تو کامنتا بنویسین.

@things_to_know_channel

#network_time

‏🚀 چطور ترافیک بالا CPU رو از پا در نمی‌آره؟

‏تا حالا شده فکر کنی وقتی یه فایل خیلی حجیم رو توی شبکه می‌فرستی، CPU باید تک‌تک اون packetهای ریز رو آماده کنه و Headerهاشون رو بسازه؟ اگه این‌طوری بود، با بالا رفتن سرعت شبکه، مصرف CPU به شدت بالا می‌رفت. برای حل این مشکل از مکانیزم‌های offload مثل TSO، GSO و GRO استفاده می‌کنیم که وظیفه segmentation رو از دوش CPU برمی‌دارن.

‏نکته اصلی اینجاست که در حالت عادی، kernel باید یه payload بزرگ رو بر اساس MTU به قطعات کوچیک‌تر تقسیم کنه و برای هر کدوم checksum و header جداگانه محاسبه کنه. اما با TSO، kernel یه packet خیلی بزرگ رو با یه Header اولیه به NIC می‌سپره و خودِ سخت‌افزار کارت شبکه وظیفه داره اون رو به segmentهای کوچیک‌تر تقسیم کنه و Headerهای جدید رو اضافه کنه. اگه کارت شبکه از این قابلیت پشتیبانی نکنه، GSO توی خودِ kernel این کار رو با کمترین هزینه انجام می‌ده تا تقسیم‌بندی رو تا آخرین لحظه عقب بندازه. از اون طرف، وقتی داده‌ها می‌رسن، GRO برعکس عمل می‌کنه؛ یعنی چند تا packet کوچیک که مال یه flow هستن رو با هم ترکیب می‌کنه تا kernel مجبور نباشه برای هر کدوم جداگانه پردازش انجام بده.

‏نتیجه‌ش اینه که تعداد interruptهایی که به CPU می‌رسه خیلی کم می‌شه و پردازش network stack خیلی سریع‌تر انجام می‌شه. اگه بخوای وضعیت این قابلیت‌ها رو بررسی کنی، می‌تونی از ابزارهای مربوط به تنظیمات کارت شبکه استفاده کنی، چون توی سرورهای پرسرعت، مدیریت درست این offloadها برای حفظ performance خیلی حیاتیه.

‏❓ تا حالا شده با فعال بودن این offloadها توی شبکه به مشکل بخورین یا مثلا با غیرفعال کردنشون عملکرد سیستم رو بهتر کنین؟ تجربه‌تون رو برامون تو کامنتا بنویسین

@things_to_know_channel

#network_time

‏🕵️ وقتی یه packet وسط راه گم می‌شه، شبکه چطور خبر می‌ده؟

‏تا حالا شده فکر کنی اگه یه packet توی مسیر به بن‌بست بخوره یا به خاطر سایز زیادش از یه مسیر رد نشه، دیگه کلاً غیب می‌شه؟ واقعیت اینه که شبکه یه راه برای گزارش دادن این اتفاق‌ها داره و اون پروتکل ICMP هست که خیلی فراتر از اون ping ساده‌ای که همه‌مون می‌شناسیم عمل می‌کنه.

‏اصل کاری اینجاست که وقتی یه router نمی‌تونه packet رو به مقصد برسونه یا با یه محدودیت برخورد می‌کنه، یه ICMP error message تولید می‌کنه و به فرستنده برمی‌گردونه. مثلاً اگه سایز یه packet از MTU اون لینک بیشتر باشه و DF flag توی IP header ست شده باشه، router packet رو drop می‌کنه و یه Fragmentation Needed message همراه با مقدار MTU جدید می‌فرسته تا فرستنده بدونه باید packetها رو کوچیک‌تر کنه. یا اگه TTL packet به صفر برسه، یعنی packet توی یه loop گیر افتاده و router اون رو drop می‌کنه و یه Time Exceeded message می‌فرسته تا جلوی سرگردونی ابدی packetها رو بگیره.

‏این پیام‌های کنترلی باعث می‌شن فرآیندهایی مثل Path MTU Discovery درست کار کنن و از قطعه‌قطعه شدن بیهوده packetها جلوگیری بشه. حتی ابزاری مثل traceroute هم دقیقاً با تکیه بر همین پیام‌های Time Exceeded کار می‌کنه تا بفهمه packetها از چه مسیرهایی رد می‌شن.

‏❓ به نظرتون برای امنیت بیشتر، بهتره ICMP رو کلاً بلاک کنیم یا اجازه بدیم پیام‌های خطا برای پایداری شبکه کار کنن؟ تجربه‌تون رو برامون تو کامنتا بنویسین

@things_to_know_channel

ادامه توضیحات در پست بعد

@things_to_know_channel

#network_time

‏🔌 چطور می‌شه با یه کابل، ترافیک چند تا شبکه رو از هم جدا کرد؟

‏تا حالا شده فکر کنی چطور می‌شه با یه کابل فیزیکی بین دو تا switch، ترافیک چند تا شبکه کاملاً متفاوت رو از هم جدا نگه داشت، اونم بدون اینکه امنیتشون به خطر بیفته؟ این کار با استفاده از یه مکانیزم به اسم VLAN tagging یا همون استاندارد 802.1Q انجام می‌شه که به ما اجازه می‌ده چندین شبکه مجازی رو روی یه link فیزیکی واحد راه بندازیم.

‏اصل داستان اینجاست که وقتی یه frame قرار هست از یه link Trunk رد بشه، switch اون رو همین‌طوری خام نمی‌فرسته. در واقع، اون یه tag چهار بایتی رو دقیقاً بعد از Source MAC توی header اون Ethernet frame تزریق می‌کنه. داخل این tag، یه فیلد ۱۲ بیتی به اسم VLAN ID وجود داره که مشخص می‌کنه این packet متعلق به کدوم شبکه مجازی هست. وقتی این frame به مقصد می‌رسه و می‌خواد وارد یه access port بشه، switch اون tag رو حذف می‌کنه و frame رو به صورت معمولی به دستگاه مقصد تحویل می‌ده، یعنی اون host اصلاً متوجه نمی‌شه که packet-ash یه بار tag شده بوده.

‏چون این tag چهار بایتی به حجم header اضافه می‌کنه، اندازه کل frame هم کمی بیشتر می‌شه؛ به همین دلیل توی تنظیمات MTU باید دقت کرد تا با مشکل fragmentation یا drop شدن packetها مواجه نشیم. همین مکانیزم پایه و اساس Trunking هست و به ما اجازه می‌ده توی دیتاسنترهای بزرگ، با کمترین تجهیزات فیزیکی، شبکه‌های خیلی پیچیده و مقیاس‌پذیر بسازیم.

‏❓ اگه بخواین امنیت رو به بالاترین سطح ممکن برسونین، ترجیح میدین به VLAN اعتماد کنین یا ترجیح میدین شبکه‌ها رو با کابل‌کشی فیزیکی از هم جدا کنین؟ تجربه‌تون رو برامون تو کامنتا بنویسین

@things_to_know_channel

ماجرای جنجالی OpenAI و معادلات ناویر–استوکس چیست؟

شرکت OpenAI اخیراً اعلام کرده که مدل جدیدش توانسته برای مسئله‌ی بسیار قدیمی و حل‌نشده‌ی Navier–Stokes یک راه‌حل پیدا کند؛ مسئله‌ای که یکی از مسائل هزاره‌ی مؤسسه Clay و دارای جایزه‌ی یک میلیون دلاری است.

اصلاً Navier–Stokes چیست؟
معادلات ناویر–استوکس مجموعه‌ای از معادلات ریاضی هستند که حرکت سیالاتی مثل آب و هوا را توصیف می‌کنند؛ از جریان هوا دور یک هواپیما گرفته تا حرکت آب در لوله و شکل‌گیری گردبادها. خود معادلات سال‌هاست شناخته شده‌اند، اما یک سؤال بنیادی هنوز حل نشده: آیا در سه بُعد، برای شرایط اولیه‌ی مناسب، همیشه یک جواب «خوب و قابل‌کنترل» برای این معادلات وجود دارد، یا ممکن است جواب در نقطه‌ای به بی‌نهایت برسد و اصطلاحاً یک singularity ایجاد شود؟ حل این مسئله مهم است چون به یکی از پایه‌ای‌ترین پرسش‌ها درباره‌ی رفتار ریاضی سیالات مربوط می‌شود و می‌تواند درک عمیق‌تری از پدیده‌های فیزیکی مانند آشفتگی (turbulence) به ما بدهد.

اما ماجرا فقط یک دستاورد علمی نیست. بحث اصلی اینجاست که برخی ریاضی‌دان‌ها می‌گویند OpenAI در جریان این کار ممکن است از پژوهش‌های منتشرنشده‌ی محققان دیگر، از جمله کارهای مرتبط با Tristan Buckmaster، اطلاع داشته باشد و مسئله‌ی «حق تقدم» و اعتبار علمی را مطرح کرده‌اند. OpenAI هم گفته بررسی کرده و نمی‌تواند استفاده‌ی ناخواسته از برخی اطلاعات را کاملاً رد کند.
از طرف دیگر، OpenAI ادعا می‌کند مدل جدیدش در مقیاس بسیار بزرگی کار کرده؛ حدود ۱۰ هزار agent برای این مسئله به کار گرفته شده‌اند و هزینه‌ی محاسباتی آن حدود ۱۵ میلیون دلار برآورد شده است.
بنابراین اتفاق مهم فعلاً این نیست که «AI رسماً یکی از بزرگ‌ترین مسائل ریاضی را حل کرده». هنوز باید نتیجه توسط ریاضی‌دان‌ها بررسی و تأیید شود.
اتفاق مهم‌تر این است که مدل‌های جدید AI دارند از حل مسائل معمولی فراتر می‌روند و به سمت انجام پژوهش‌های پیچیده و چندمرحله‌ای علمی حرکت می‌کنند؛ و همین موضوع بحث جدی درباره‌ی اعتبار علمی، مالکیت فکری و نقش انسان در پژوهش را به وجود آورده است.

@things_to_know_channel

#network_time

‏🔌 چطور می‌شه چند تا کابل رو طوری با هم ترکیب کرد که مثل یه کابل واحد کار کنن؟

‏تا حالا شده بخوای پهنای باند یه لینک رو بیشتر کنی و به جای یه کابل، چند تا کابل رو به یه سوییچ و سرور وصل کنی، ولی ببینی سیستم هنوز همه‌چیز رو یه مسیر واحد می‌بینه؟ این دقیقاً همون کاریه که Link Aggregation یا اگه از پروتکل استاندارد LACP استفاده کنی، انجامش می‌ده؛ یعنی چند تا interface فیزیکی رو با هم ترکیب می‌کنی تا یه interface منطقی واحد با پهنای باند بالاتر داشته باشی.

‏حالا سوال اصلی اینه که وقتی یه packet می‌رسه، سیستم از کدوم کابل باید ردش کنه؟ اگه کابل‌ها رو خیلی ساده و پشت سر هم یا همون Round-robin استفاده کنیم، ممکنه یه سری packetهای مربوط به یه flow خاص، با تاخیرهای متفاوت از مسیرهای مختلف بیان و باعث بشه ترتیب رسیدن پکت‌ها بهم بخوره که این برای TCP فاجعه‌ست. برای همین، kernel یا سوییچ از یه مکانیزم به اسم Hashing استفاده می‌کنن. این مکانیزم بر اساس اطلاعاتی مثل Source MAC، Destination MAC، یا حتی IP و portها، یه مقدار عددی تولید می‌کنه که اون عدد تعیین می‌کنه packet باید از کدوم لینک عبور کنه. چون برای یه flow مشخص، تمام پارامترهای header ثابت می‌مونن، خروجی hash هم همیشه یکیه و در نتیجه تمام packetهای مربوط به اون اتصال حتماً از یه مسیر مشخص رد می‌شن تا ترتیبشون حفظ بشه.

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

‏❓ شما توی پروژه‌های واقعی، ترجیح می‌دین چند تا لینک رو با LACP ترکیب کنین یا اینکه کلاً برید سراغ یه لینک با پهنای باند خیلی بالاتر؟ تجربیات یا دیدگاهتون رو برامون تو کامنتا بنویسین

@things_to_know_channel

اجرای مدل‌های زبانی روی سیستم خودت، با دستورهایی که از قبل بلدی!

برای اجرای مدل زبانی روی لوکال معمولاً کار می‌رسه به نصب یه ابزار جدا، محیط پایتون، درایور GPU و یه سرویسی که با بقیه‌ی استکت جور درنمیاد. اگر Docker داری، لازم نیست از این فضا بیای بیرون.

ابزار Docker Model Runner مدل رو مثل ایمیج مدیریت می‌کنه: از Docker Hub یا Hugging Face می‌کشی، با docker model اجرا می‌کنی، و روی خودِ ماشین یه API سازگار با OpenAI بالا میاد. پرامپت و پاسخ روی سیستم خودت می‌مونه.

چرا به‌درد می‌خوره؟

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

اگر اپلیکیشن الان با OpenAI SDK حرف می‌زنه، غالباً فقط base_url عوض می‌شه. تو Compose هم می‌شه مدل رو کنار سرویس تعریف کرد تا آدرس به کانتینر تزریق بشه؛ یعنی مدل بخشی از همون فایل است، نه یه باکس جدا روی میز.

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

شروع کوتاه

روی Docker Desktop برو Settings، تب AI، گزینه‌ی Enable Docker Model Runner. اگر از روی خودِ ماشین (نه از داخل کانتینر) می‌خوای با curl یا SDK صداش بزنی، باید TCP روی پورت ۱۲۴۳۴ رو هم باز کنی، روی Docker Engine این پورت پیش‌فرض باز است؛ فقط پلاگین رو نصب کن:

# Debian / Ubuntu
sudo apt-get install docker-model-plugin

# Fedora / RHEL
sudo dnf install docker-model-plugin

بعد یه مدل کوچک pull کن و همون‌جا چت کن:

docker model pull ai/smollm2
docker model run ai/smollm2

از روی هاست همون API:

curl http://localhost:12434/engines/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"ai/smollm2","messages":[{"role":"user","content":"سلام، در یک جمله بگو Docker چیست؟"}]}'

با SDK پایتون تقریباً همیون چیزی هست که عادت داریم. فقط کلید رو خالی یا ساختگی بذار؛ این سرویس بهش نگاه نمی‌کنه:

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:12434/engines/v1",
    api_key="not-needed",
)
r = client.chat.completions.create(
    model="ai/smollm2",
    messages=[{"role": "user", "content": "سلام"}],
)
print(r.choices[0].message.content)

تذکر مهم

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

روی مک فعلاً Apple Silicon، روی ویندوز برای شتاب GPU معمولاً انویدیا، روی لینوکس خودِ Docker Engine. مدل بزرگ بدون RAM کافی یا کند می‌شه یا اصلاً لود نمی‌شه. موتور پیش‌فرض llama.cpp است و برای کار روزمره کافی است؛ vLLM مسیر جداگانه‌ای است برای لینوکس با GPU انویدیا و ترافیک بالاتر.

مستندات رسمی:

شروع کار
https://docs.docker.com/ai/model-runner/get-started/

مرجع API
https://docs.docker.com/ai/model-runner/api-reference/


@things_to_know_channel

#network_time

‏🛡️ سیستم از کجا می‌فهمه یه IP جعلی اومده؟

‏تا حالا شده فکر کنی چطور ممکنه یه هکر بتونه IP خودش رو جعل کنه تا خودشو جای یه کاربر معتبر جا بزنه؟ برای جلوگیری از این اتفاق، یه مکانیزم امنیتی توی kernel لینوکس وجود داره به اسم reverse path filtering یا همون rp_filter که وظیفه‌اش شناسایی و حذف packetهایی هست که از آدرس‌های جعلی یا غیرمجاز می‌خوان بیان.

‏داستان از این قراره که وقتی یه packet به یه interface می‌رسه، kernel فقط به header اون اکتفا نمی‌کنه و یه بررسی دقیق انجام می‌ده. سیستم به routing table نگاه می‌کنه تا ببینه اگه بخواد یه پاسخ به اون IP مبدأ بفرسته، آیا از همون interface‌ای که packet از اونجا اومده استفاده می‌کنه یا نه. اگه مسیر برگشت از یه interface دیگه باشه، سیستم فرض می‌کنه که این یه IP spoofing هست و اون packet رو drop می‌کنه تا امنیت شبکه حفظ بشه.

‏البته یه نکته مهم هم هست: اگه توی شبکه routing تو asymmetric باشه، یعنی مسیر رفت و برگشت متفاوت باشه، این مکانیزم ممکنه packetهای کاملاً سالم رو هم به اشتباه حذف کنه. به همین خاطر، بسته به نیاز، می‌شه تنظیم کرد که kernel فقط چک کنه آیا اون IP اصلاً توی routing table وجود داره یا نه، بدون اینکه لزوماً مسیر برگشت دقیقاً از همون interface بیاد.

‏❓ تا حالا شده با مشکل drop شدن packetها روبرو شدین که مسیر routing درست بوده ولی مقصر اصلیش rp_filter بوده؟ تجربه‌تون رو برامون تو کامنتا بنویسین

@things_to_know_channel

#linux_time
#security_time

🔥 فایروال لینوکس — قسمت ۳/۳
رسیدیم به firewalld.
اگر با:
Rocky Linux
RHEL
Fedora
CentOS
کار کرده باشی، احتمالاً firewalld را زیاد دیده‌ای.
اینجا هم مستقیم می‌ریم سراغ دستورها 👇
━━━━━━━━━━━━━━━━━━
🔥 وضعیت Firewall:

sudo firewall-cmd --state

🔎 Zoneهای فعال:

sudo firewall-cmd --get-active-zones

🔎 Zone پیش‌فرض:

sudo firewall-cmd --get-default-zone

🔎 همه تنظیمات Zone:

sudo firewall-cmd --list-all

━━━━━━━━━━━━━━━━━━
🟢 فعال کردن:

sudo systemctl enable --now firewalld

🔴 متوقف کردن:

sudo systemctl disable --now firewalld

━━━━━━━━━━━━━━━━━━
➕ باز کردن پورت:

sudo firewall-cmd \
  --add-port=80/tcp \
  --permanent

بعد:

sudo firewall-cmd --reload

➕ باز کردن SSH:

sudo firewall-cmd \
  --add-service=ssh \
  --permanent

sudo firewall-cmd --reload

🔎 سرویس‌های موجود:

sudo firewall-cmd --get-services

━━━━━━━━━━━━━━━━━━
❌ حذف پورت:

sudo firewall-cmd \
  --remove-port=80/tcp \
  --permanent

sudo firewall-cmd --reload

❌ حذف Service:

sudo firewall-cmd \
  --remove-service=http \
  --permanent

━━━━━━━━━━━━━━━━━━
🔎 دیدن Ruleهای فعلی:

sudo firewall-cmd --list-all

🔎 دیدن پورت‌ها:

sudo firewall-cmd --list-ports

🔎 دیدن Serviceها:

sudo firewall-cmd --list-services

━━━━━━━━━━━━━━━━━━
🔥 حالا قسمت جذاب:
RICH RULE
فرض کنیم Node Exporter روی پورت 9100 اجرا شده.
می‌خواهیم فقط Prometheus با IP زیر بتواند به آن دسترسی داشته باشد:

172.25.3.56

Rule:

sudo firewall-cmd --permanent \
  --add-rich-rule='rule family="ipv4" \
  source address="172.25.3.56" \
  port port="9100" protocol="tcp" accept'

بعد:

sudo firewall-cmd --reload

🔎 بررسی:

sudo firewall-cmd --list-rich-rules

━━━━━━━━━━━━━━━━━━
❌ حالا می‌توانیم سایر دسترسی‌ها را Drop کنیم:

sudo firewall-cmd --permanent \
  --add-rich-rule='rule family="ipv4" \
  port port="9100" protocol="tcp" drop'

sudo firewall-cmd --reload

یعنی:

172.25.3.56 ───────► :9100 ✅

Other IPs ─────────► :9100 ❌

━━━━━━━━━━━━━━━━━━
❌ حذف Rich Rule:
اول Ruleها را ببین:

sudo firewall-cmd --list-rich-rules

بعد همان Rule را با --remove-rich-rule حذف کن:

sudo firewall-cmd --permanent \
  --remove-rich-rule='rule family="ipv4" \
  source address="172.25.3.56" \
  port port="9100" protocol="tcp" accept'

و:

sudo firewall-cmd --reload

━━━━━━━━━━━━━━━━━━
🧠 جمع‌بندی:
Ubuntu / Debian:

UFW
 ↓
iptables / nftables

Rocky / RHEL / Fedora:

firewalld
 ↓
nftables

و برای کنترل مستقیم‌تر:

nftables

و برای یادگیری و کار با سیستم‌های قدیمی‌تر:

iptables

📌 قانون طلایی:
❌ همزمان UFW و firewalld را مدیریت نکن.
❌ روی یک سرور، بدون اینکه دقیقاً بدانی چه اتفاقی می‌افتد، Ruleهای دستی iptables را با UFW/firewalld قاطی نکن.
🔥 Firewall خوب یعنی:
«فقط چیزی که لازم است باز باشد.»
نه اینکه:
«همه‌چیز را باز کنیم و امیدوار باشیم کسی پیدایش نکند.»

@things_to_know_channel

Linux Firewall Cheat Sheet

@things_to_know_channel