شبکه به زبان ساده!
Photo
نسخه جدید هسته متن‌باز و رایگان Aether منتشر شده و این بار قابلیت‌های Tor هم بهش اضافه شده. یعنی الان می‌تونین از Tor به چند حالت مختلف استفاده کنین؛ اتصال مستقیم به Tor، اتصال Tor از طریق WARP و حتی حالت معکوس. جالب‌تر اینکه Bridgeهای Tor هم می‌تونن به‌صورت خودکار از BridgeDB دریافت بشن و Aether امکان امتحان کردن Bridgeهایی مثل Snowflake و WebTunnel رو هم داره. یه قابلیت دیگه‌ای که اضافه شده MASQUE-in-MASQUE هست؛ یعنی به‌جای اینکه فقط یه لایه MASQUE داشته باشین، دو لایه MASQUE پشت سر هم برقرار میشه. این کار میتونه باعث بشه مسیر و رنج IP خروجی با حالت MASQUE معمولی متفاوت باشه و طبق توضیحات پروژه، در این حالت دیگه خروجی الزاماً از رنج IP ایران Cloudflare نمیاد و رفتار اتصال تا حدی شبیه متد Gool میشه. خلاصه Aether توی این نسخه یه قدم جدی‌تر رفته سمت ترکیب روش‌های مختلف تونل و مسیریابی برای شرایطی که اتصال معمولی جواب نمیده.
👉 github.com/CluvexStudio/Aether/releases
@ModernLan
👉 github.com/CluvexStudio/Aether/releases
@ModernLan
🔥6
شبکه به زبان ساده!
Photo
چین و مهندسی فیلترینگ در ایران؛ از DPI تا اختلال سیستماتیک اینترنت!
اگر بخوایم خیلی عمیق ولی فنی به قضیه نگاه کنیم، چین برای جمهوری اسلامی فقط «تجهیزات شبکه» نفروخته؛ چیزی که اهمیت بیشتری داره اینه که بخشی از تجربه و فناوری کنترل متمرکز اینترنت رو هم منتقل کرده. یعنی ایده این نیست که اینترنت رو کلاً خاموش کنن؛ مدل پیشرفته‌تر اینه که اینترنت وجود داشته باشه، ولی مسیر عبورش، مقصدش، سرعتش و حتی اینکه چه کسی به چه سرویسی دسترسی داشته باشه، قابل کنترل باشه.
یکی از قطعات مهم این داستان DPI یا Deep Packet Inspection ـه. DPI رو می‌تونی مثل یه سیستم بازرسی خیلی پیشرفته در مسیر ترافیک تصور کنی. وقتی ترافیک کاربر از شبکه ISP یا اپراتور رد میشه، تجهیزات می‌تونن مشخصات جریان ارتباطی رو بررسی کنن؛ مثلاً IP مقصد، پورت، پروتکل، مشخصات TLS و در بعضی شرایط اطلاعات قابل مشاهده داخل ترافیک. بعد بر اساس Policy تصمیم گرفته میشه که این ارتباط عبور کنه، Drop بشه، Reset بشه یا سرعتش محدود بشه. گزارش‌های منتشرشده درباره ایران، فناوری DPI ارائه‌شده یا مرتبط با شرکت‌هایی مثل Huawei و ZTE رو یکی از اجزای مهم این معماری معرفی می‌کنن.
حالا قسمت مهم‌تر ماجرا اینه که فیلترینگ فقط «بلاک کردن یه IP» نیست. فرض کن کاربر می‌خواد به یک سرویس خارجی وصل بشه. درخواست DNS میره، آدرس IP گرفته میشه، بعد ارتباط TCP یا UDP برقرار میشه و در HTTPS هم TLS Handshake اتفاق میفته. سیستم کنترل شبکه میتونه در چند نقطه مختلف روی این زنجیره دخالت کنه. حتی وقتی محتوای اصلی HTTPS رمزنگاری شده، بعضی Metadataها و مشخصات ارتباط، مثل SNI در TLS، در معماری‌های خاص می‌تونن برای اعمال Policy استفاده بشن. مطالعات فنی منتشرشده درباره فیلترینگ ایران، دخالت در DNS، HTTP، SNI در HTTPS و حتی ترافیک UDP/QUIC رو گزارش کرده‌اند.
یعنی ممکنه تو مرورگرت ببینی اینترنت «وصله»، ولی یک سایت خاص باز نمیشه؛ بعد فکر کنی مشکل DNS یا اینترنت خودته. در حالی که ممکنه اتصال عمداً در یکی از مراحل ارتباط قطع شده باشه. حتی میشه کاری کرد که ارتباط TCP شروع بشه ولی قبل از کامل شدن Session، اتصال با Packetهای Reset مختل بشه. نتیجه برای کاربر ساده است: «اینترنت خرابه»، ولی از دید شبکه یک Policy عمداً اجرا شده.
یه مرحله بالاتر، بحث Throttling یا کاهش عمدی کیفیت ارتباطه. لازم نیست همیشه سرویس رو کامل Block کنی. میشه با ایجاد Packet Loss، افزایش Latency، محدود کردن Bandwidth یا دستکاری مسیر، کیفیت سرویس رو آن‌قدر پایین آورد که عملاً استفاده ازش سخت یا غیرممکن بشه. این مدل از نظر فنی خیلی متفاوت از قطع کامل اینترنت به نظر میاد، ولی نتیجه برای کاربر میتونه تقریباً همون باشه: سرویس باز میشه اما ویدیو لود نمیشه، VPN ناپایدار میشه، تماس تصویری قطع میشه یا اتصال مرتب Timeout میخوره.
حالا می‌رسیم به قسمت خیلی مهم‌تر یعنی «اختلال سیستماتیک». وقتی کنترل فقط روی یک فایروال کوچک نیست و در لایه‌های مختلف ISP، اپراتور، Gatewayهای بین‌المللی و زیرساخت داخلی توزیع شده باشه، دولت میتونه به جای اینکه تک‌تک سایت‌ها رو ببنده، خودِ مسیر دسترسی به اینترنت جهانی رو کنترل کنه.
اینجاست که NIN یا شبکه ملی اطلاعات اهمیت پیدا می‌کنه. ایده فنی اینه که یک بخش بزرگ از سرویس‌های داخلی داخل یک فضای شبکه‌ای داخلی قابل دسترس باقی بمونن، حتی وقتی دسترسی به اینترنت بین‌المللی محدود شده. بنابراین «قطع اینترنت» لزوماً به معنی خاموش شدن همه شبکه‌ها نیست؛ میشه مسیر Global Internet رو محدود کرد ولی سرویس‌های داخلی، بانک‌ها، سامانه‌های دولتی و بعضی سرویس‌های مجاز همچنان کار کنن. گزارش Financial Times هم توضیح داده که ساختار شبکه کنترل‌شده داخلی ایران، امکان جدا کردن ارتباطات خارجی از سرویس‌های داخلی رو آسان‌تر کرده است.
این مدل از نظر معماری خیلی شبیه یک شبکه Enterprise فوق‌العاده بزرگه که مدیر شبکه تصمیم گرفته چه VLAN یا Segmentهایی به بیرون دسترسی داشته باشن و چه Segmentهایی فقط داخل شبکه خودشون کار کنن؛ با این تفاوت که اینجا مقیاسش یک کشوره.
حالا نقش چین دقیقاً کجاست؟ بخشی از شرکت‌های چینی، مخصوصاً Huawei و ZTE، سال‌ها در زیرساخت مخابرات و شبکه ایران حضور داشته‌اند و طبق گزارش‌های منتشرشده، فناوری‌های DPI و تجهیزات مرتبط با پایش و کنترل ترافیک نیز در این همکاری‌ها مطرح بوده‌اند. در کنار اون، شرکت‌هایی مثل Tiandy و Hikvision بیشتر در حوزه نظارت تصویری و تشخیص چهره مطرح‌اند؛ یعنی این همکاری فقط محدود به Packet و Router نیست و یک اکوسیستم گسترده‌تر نظارت دیجیتال شکل میده.
اگر بخوایم خیلی عمیق ولی فنی به قضیه نگاه کنیم، چین برای جمهوری اسلامی فقط «تجهیزات شبکه» نفروخته؛ چیزی که اهمیت بیشتری داره اینه که بخشی از تجربه و فناوری کنترل متمرکز اینترنت رو هم منتقل کرده. یعنی ایده این نیست که اینترنت رو کلاً خاموش کنن؛ مدل پیشرفته‌تر اینه که اینترنت وجود داشته باشه، ولی مسیر عبورش، مقصدش، سرعتش و حتی اینکه چه کسی به چه سرویسی دسترسی داشته باشه، قابل کنترل باشه.
یکی از قطعات مهم این داستان DPI یا Deep Packet Inspection ـه. DPI رو می‌تونی مثل یه سیستم بازرسی خیلی پیشرفته در مسیر ترافیک تصور کنی. وقتی ترافیک کاربر از شبکه ISP یا اپراتور رد میشه، تجهیزات می‌تونن مشخصات جریان ارتباطی رو بررسی کنن؛ مثلاً IP مقصد، پورت، پروتکل، مشخصات TLS و در بعضی شرایط اطلاعات قابل مشاهده داخل ترافیک. بعد بر اساس Policy تصمیم گرفته میشه که این ارتباط عبور کنه، Drop بشه، Reset بشه یا سرعتش محدود بشه. گزارش‌های منتشرشده درباره ایران، فناوری DPI ارائه‌شده یا مرتبط با شرکت‌هایی مثل Huawei و ZTE رو یکی از اجزای مهم این معماری معرفی می‌کنن.
حالا قسمت مهم‌تر ماجرا اینه که فیلترینگ فقط «بلاک کردن یه IP» نیست. فرض کن کاربر می‌خواد به یک سرویس خارجی وصل بشه. درخواست DNS میره، آدرس IP گرفته میشه، بعد ارتباط TCP یا UDP برقرار میشه و در HTTPS هم TLS Handshake اتفاق میفته. سیستم کنترل شبکه میتونه در چند نقطه مختلف روی این زنجیره دخالت کنه. حتی وقتی محتوای اصلی HTTPS رمزنگاری شده، بعضی Metadataها و مشخصات ارتباط، مثل SNI در TLS، در معماری‌های خاص می‌تونن برای اعمال Policy استفاده بشن. مطالعات فنی منتشرشده درباره فیلترینگ ایران، دخالت در DNS، HTTP، SNI در HTTPS و حتی ترافیک UDP/QUIC رو گزارش کرده‌اند.
یعنی ممکنه تو مرورگرت ببینی اینترنت «وصله»، ولی یک سایت خاص باز نمیشه؛ بعد فکر کنی مشکل DNS یا اینترنت خودته. در حالی که ممکنه اتصال عمداً در یکی از مراحل ارتباط قطع شده باشه. حتی میشه کاری کرد که ارتباط TCP شروع بشه ولی قبل از کامل شدن Session، اتصال با Packetهای Reset مختل بشه. نتیجه برای کاربر ساده است: «اینترنت خرابه»، ولی از دید شبکه یک Policy عمداً اجرا شده.
یه مرحله بالاتر، بحث Throttling یا کاهش عمدی کیفیت ارتباطه. لازم نیست همیشه سرویس رو کامل Block کنی. میشه با ایجاد Packet Loss، افزایش Latency، محدود کردن Bandwidth یا دستکاری مسیر، کیفیت سرویس رو آن‌قدر پایین آورد که عملاً استفاده ازش سخت یا غیرممکن بشه. این مدل از نظر فنی خیلی متفاوت از قطع کامل اینترنت به نظر میاد، ولی نتیجه برای کاربر میتونه تقریباً همون باشه: سرویس باز میشه اما ویدیو لود نمیشه، VPN ناپایدار میشه، تماس تصویری قطع میشه یا اتصال مرتب Timeout میخوره.
حالا می‌رسیم به قسمت خیلی مهم‌تر یعنی «اختلال سیستماتیک». وقتی کنترل فقط روی یک فایروال کوچک نیست و در لایه‌های مختلف ISP، اپراتور، Gatewayهای بین‌المللی و زیرساخت داخلی توزیع شده باشه، دولت میتونه به جای اینکه تک‌تک سایت‌ها رو ببنده، خودِ مسیر دسترسی به اینترنت جهانی رو کنترل کنه.
اینجاست که NIN یا شبکه ملی اطلاعات اهمیت پیدا می‌کنه. ایده فنی اینه که یک بخش بزرگ از سرویس‌های داخلی داخل یک فضای شبکه‌ای داخلی قابل دسترس باقی بمونن، حتی وقتی دسترسی به اینترنت بین‌المللی محدود شده. بنابراین «قطع اینترنت» لزوماً به معنی خاموش شدن همه شبکه‌ها نیست؛ میشه مسیر Global Internet رو محدود کرد ولی سرویس‌های داخلی، بانک‌ها، سامانه‌های دولتی و بعضی سرویس‌های مجاز همچنان کار کنن. گزارش Financial Times هم توضیح داده که ساختار شبکه کنترل‌شده داخلی ایران، امکان جدا کردن ارتباطات خارجی از سرویس‌های داخلی رو آسان‌تر کرده است.
این مدل از نظر معماری خیلی شبیه یک شبکه Enterprise فوق‌العاده بزرگه که مدیر شبکه تصمیم گرفته چه VLAN یا Segmentهایی به بیرون دسترسی داشته باشن و چه Segmentهایی فقط داخل شبکه خودشون کار کنن؛ با این تفاوت که اینجا مقیاسش یک کشوره.
حالا نقش چین دقیقاً کجاست؟ بخشی از شرکت‌های چینی، مخصوصاً Huawei و ZTE، سال‌ها در زیرساخت مخابرات و شبکه ایران حضور داشته‌اند و طبق گزارش‌های منتشرشده، فناوری‌های DPI و تجهیزات مرتبط با پایش و کنترل ترافیک نیز در این همکاری‌ها مطرح بوده‌اند. در کنار اون، شرکت‌هایی مثل Tiandy و Hikvision بیشتر در حوزه نظارت تصویری و تشخیص چهره مطرح‌اند؛ یعنی این همکاری فقط محدود به Packet و Router نیست و یک اکوسیستم گسترده‌تر نظارت دیجیتال شکل میده.
🔥7
شبکه به زبان ساده!
Photo
یه نکته خیلی مهم هم این وسط وجود داره: اینکه بگیم «چین کل فیلترینگ ایران رو ساخته» دقیق نیست. ایران خودش شرکت‌ها، سامانه‌ها و سیاست‌های داخلی زیادی داره و معماری نهایی حاصل ترکیب فناوری خارجی، تجهیزات داخلی، اپراتورها و تصمیمات حکومتیه. چیزی که درباره چین مهمه، فراهم کردن بخشی از فناوری و همچنین انتقال یک مدل فکریه که بهش Cyber Sovereignty یا حاکمیت سایبری گفته میشه؛ یعنی اینترنت داخل مرزهای کشور باید تا حد زیادی تحت کنترل حاکمیت باشه. ARTICLE 19 این شباهت فکری و فنی بین مدل چین و ایران رو یکی از محورهای اصلی همکاری دو کشور می‌دونه.
در واقع اگر کل داستان رو توی یک دیاگرام ببینی، تقریباً با چنین معماری‌ای طرفی:
User
↓
Mobile / ISP
↓
DNS / Filtering
↓
DPI / Traffic Classification
↓
Firewall / Policy Enforcement
↓
National Network ─────→ Domestic Services
│
↓
International Gateway
│
↓
Global Internet
در حالت عادی، ترافیک از User به سمت اینترنت جهانی میره؛ ولی در یک معماری کنترل‌شده، چند نقطه وجود داره که میشه روی اون‌ها Policy اعمال کرد. یکی DNS، یکی Gateway، یکی DPI، یکی Routing و یکی هم خود اپراتور.
و اینجاست که «اختلال سیستماتیک» معنی واقعی پیدا می‌کنه. لازم نیست یک نفر بشینه تک‌تک سایت‌ها رو خاموش کنه. اگر کنترل در سطح زیرساخت باشه، میشه Policy رو روی میلیون‌ها Connection اعمال کرد. مثلاً یک دسته IP Block بشن، یک Protocol محدود بشه، یک Domain از طریق DNS مختل بشه، یک نوع TLS Session قطع بشه، ترافیک UDP محدود بشه یا مسیر بین‌المللی تغییر کنه.
حتی میشه دسترسی کاربران رو به صورت Selective مدیریت کرد؛ یعنی یک کاربر یا سازمان دسترسی داشته باشه ولی کاربر عادی نداشته باشه. گزارش‌های مربوط به معماری جدید کنترل اینترنت ایران از حرکت به سمت مدل‌هایی صحبت می‌کنن که دسترسی عمومی بیشتر شبیه «Whitelist» میشه؛ یعنی به جای اینکه همه چیز آزاد باشه و چند مورد Block بشن، پیش‌فرض میتونه محدود باشه و فقط سرویس‌های مشخص اجازه عبور داشته باشن.
پس اگر بخوام خیلی خلاصه بگم، نقش چین رو باید در سه لایه ببینی:
لایه اول: تجهیزات؛ تجهیزات مخابراتی، شبکه، مانیتورینگ و فناوری‌های مرتبط.
لایه دوم: فناوری کنترل؛ DPI، Traffic Classification، Filtering، Monitoring و مدیریت متمرکز ترافیک.
لایه سوم که شاید از همه مهم‌تر باشه: مدل معماری؛ اینکه اینترنت به جای یک شبکه آزاد و End-to-End، تبدیل بشه به یک شبکه تحت Policy که حاکمیت بتونه تعیین کنه چه کسی، از کجا، با چه پروتکلی و به چه سرویسی وصل بشه.
@ModernLan
در واقع اگر کل داستان رو توی یک دیاگرام ببینی، تقریباً با چنین معماری‌ای طرفی:
User
↓
Mobile / ISP
↓
DNS / Filtering
↓
DPI / Traffic Classification
↓
Firewall / Policy Enforcement
↓
National Network ─────→ Domestic Services
│
↓
International Gateway
│
↓
Global Internet
در حالت عادی، ترافیک از User به سمت اینترنت جهانی میره؛ ولی در یک معماری کنترل‌شده، چند نقطه وجود داره که میشه روی اون‌ها Policy اعمال کرد. یکی DNS، یکی Gateway، یکی DPI، یکی Routing و یکی هم خود اپراتور.
و اینجاست که «اختلال سیستماتیک» معنی واقعی پیدا می‌کنه. لازم نیست یک نفر بشینه تک‌تک سایت‌ها رو خاموش کنه. اگر کنترل در سطح زیرساخت باشه، میشه Policy رو روی میلیون‌ها Connection اعمال کرد. مثلاً یک دسته IP Block بشن، یک Protocol محدود بشه، یک Domain از طریق DNS مختل بشه، یک نوع TLS Session قطع بشه، ترافیک UDP محدود بشه یا مسیر بین‌المللی تغییر کنه.
حتی میشه دسترسی کاربران رو به صورت Selective مدیریت کرد؛ یعنی یک کاربر یا سازمان دسترسی داشته باشه ولی کاربر عادی نداشته باشه. گزارش‌های مربوط به معماری جدید کنترل اینترنت ایران از حرکت به سمت مدل‌هایی صحبت می‌کنن که دسترسی عمومی بیشتر شبیه «Whitelist» میشه؛ یعنی به جای اینکه همه چیز آزاد باشه و چند مورد Block بشن، پیش‌فرض میتونه محدود باشه و فقط سرویس‌های مشخص اجازه عبور داشته باشن.
پس اگر بخوام خیلی خلاصه بگم، نقش چین رو باید در سه لایه ببینی:
لایه اول: تجهیزات؛ تجهیزات مخابراتی، شبکه، مانیتورینگ و فناوری‌های مرتبط.
لایه دوم: فناوری کنترل؛ DPI، Traffic Classification، Filtering، Monitoring و مدیریت متمرکز ترافیک.
لایه سوم که شاید از همه مهم‌تر باشه: مدل معماری؛ اینکه اینترنت به جای یک شبکه آزاد و End-to-End، تبدیل بشه به یک شبکه تحت Policy که حاکمیت بتونه تعیین کنه چه کسی، از کجا، با چه پروتکلی و به چه سرویسی وصل بشه.
@ModernLan
🔥6❤2
شبکه به زبان ساده!
Photo
اگر بخوام خیلی فنی براتون توضیح بدم، Load Balancer وسط کاربر و چند تا سرور قرار می‌گیره و تصمیم می‌گیره هر درخواست بره سمت کدوم سرور.
مثلاً این معماری رو داشته باش:
کاربر مثلاً به این آدرس می‌زنه:
DNS
معمولاً IP مربوط به Load Balancer رو برمی‌گردونه، نه IP مستقیم سرورها. درخواست میاد روی LB و اون بررسی می‌کنه کدوم Backend شرایط بهتری برای دریافت این Request داره.
روش‌های اصلی تقسیم ترافیک
1. Round Robin
خیلی ساده درخواست‌ها رو به ترتیب پخش می‌کنه:
برای زمانی خوبه که سرورها تقریباً قدرت مشابهی داشته باشن.
2. Weighted Round Robin
به هر سرور وزن میدی:
پس Server 1 درخواست بیشتری می‌گیره، چون قوی‌تره.
3. Least Connections
Load Balancer
تعداد Connectionهای فعال هر سرور رو بررسی می‌کنه و درخواست جدید رو معمولاً می‌فرسته سمت سروری که Connection کمتری داره:
برای سرویس‌هایی که Connectionها مدت‌زمان متفاوتی دارن خیلی کاربردیه.
4. IP Hash / Consistent Hashing
بر اساس IP کاربر تصمیم می‌گیره درخواست به کدوم Backend بره:
این روش میتونه باعث بشه یک Client تا حد زیادی به یک Backend مشخص هدایت بشه؛ مخصوصاً وقتی Session Persistence / Sticky Session لازم داری.
اما Load Balancer فقط «تقسیم» نمی‌کنه
یکی از مهم‌ترین قسمت‌ها Health Check هست.
فرض کن سه سرور داریم:
LB مرتب Backendها رو Check می‌کنه؛ مثلاً:
یا حتی TCP Connection روی پورت خاص:
اگر Server 3 جواب نده، Load Balancer اون رو از Pool خارج می‌کنه:
در نتیجه کاربر حتی ممکنه اصلاً متوجه خراب شدن Server 3 نشه.
یک نکته مهم‌تر: L4 و L7
Load Balancerها معمولاً در دو سطح معروف کار می‌کنن:
L4 Load Balancer
بر اساس اطلاعاتی مثل:
تصمیم می‌گیره.
مثلاً:
سریع‌تره چون لازم نیست محتوای HTTP رو بررسی کنه.
L7 Load Balancer
تا سطح Application میاد و میتونه چیزهایی مثل این‌ها رو ببینه:
مثلاً:
پس L7 میتونه خیلی هوشمندتر Route کنه.
در عمل، Load Balancer میتونه علاوه بر تقسیم بار، Health Check، SSL/TLS Termination، Session Persistence، Routing، Rate Limiting و حتی بعضی قابلیت‌های امنیتی رو هم انجام بده.
@ModernLan
مثلاً این معماری رو داشته باش:
کاربران
│
▼
┌────────────────┐
│ Load Balancer │
└───────┬────────┘
┌─────┼─────┐
▼ ▼ ▼
Server1 Server2 Server3
10.0.0.11 .12 .13
کاربر مثلاً به این آدرس می‌زنه:
https://example.com
DNS
معمولاً IP مربوط به Load Balancer رو برمی‌گردونه، نه IP مستقیم سرورها. درخواست میاد روی LB و اون بررسی می‌کنه کدوم Backend شرایط بهتری برای دریافت این Request داره.
روش‌های اصلی تقسیم ترافیک
1. Round Robin
خیلی ساده درخواست‌ها رو به ترتیب پخش می‌کنه:
Request 1 → Server 1
Request 2 → Server 2
Request 3 → Server 3
Request 4 → Server 1
Request 5 → Server 2
برای زمانی خوبه که سرورها تقریباً قدرت مشابهی داشته باشن.
2. Weighted Round Robin
به هر سرور وزن میدی:
Server 1 → Weight 5
Server 2 → Weight 3
Server 3 → Weight 1
پس Server 1 درخواست بیشتری می‌گیره، چون قوی‌تره.
3. Least Connections
Load Balancer
تعداد Connectionهای فعال هر سرور رو بررسی می‌کنه و درخواست جدید رو معمولاً می‌فرسته سمت سروری که Connection کمتری داره:
Server 1 → 80 connections
Server 2 → 25 connections ← Request جدید
Server 3 → 60 connections
برای سرویس‌هایی که Connectionها مدت‌زمان متفاوتی دارن خیلی کاربردیه.
4. IP Hash / Consistent Hashing
بر اساس IP کاربر تصمیم می‌گیره درخواست به کدوم Backend بره:
Client A → Server 1
Client B → Server 3
Client C → Server 2
این روش میتونه باعث بشه یک Client تا حد زیادی به یک Backend مشخص هدایت بشه؛ مخصوصاً وقتی Session Persistence / Sticky Session لازم داری.
اما Load Balancer فقط «تقسیم» نمی‌کنه
یکی از مهم‌ترین قسمت‌ها Health Check هست.
فرض کن سه سرور داریم:
Server 1 → UP
Server 2 → UP
Server 3 → DOWN
LB مرتب Backendها رو Check می‌کنه؛ مثلاً:
GET /health
یا حتی TCP Connection روی پورت خاص:
TCP/443 → Server
اگر Server 3 جواب نده، Load Balancer اون رو از Pool خارج می‌کنه:
Load Balancer
/ \
▼ ▼
Server 1 Server 2
X
Server 3
DOWN
در نتیجه کاربر حتی ممکنه اصلاً متوجه خراب شدن Server 3 نشه.
یک نکته مهم‌تر: L4 و L7
Load Balancerها معمولاً در دو سطح معروف کار می‌کنن:
L4 Load Balancer
بر اساس اطلاعاتی مثل:
Source IP
Destination IP
Source Port
Destination Port
TCP/UDP
تصمیم می‌گیره.
مثلاً:
TCP :443 → Backend Pool
سریع‌تره چون لازم نیست محتوای HTTP رو بررسی کنه.
L7 Load Balancer
تا سطح Application میاد و میتونه چیزهایی مثل این‌ها رو ببینه:
HTTP Method
URL
Host Header
Cookie
HTTP Header
مثلاً:
example.com/api/* → API Servers
example.com/images/* → Image Servers
example.com/shop/* → Shop Servers
پس L7 میتونه خیلی هوشمندتر Route کنه.
در عمل، Load Balancer میتونه علاوه بر تقسیم بار، Health Check، SSL/TLS Termination، Session Persistence، Routing، Rate Limiting و حتی بعضی قابلیت‌های امنیتی رو هم انجام بده.
@ModernLan
👍7❤3
شبکه به زبان ساده!
Photo
🔹 iSCSI چیست و چطور کار می‌کند؟
فناوری iSCSI مخفف Internet Small Computer Systems Interface هست و یه پروتکله برای اینکه بتونیم Storage رو از طریق شبکه IP در اختیار سرورها قرار بدیم؛ یعنی به‌جای اینکه هارد مستقیماً داخل خود سرور باشه، سرور از طریق شبکه به یک Storage مرکزی وصل میشه و یک فضای ذخیره‌سازی رو مثل یک دیسک در اختیار می‌گیره.
در iSCSI دو طرف اصلی داریم: Initiator و Target. Initiator معمولاً روی سروری قرار داره که می‌خواد به Storage دسترسی داشته باشه و Target سمت Storage قرار داره و فضای ذخیره‌سازی رو ارائه می‌کنه. Storage میتونه یک LUN بسازه و اون LUN رو از طریق iSCSI در اختیار سرور قرار بده.
مثلاً فرض کن یه شرکت چندتا سرور VMware داره و یک Storage مرکزی با ظرفیت چند ترابایت. به‌جای اینکه روی هر سرور کلی هارد نصب کنیم، Storage رو به شبکه وصل می‌کنیم و سرورها از طریق iSCSI به LUNهای اون دسترسی پیدا می‌کنن.
مسیر ارتباطی تقریباً این شکلیه:
نکته مهم اینه که iSCSI روی TCP/IP کار می‌کنه و پورت استانداردش TCP 3260 هست. بنابراین برخلاف تکنولوژی‌هایی مثل Fibre Channel، میتونه روی زیرساخت Ethernet و شبکه IP پیاده‌سازی بشه.
حالا LUN چیه؟ LUN رو می‌تونی مثل یه فضای Block-Level در نظر بگیری که Storage به سرور ارائه میده. سیستم‌عامل سرور اون رو به شکل یک Disk می‌بینه و میتونه روش Partition و File System ایجاد کنه.
اینجا تفاوت iSCSI با چیزهایی مثل SMB و NFS هم مهم میشه. SMB/NFS بیشتر برای File-Level Access استفاده میشن؛ یعنی سیستم‌عامل از یک Share به فایل‌ها دسترسی پیدا می‌کنه، ولی iSCSI در سطح Block Storage کار می‌کنه و سیستم‌عامل مقصد میتونه LUN رو مثل یک دیسک مدیریت کنه.
در محیط‌های حرفه‌ای معمولاً iSCSI رو با Multipathing هم پیاده‌سازی می‌کنن؛ یعنی بین سرور و Storage چند مسیر شبکه وجود داره تا اگر یک لینک یا مسیر قطع شد، ارتباط از مسیر دیگه ادامه پیدا کنه و Availability بالاتر بره.
پس خلاصه اگر بخوایم تو یه خط بگیم:
iSCSI
یعنی ارائه Storage در سطح Block از طریق شبکه IP، با استفاده از TCP/IP.
📌 مفاهیم مهمی که کنار iSCSI باید بلد باشی:
Initiator | Target | LUN | IQN | TCP/3260 | CHAP | Multipathing | Block Storage
#NetworkPlus #Networking #iSCSI #Storage #SAN #VMware #NetworkSecurity
🔗 @ModernLAN
فناوری iSCSI مخفف Internet Small Computer Systems Interface هست و یه پروتکله برای اینکه بتونیم Storage رو از طریق شبکه IP در اختیار سرورها قرار بدیم؛ یعنی به‌جای اینکه هارد مستقیماً داخل خود سرور باشه، سرور از طریق شبکه به یک Storage مرکزی وصل میشه و یک فضای ذخیره‌سازی رو مثل یک دیسک در اختیار می‌گیره.
در iSCSI دو طرف اصلی داریم: Initiator و Target. Initiator معمولاً روی سروری قرار داره که می‌خواد به Storage دسترسی داشته باشه و Target سمت Storage قرار داره و فضای ذخیره‌سازی رو ارائه می‌کنه. Storage میتونه یک LUN بسازه و اون LUN رو از طریق iSCSI در اختیار سرور قرار بده.
مثلاً فرض کن یه شرکت چندتا سرور VMware داره و یک Storage مرکزی با ظرفیت چند ترابایت. به‌جای اینکه روی هر سرور کلی هارد نصب کنیم، Storage رو به شبکه وصل می‌کنیم و سرورها از طریق iSCSI به LUNهای اون دسترسی پیدا می‌کنن.
مسیر ارتباطی تقریباً این شکلیه:
Server
│
│ iSCSI Initiator
│
▼
Ethernet / IP Network
│
▼
Switch
│
▼
Storage
│
│ iSCSI Target
▼
LUN
نکته مهم اینه که iSCSI روی TCP/IP کار می‌کنه و پورت استانداردش TCP 3260 هست. بنابراین برخلاف تکنولوژی‌هایی مثل Fibre Channel، میتونه روی زیرساخت Ethernet و شبکه IP پیاده‌سازی بشه.
حالا LUN چیه؟ LUN رو می‌تونی مثل یه فضای Block-Level در نظر بگیری که Storage به سرور ارائه میده. سیستم‌عامل سرور اون رو به شکل یک Disk می‌بینه و میتونه روش Partition و File System ایجاد کنه.
اینجا تفاوت iSCSI با چیزهایی مثل SMB و NFS هم مهم میشه. SMB/NFS بیشتر برای File-Level Access استفاده میشن؛ یعنی سیستم‌عامل از یک Share به فایل‌ها دسترسی پیدا می‌کنه، ولی iSCSI در سطح Block Storage کار می‌کنه و سیستم‌عامل مقصد میتونه LUN رو مثل یک دیسک مدیریت کنه.
در محیط‌های حرفه‌ای معمولاً iSCSI رو با Multipathing هم پیاده‌سازی می‌کنن؛ یعنی بین سرور و Storage چند مسیر شبکه وجود داره تا اگر یک لینک یا مسیر قطع شد، ارتباط از مسیر دیگه ادامه پیدا کنه و Availability بالاتر بره.
پس خلاصه اگر بخوایم تو یه خط بگیم:
iSCSI
یعنی ارائه Storage در سطح Block از طریق شبکه IP، با استفاده از TCP/IP.
📌 مفاهیم مهمی که کنار iSCSI باید بلد باشی:
Initiator | Target | LUN | IQN | TCP/3260 | CHAP | Multipathing | Block Storage
#NetworkPlus #Networking #iSCSI #Storage #SAN #VMware #NetworkSecurity
🔗 @ModernLAN
👍5
شبکه به زبان ساده!
Anycast چیست؟
Anycast چیست؟
یک روش آدرس‌دهی و مسیریابی در شبکه است که در آن یک IP یکسان روی چند سرور یا چند نقطه مختلف شبکه استفاده می‌شود. وقتی کاربر به آن IP متصل می‌شود، ترافیک معمولاً به سمتی هدایت می‌شود که از دید پروتکل مسیریابی، بهترین یا نزدیک‌ترین مسیر را دارد.
مثلاً فرض کن یک سرویس DNS سه سرور دارد:
کاربر در آسیا وقتی به
Anycast چطور کار می‌کند؟
فرض کن یک شرکت در سه دیتاسنتر مختلف سرویس یکسانی دارد:
هر سه دیتاسنتر همان IP Prefix را از طریق BGP اعلام می‌کنند. روترهای اینترنت با توجه به جدول Routing و معیارهای BGP تصمیم می‌گیرند ترافیک را از کدام مسیر بفرستند.
بنابراین ممکن است یک کاربر در اروپا به سرور لندن برسد، درحالی‌که کاربر دیگری با همان IP به سرور دبی یا توکیو برسد.
Anycast چه مزیتی دارد؟
کاهش Latency:
کاربر معمولاً به یک نقطه نسبتاً نزدیک‌تر هدایت می‌شود.
High Availability:
اگر یکی از سایت‌ها از دسترس خارج شود، می‌توان Route مربوط به آن را Withdraw کرد تا ترافیک به سایت‌های دیگر برود.
مقاومت بهتر در برابر DDoS:
ترافیک حمله می‌تواند بین چند نقطه توزیع شود؛ به همین دلیل Anycast در سرویس‌های بزرگ مثل DNS و CDN بسیار رایج است.
مقیاس‌پذیری:
به‌جای اینکه تمام کاربران جهان به یک دیتاسنتر متصل شوند، سرویس در چند نقطه ارائه می‌شود.
Anycast با Unicast چه فرقی دارد؟
در Unicast معمولاً یک IP به یک مقصد مشخص اشاره می‌کند:
ولی در Anycast چند مقصد مختلف می‌توانند همان IP را داشته باشند:
البته انتخاب مقصد توسط Routing انجام می‌شود، نه اینکه خود IP تشخیص دهد کدام سرور نزدیک‌تر است.
یک نکته خیلی مهم
Anycast
الزاماً به معنی نزدیک‌ترین سرور از نظر جغرافیایی نیست.
روترها بر اساس مسیری که Routing Protocol انتخاب می‌کند تصمیم می‌گیرند. بنابراین ممکن است یک سرور از نظر جغرافیایی نزدیک‌تر باشد ولی به دلیل سیاست‌های BGP یا ساختار مسیرهای اینترنت، ترافیک به نقطه دیگری برود.
@ModernLan
یک روش آدرس‌دهی و مسیریابی در شبکه است که در آن یک IP یکسان روی چند سرور یا چند نقطه مختلف شبکه استفاده می‌شود. وقتی کاربر به آن IP متصل می‌شود، ترافیک معمولاً به سمتی هدایت می‌شود که از دید پروتکل مسیریابی، بهترین یا نزدیک‌ترین مسیر را دارد.
مثلاً فرض کن یک سرویس DNS سه سرور دارد:
DNS Server 1 → 8.8.8.8 → اروپا
DNS Server 2 → 8.8.8.8 → آمریکا
DNS Server 3 → 8.8.8.8 → آسیا
کاربر در آسیا وقتی به
8.8.8.8 درخواست می‌فرستد، قرار نیست درخواستش به‌صورت تصادفی بین این سرورها پخش شود؛ Routing شبکه، مخصوصاً BGP در اینترنت، مسیر مناسب را انتخاب می‌کند.Anycast چطور کار می‌کند؟
فرض کن یک شرکت در سه دیتاسنتر مختلف سرویس یکسانی دارد:
Internet
|
+-------+-------+
| | |
BGP BGP BGP
| | |
London Dubai Tokyo
| | |
Server Server Server
1.2.3.4 1.2.3.4 1.2.3.4
هر سه دیتاسنتر همان IP Prefix را از طریق BGP اعلام می‌کنند. روترهای اینترنت با توجه به جدول Routing و معیارهای BGP تصمیم می‌گیرند ترافیک را از کدام مسیر بفرستند.
بنابراین ممکن است یک کاربر در اروپا به سرور لندن برسد، درحالی‌که کاربر دیگری با همان IP به سرور دبی یا توکیو برسد.
Anycast چه مزیتی دارد؟
کاهش Latency:
کاربر معمولاً به یک نقطه نسبتاً نزدیک‌تر هدایت می‌شود.
High Availability:
اگر یکی از سایت‌ها از دسترس خارج شود، می‌توان Route مربوط به آن را Withdraw کرد تا ترافیک به سایت‌های دیگر برود.
مقاومت بهتر در برابر DDoS:
ترافیک حمله می‌تواند بین چند نقطه توزیع شود؛ به همین دلیل Anycast در سرویس‌های بزرگ مثل DNS و CDN بسیار رایج است.
مقیاس‌پذیری:
به‌جای اینکه تمام کاربران جهان به یک دیتاسنتر متصل شوند، سرویس در چند نقطه ارائه می‌شود.
Anycast با Unicast چه فرقی دارد؟
در Unicast معمولاً یک IP به یک مقصد مشخص اشاره می‌کند:
Client ───────→ Server
10.10.10.10
ولی در Anycast چند مقصد مختلف می‌توانند همان IP را داشته باشند:
┌→ Server A
Client → 10.10.10.10├→ Server B
└→ Server C
البته انتخاب مقصد توسط Routing انجام می‌شود، نه اینکه خود IP تشخیص دهد کدام سرور نزدیک‌تر است.
یک نکته خیلی مهم
Anycast
الزاماً به معنی نزدیک‌ترین سرور از نظر جغرافیایی نیست.
روترها بر اساس مسیری که Routing Protocol انتخاب می‌کند تصمیم می‌گیرند. بنابراین ممکن است یک سرور از نظر جغرافیایی نزدیک‌تر باشد ولی به دلیل سیاست‌های BGP یا ساختار مسیرهای اینترنت، ترافیک به نقطه دیگری برود.
@ModernLan
👍4❤3
شبکه به زبان ساده!
Photo
🔎 از روی یک Packet مشکوک چطور بفهمیم حمله در حال رخ دادنه؟
تو Wireshark صرفاً با دیدن یک Packet نمیشه با قطعیت گفت حمله اتفاق افتاده؛ چیزی که مهمه Context و الگوی ترافیکه. یعنی باید ببینی این Packet از کجا اومده، به کجا میره، چه Flagهایی داره و در کنار Packetهای دیگه چه رفتاری ایجاد می‌کنه.
1️⃣ Source / Destination
اول
2️⃣ TCP Flags
TCP Flag
ها خیلی چیزها رو مشخص می‌کنن. مثلاً تعداد زیادی
3️⃣ DNS
در DNS دنبال رفتارهای غیرعادی بگرد؛ مثلاً تعداد زیادی Query در مدت کوتاه، درخواست برای Domainهای تصادفی و طولانی، تعداد زیادی
4️⃣ HTTP
اگر HTTP بدون رمزنگاری باشه، می‌تونی Requestها رو مستقیم بررسی کنی. دنبال چیزهایی مثل
5️⃣ الگوی زمانی و حجم ترافیک
یکی از مهم‌ترین چیزها اینه که Packet رو تنها نبینی. مثلاً:
خیلی متفاوت از این حالته:
یا:
اینجا احتمال یک رفتار غیرعادی خیلی بیشتره.
6️⃣ چند نشونه را کنار هم بگذار
مثلاً اگر ببینی:
و این روند برای تعداد زیادی Port تکرار بشه، الگوی رفتاری بیشتر به Port Scanning شبیهه تا یک اتصال عادی.
در Wireshark می‌تونی از فیلترهایی مثل این‌ها برای شروع استفاده کنی:
برای دیدن SYNهای بدون ACK.
برای بررسی RSTها.
برای مشاهده DNS Traffic.
برای HTTP Requestها.
برای محدود کردن بررسی به یک IP خاص.
نکته مهم: تشخیص واقعی حمله معمولاً با یک Packet انجام نمیشه؛ باید Source/Destination + Flags + Port + Frequency + Payload + Sequence رفتارها رو کنار هم گذاشت. Wireshark بهت شواهد شبکه‌ای میده، ولی برای تشخیص دقیق‌تر معمولاً باید این شواهد رو با لاگ‌های Firewall، IDS/IPS، DNS Server و سیستم مقصد هم تطبیق بدی.
@ModernLan
تو Wireshark صرفاً با دیدن یک Packet نمیشه با قطعیت گفت حمله اتفاق افتاده؛ چیزی که مهمه Context و الگوی ترافیکه. یعنی باید ببینی این Packet از کجا اومده، به کجا میره، چه Flagهایی داره و در کنار Packetهای دیگه چه رفتاری ایجاد می‌کنه.
1️⃣ Source / Destination
اول
Source IP و Destination IP رو بررسی کن. مثلاً اگر یک IP ناشناس داره در مدت کوتاه تعداد زیادی Connection به یک Server داخلی می‌زنه، میتونه نشونه‌ی Scan یا حمله باشه. مخصوصاً وقتی یک Source به تعداد زیادی Port مختلف روی یک سیستم درخواست می‌فرسته.2️⃣ TCP Flags
TCP Flag
ها خیلی چیزها رو مشخص می‌کنن. مثلاً تعداد زیادی
SYN بدون اینکه SYN, ACK مناسب از سمت مقصد برگرده، میتونه نشونه‌ی SYN Scan یا SYN Flood باشه. تعداد زیاد RST هم میتونه در کنار سایر شواهد نشون‌دهنده‌ی Scan یا Connectionهای ناموفق باشه. پس Flag رو باید به‌صورت Pattern بررسی کرد، نه یک Packet منفرد.3️⃣ DNS
در DNS دنبال رفتارهای غیرعادی بگرد؛ مثلاً تعداد زیادی Query در مدت کوتاه، درخواست برای Domainهای تصادفی و طولانی، تعداد زیادی
NXDOMAIN یا Subdomainهای غیرمعمول. این رفتارها می‌تونن در بعضی سناریوها با DNS Tunneling، Malware یا Domain Generation Algorithm (DGA) دیده بشن.4️⃣ HTTP
اگر HTTP بدون رمزنگاری باشه، می‌تونی Requestها رو مستقیم بررسی کنی. دنبال چیزهایی مثل
GET/POSTهای غیرعادی، تعداد زیاد Request به یک Endpoint، URIهای خیلی طولانی، پارامترهای مشکوک یا الگوهایی مثل تلاش برای دستکاری ورودی‌ها باش. البته وجود یک رشته مشکوک به‌تنهایی اثبات حمله نیست.5️⃣ الگوی زمانی و حجم ترافیک
یکی از مهم‌ترین چیزها اینه که Packet رو تنها نبینی. مثلاً:
1 Request → Response → تمامخیلی متفاوت از این حالته:
1000 SYN → یک Destination → در چند ثانیهیا:
یک Client → تعداد زیادی DNS Query تصادفی → چندین Domain ناشناساینجا احتمال یک رفتار غیرعادی خیلی بیشتره.
6️⃣ چند نشونه را کنار هم بگذار
مثلاً اگر ببینی:
Unknown IP → SYN → Port 22Unknown IP → SYN → Port 80Unknown IP → SYN → Port 443Unknown IP → SYN → Port 445Unknown IP → SYN → Port 3389و این روند برای تعداد زیادی Port تکرار بشه، الگوی رفتاری بیشتر به Port Scanning شبیهه تا یک اتصال عادی.
در Wireshark می‌تونی از فیلترهایی مثل این‌ها برای شروع استفاده کنی:
tcp.flags.syn == 1 && tcp.flags.ack == 0
برای دیدن SYNهای بدون ACK.
tcp.flags.reset == 1
برای بررسی RSTها.
dns
برای مشاهده DNS Traffic.
http.request
برای HTTP Requestها.
ip.addr == 192.168.1.10
برای محدود کردن بررسی به یک IP خاص.
نکته مهم: تشخیص واقعی حمله معمولاً با یک Packet انجام نمیشه؛ باید Source/Destination + Flags + Port + Frequency + Payload + Sequence رفتارها رو کنار هم گذاشت. Wireshark بهت شواهد شبکه‌ای میده، ولی برای تشخیص دقیق‌تر معمولاً باید این شواهد رو با لاگ‌های Firewall، IDS/IPS، DNS Server و سیستم مقصد هم تطبیق بدی.
@ModernLan
🔥6
شبکه به زبان ساده!
Photo
🔥 Reverse Proxy vs Forward Proxy فرقشون چیه؟
اگه بخوای خیلی ساده تفاوت Forward Proxy و Reverse Proxy رو بفهمی، باید بدونی که Forward Proxy نماینده‌ی Client هست ولی Reverse Proxy نماینده‌ی Server. توی Forward Proxy داستان از سمت کاربر شروع میشه؛ یعنی کاربر به‌جای اینکه مستقیم به اینترنت یا یک Server مقصد وصل بشه، درخواستش رو می‌فرسته سمت Proxy و Proxy اون درخواست رو از طرف کاربر به مقصد می‌رسونه.
ساختار کلیش میشه Client → Forward Proxy → Internet/Server. مثلاً توی یک شرکت ممکنه سیستم‌های کارمندان مستقیماً به اینترنت دسترسی نداشته باشن و تمام درخواست‌ها اول از یک Proxy سازمانی رد بشن. اونجا Proxy میتونه روی درخواست‌ها Policy اعمال کنه، دسترسی بعضی سایت‌ها رو محدود کنه، ترافیک رو Log کنه، Cache انجام بده و حتی باعث بشه مقصد به‌جای IP واقعی Client، IP مربوط به Proxy رو ببینه. پس Forward Proxy بیشتر برای کنترل و مدیریت دسترسی کاربران استفاده میشه.
حالا Reverse Proxy دقیقاً از اون طرف قضیه وارد میشه. اینجا Proxy جلوی Server قرار می‌گیره و Client معمولاً اصلاً خبر نداره پشت این Proxy چند تا Server وجود داره.
ساختارش میشه Client → Reverse Proxy → Backend Server. مثلاً کاربر وارد یک سایت میشه و درخواستش به Reverse Proxy می‌رسه؛ Reverse Proxy بررسی می‌کنه درخواست برای کدوم سرویس یا Server هست و بعد اون رو به یکی از Backend Serverها می‌فرسته. حتی ممکنه پشت Reverse Proxy ده‌ها Server وجود داشته باشه و Reverse Proxy درخواست‌ها رو بین اون‌ها تقسیم کنه؛ اینجاست که بحث Load Balancing مطرح میشه. علاوه بر این، Reverse Proxy میتونه TLS/SSL رو Terminate کنه، درخواست‌های مشکوک رو فیلتر کنه، Rate Limiting انجام بده، Cache داشته باشه و جلوی دسترسی مستقیم به Backend Serverها رو بگیره.
مثلاً فرض کن یک سایت بزرگ داری و سه تا Web Server پشتش هست. کاربر فقط Reverse Proxy رو می‌بینه و درخواستش میاد روی Reverse Proxy؛ بعد Proxy بر اساس الگوریتم Load Balancing مثل Round Robin یا Least Connections تصمیم می‌گیره درخواست رو به Server 1 یا Server 2 یا Server 3 بفرسته. در این حالت اگر یکی از Serverها Down بشه، Reverse Proxy میتونه درخواست‌ها رو به Serverهای سالم هدایت کنن.
پس اگه بخوای خیلی راحت تو ذهنت بمونه، Forward Proxy یعنی «من به جای Client میرم سمت اینترنت» و Reverse Proxy یعنی «من جلوی Server وایسادم و درخواست Client رو می‌گیرم و تصمیم می‌گیرم به کدوم Backend بفرستم». Forward Proxy بیشتر سمت کاربران و شبکه‌ی داخلی دیده میشه، ولی Reverse Proxy بیشتر سمت سرویس‌ها و Web Serverها قرار می‌گیره و چیزهایی مثل Load Balancer، WAF، TLS Termination، Cache و کنترل دسترسی معمولاً اونجا دیده میشن.
@ModernLan
اگه بخوای خیلی ساده تفاوت Forward Proxy و Reverse Proxy رو بفهمی، باید بدونی که Forward Proxy نماینده‌ی Client هست ولی Reverse Proxy نماینده‌ی Server. توی Forward Proxy داستان از سمت کاربر شروع میشه؛ یعنی کاربر به‌جای اینکه مستقیم به اینترنت یا یک Server مقصد وصل بشه، درخواستش رو می‌فرسته سمت Proxy و Proxy اون درخواست رو از طرف کاربر به مقصد می‌رسونه.
ساختار کلیش میشه Client → Forward Proxy → Internet/Server. مثلاً توی یک شرکت ممکنه سیستم‌های کارمندان مستقیماً به اینترنت دسترسی نداشته باشن و تمام درخواست‌ها اول از یک Proxy سازمانی رد بشن. اونجا Proxy میتونه روی درخواست‌ها Policy اعمال کنه، دسترسی بعضی سایت‌ها رو محدود کنه، ترافیک رو Log کنه، Cache انجام بده و حتی باعث بشه مقصد به‌جای IP واقعی Client، IP مربوط به Proxy رو ببینه. پس Forward Proxy بیشتر برای کنترل و مدیریت دسترسی کاربران استفاده میشه.
حالا Reverse Proxy دقیقاً از اون طرف قضیه وارد میشه. اینجا Proxy جلوی Server قرار می‌گیره و Client معمولاً اصلاً خبر نداره پشت این Proxy چند تا Server وجود داره.
ساختارش میشه Client → Reverse Proxy → Backend Server. مثلاً کاربر وارد یک سایت میشه و درخواستش به Reverse Proxy می‌رسه؛ Reverse Proxy بررسی می‌کنه درخواست برای کدوم سرویس یا Server هست و بعد اون رو به یکی از Backend Serverها می‌فرسته. حتی ممکنه پشت Reverse Proxy ده‌ها Server وجود داشته باشه و Reverse Proxy درخواست‌ها رو بین اون‌ها تقسیم کنه؛ اینجاست که بحث Load Balancing مطرح میشه. علاوه بر این، Reverse Proxy میتونه TLS/SSL رو Terminate کنه، درخواست‌های مشکوک رو فیلتر کنه، Rate Limiting انجام بده، Cache داشته باشه و جلوی دسترسی مستقیم به Backend Serverها رو بگیره.
مثلاً فرض کن یک سایت بزرگ داری و سه تا Web Server پشتش هست. کاربر فقط Reverse Proxy رو می‌بینه و درخواستش میاد روی Reverse Proxy؛ بعد Proxy بر اساس الگوریتم Load Balancing مثل Round Robin یا Least Connections تصمیم می‌گیره درخواست رو به Server 1 یا Server 2 یا Server 3 بفرسته. در این حالت اگر یکی از Serverها Down بشه، Reverse Proxy میتونه درخواست‌ها رو به Serverهای سالم هدایت کنن.
پس اگه بخوای خیلی راحت تو ذهنت بمونه، Forward Proxy یعنی «من به جای Client میرم سمت اینترنت» و Reverse Proxy یعنی «من جلوی Server وایسادم و درخواست Client رو می‌گیرم و تصمیم می‌گیرم به کدوم Backend بفرستم». Forward Proxy بیشتر سمت کاربران و شبکه‌ی داخلی دیده میشه، ولی Reverse Proxy بیشتر سمت سرویس‌ها و Web Serverها قرار می‌گیره و چیزهایی مثل Load Balancer، WAF، TLS Termination، Cache و کنترل دسترسی معمولاً اونجا دیده میشن.
@ModernLan
❤5👍3
Media is too big
VIEW IN TELEGRAM
یک روش تجربی برای بررسی مشکل در ارتباطات فیبر نکات : این روش برای ارتباطات مالتی مود بهتر و راحت تر جواب میده و در مسافتهای طولانی بخاطر تضعیف ممکنه جواب نگیرید پورت تجهیز باید فعال باشه (no shutdown)
با چشم مستقیم به sfpها نگاه نکنید که ممکنه به چشم اسیب بزنه این یک روش تجربی هست و میتونه خطا داشته باشه و در مواقعی که تجهیزات نداریم میتونه به ما کمک کنه.
@ModernLan
با چشم مستقیم به sfpها نگاه نکنید که ممکنه به چشم اسیب بزنه این یک روش تجربی هست و میتونه خطا داشته باشه و در مواقعی که تجهیزات نداریم میتونه به ما کمک کنه.
@ModernLan
❤5
شبکه به زبان ساده!
Photo
🌐 BGP چطور اینترنت رو به هم وصل می‌کنه؟
اینترنت در واقع یه شبکه بزرگ و یکپارچه نیست؛ از هزاران شبکه مختلف تشکیل شده که هر کدوم متعلق به یه ISP، اپراتور، دیتاسنتر، شرکت بزرگ یا سازمانه. به هر کدوم از این شبکه‌های مستقل می‌گیم AS یا Autonomous System. مثلاً یه ISP یه AS داره، یه اپراتور موبایل یه AS دیگه و یه شرکت بزرگ هم ممکنه AS خودش رو داشته باشه.
حالا مشکل اینجاست که این شبکه‌ها باید بدونن برای رسیدن به شبکه‌های دیگه از چه مسیری برن. مثلاً فرض کن یه ISP توی ایران می‌خواد به یه سرور توی دیتاسنتر آلمان وصل بشه. ISP باید بدونه Prefix مربوط به اون سرور از کدوم شبکه قابل دسترسیه و برای رسیدن به اون باید بسته رو به کدوم شبکه بعدی تحویل بده. اینجاست که BGP وارد میشه.
در اصل زبان ارتباطی بین شبکه‌های مستقله. شبکه‌ها با BGP به هم اعلام می‌کنن که «من به این Prefixها دسترسی دارم». مثلاً یه شبکه اعلام می‌کنه که Prefix زیر متعلق به منه و می‌تونم ترافیک مربوط بهش رو دریافت کنم:
شبکه‌های اطراف این Route رو یاد می‌گیرن و ممکنه اون رو به شبکه‌های دیگه هم اعلام کنن. این اطلاعات کم‌کم بین ASهای مختلف پخش میشه و شبکه‌ها متوجه میشن برای رسیدن به Prefixهای مختلف چه مسیرهایی وجود داره.
مثلاً فرض کن سه شبکه داریم:
AS300
صاحب یه Prefix خاصه. AS300 اون Prefix رو به AS200 اعلام می‌کنه، AS200 هم متوجه میشه برای رسیدن به اون Prefix باید از AS300 استفاده کنه. بعد همین Route ممکنه به AS100 هم برسه. در نتیجه AS100 می‌فهمه برای رسیدن به اون Prefix میتونه از مسیر
حالا ممکنه فقط یه مسیر وجود نداشته باشه. مثلاً AS100 برای رسیدن به AS300 دو مسیر مختلف داشته باشه:
یا:
اینجا BGP قرار نیست صرفاً بگه «هر کدوم کوتاه‌تره همونو انتخاب کن». BGP بر اساس یه سری Attribute و Policy تصمیم می‌گیره کدوم Route ترجیح داده بشه. چیزهایی مثل LOCAL_PREF، AS_PATH، MED و نوع Route می‌تونن روی انتخاب مسیر تأثیر بذارن.
یکی از قسمت‌های مهم BGP هم AS_PATH هست. هر Route وقتی از یک AS عبور می‌کنه، شماره اون AS به مسیر اضافه میشه. مثلاً:
حالا اگر AS100 یه Route رو دوباره دریافت کنه و داخل AS_PATH ببینه که خودش یعنی
یه نکته خیلی مهم هم اینه که BGP فقط برای پیدا کردن مسیر نیست؛ Policy توی BGP خیلی مهمه. یعنی صاحب شبکه میتونه تعیین کنه چه Routeهایی رو به چه شبکه‌ای Advertise کنه و برای انتخاب مسیرهای مختلف چه ترجیحی داشته باشه.
مثلاً یه ISP ممکنه دو تا Provider اینترنت داشته باشه. میتونه با Policyهای BGP کاری کنه که ترافیک بعضی Prefixها از Provider اول عبور کنه و ترافیک بعضی مقصدهای دیگه از Provider دوم. پس BGP فقط یه نقشه ساده از اینترنت نیست؛ در واقع شبکه‌ها باهاش روی نحوه تبادل و انتخاب مسیر هم سیاست‌گذاری می‌کنن.
حالا وقتی تو از خونه می‌خوای به یه سایت خارجی وصل بشی، بسته‌ات ممکنه از چندین شبکه مختلف عبور کنه. هر شبکه در مسیر، بر اساس Routing Table خودش تصمیم می‌گیره بسته رو به کدوم Next-Hop بفرسته. BGP هم کمک کرده این شبکه‌ها اطلاعات لازم درباره Prefixهای شبکه‌های دیگه رو داشته باشن.
پس خیلی خلاصه اگر بخوایم قضیه رو جمع کنیم، DNS معمولاً اسم دامنه رو به IP تبدیل می‌کنه، BGP به شبکه‌های مستقل کمک می‌کنه بفهمن Prefixهای مختلف از چه مسیرهایی قابل دسترسی هستن، و IP Routing داخل هر شبکه تصمیم می‌گیره بسته رو به کدوم Next-Hop بفرسته.
مثلاً وقتی می‌زنی:
اول باید IP مقصد مشخص بشه. بعد بسته از شبکه خودت وارد مسیر اینترنت میشه و روترها بر اساس Routeهایی که دارن تصمیم می‌گیرن بسته رو به کجا بفرستن. این Routeها در مقیاس بین شبکه‌های مستقل، بخش مهمی از اطلاعاتشون رو از BGP می‌گیرن.
به خاطر همین هم BGP یکی از پایه‌های اصلی اینترنت محسوب میشه. چون اینترنت از هزاران شبکه مستقل تشکیل شده و این شبکه‌ها باید somehow بتونن مسیرهای خودشون رو به هم اعلام کنن و درباره Reachability شبکه‌های مختلف اطلاعات داشته باشن.
یه مثال خیلی ساده بخوایم بزنیم: اینترنت رو مثل یه سیستم بزرگ از شهرها و جاده‌ها در نظر بگیر. هر AS مثل یه شهر یا مجموعه جاده‌ای مستقله، Prefixها مثل محدوده‌های مقصد هستن و BGP مثل سیستمیه که به شبکه‌ها میگه برای رسیدن به مقصدهای مختلف چه مسیرهایی وجود داره و کدوم مسیر طبق Policyهای شبکه ترجیح داده میشه.
اینترنت در واقع یه شبکه بزرگ و یکپارچه نیست؛ از هزاران شبکه مختلف تشکیل شده که هر کدوم متعلق به یه ISP، اپراتور، دیتاسنتر، شرکت بزرگ یا سازمانه. به هر کدوم از این شبکه‌های مستقل می‌گیم AS یا Autonomous System. مثلاً یه ISP یه AS داره، یه اپراتور موبایل یه AS دیگه و یه شرکت بزرگ هم ممکنه AS خودش رو داشته باشه.
حالا مشکل اینجاست که این شبکه‌ها باید بدونن برای رسیدن به شبکه‌های دیگه از چه مسیری برن. مثلاً فرض کن یه ISP توی ایران می‌خواد به یه سرور توی دیتاسنتر آلمان وصل بشه. ISP باید بدونه Prefix مربوط به اون سرور از کدوم شبکه قابل دسترسیه و برای رسیدن به اون باید بسته رو به کدوم شبکه بعدی تحویل بده. اینجاست که BGP وارد میشه.
در اصل زبان ارتباطی بین شبکه‌های مستقله. شبکه‌ها با BGP به هم اعلام می‌کنن که «من به این Prefixها دسترسی دارم». مثلاً یه شبکه اعلام می‌کنه که Prefix زیر متعلق به منه و می‌تونم ترافیک مربوط بهش رو دریافت کنم:
203.0.113.0/24شبکه‌های اطراف این Route رو یاد می‌گیرن و ممکنه اون رو به شبکه‌های دیگه هم اعلام کنن. این اطلاعات کم‌کم بین ASهای مختلف پخش میشه و شبکه‌ها متوجه میشن برای رسیدن به Prefixهای مختلف چه مسیرهایی وجود داره.
مثلاً فرض کن سه شبکه داریم:
AS100 → AS200 → AS300AS300
صاحب یه Prefix خاصه. AS300 اون Prefix رو به AS200 اعلام می‌کنه، AS200 هم متوجه میشه برای رسیدن به اون Prefix باید از AS300 استفاده کنه. بعد همین Route ممکنه به AS100 هم برسه. در نتیجه AS100 می‌فهمه برای رسیدن به اون Prefix میتونه از مسیر
AS100 → AS200 → AS300 استفاده کنه.حالا ممکنه فقط یه مسیر وجود نداشته باشه. مثلاً AS100 برای رسیدن به AS300 دو مسیر مختلف داشته باشه:
AS100 → AS200 → AS300یا:
AS100 → AS400 → AS500 → AS300اینجا BGP قرار نیست صرفاً بگه «هر کدوم کوتاه‌تره همونو انتخاب کن». BGP بر اساس یه سری Attribute و Policy تصمیم می‌گیره کدوم Route ترجیح داده بشه. چیزهایی مثل LOCAL_PREF، AS_PATH، MED و نوع Route می‌تونن روی انتخاب مسیر تأثیر بذارن.
یکی از قسمت‌های مهم BGP هم AS_PATH هست. هر Route وقتی از یک AS عبور می‌کنه، شماره اون AS به مسیر اضافه میشه. مثلاً:
AS100 → AS200 → AS300حالا اگر AS100 یه Route رو دوباره دریافت کنه و داخل AS_PATH ببینه که خودش یعنی
AS100 قبلاً توی مسیر وجود داشته، می‌فهمه این مسیر میتونه باعث Loop بشه و اون Route رو قبول نمی‌کنه. این یکی از مکانیزم‌های مهم BGP برای جلوگیری از Loop بین ASهاست.یه نکته خیلی مهم هم اینه که BGP فقط برای پیدا کردن مسیر نیست؛ Policy توی BGP خیلی مهمه. یعنی صاحب شبکه میتونه تعیین کنه چه Routeهایی رو به چه شبکه‌ای Advertise کنه و برای انتخاب مسیرهای مختلف چه ترجیحی داشته باشه.
مثلاً یه ISP ممکنه دو تا Provider اینترنت داشته باشه. میتونه با Policyهای BGP کاری کنه که ترافیک بعضی Prefixها از Provider اول عبور کنه و ترافیک بعضی مقصدهای دیگه از Provider دوم. پس BGP فقط یه نقشه ساده از اینترنت نیست؛ در واقع شبکه‌ها باهاش روی نحوه تبادل و انتخاب مسیر هم سیاست‌گذاری می‌کنن.
حالا وقتی تو از خونه می‌خوای به یه سایت خارجی وصل بشی، بسته‌ات ممکنه از چندین شبکه مختلف عبور کنه. هر شبکه در مسیر، بر اساس Routing Table خودش تصمیم می‌گیره بسته رو به کدوم Next-Hop بفرسته. BGP هم کمک کرده این شبکه‌ها اطلاعات لازم درباره Prefixهای شبکه‌های دیگه رو داشته باشن.
پس خیلی خلاصه اگر بخوایم قضیه رو جمع کنیم، DNS معمولاً اسم دامنه رو به IP تبدیل می‌کنه، BGP به شبکه‌های مستقل کمک می‌کنه بفهمن Prefixهای مختلف از چه مسیرهایی قابل دسترسی هستن، و IP Routing داخل هر شبکه تصمیم می‌گیره بسته رو به کدوم Next-Hop بفرسته.
مثلاً وقتی می‌زنی:
example.comاول باید IP مقصد مشخص بشه. بعد بسته از شبکه خودت وارد مسیر اینترنت میشه و روترها بر اساس Routeهایی که دارن تصمیم می‌گیرن بسته رو به کجا بفرستن. این Routeها در مقیاس بین شبکه‌های مستقل، بخش مهمی از اطلاعاتشون رو از BGP می‌گیرن.
به خاطر همین هم BGP یکی از پایه‌های اصلی اینترنت محسوب میشه. چون اینترنت از هزاران شبکه مستقل تشکیل شده و این شبکه‌ها باید somehow بتونن مسیرهای خودشون رو به هم اعلام کنن و درباره Reachability شبکه‌های مختلف اطلاعات داشته باشن.
یه مثال خیلی ساده بخوایم بزنیم: اینترنت رو مثل یه سیستم بزرگ از شهرها و جاده‌ها در نظر بگیر. هر AS مثل یه شهر یا مجموعه جاده‌ای مستقله، Prefixها مثل محدوده‌های مقصد هستن و BGP مثل سیستمیه که به شبکه‌ها میگه برای رسیدن به مقصدهای مختلف چه مسیرهایی وجود داره و کدوم مسیر طبق Policyهای شبکه ترجیح داده میشه.
❤7🤩3
شبکه به زبان ساده!
Photo
چرا چند سایت یک IP دارند؟
چون در اینترنت IP الزاماً نماینده‌ی یک سایت نیست؛ یک IP می‌تواند متعلق به یک سرور، کلاستر، Load Balancer یا سرویس ابری باشد و چندین دامنه روی همان زیرساخت میزبانی شوند.
فرض کن این دامنه‌ها را داریم:
ممکن است DNS هر سه به یک IP اشاره کند:
وقتی کاربر به آن IP وصل می‌شود، وب‌سرور از روی نام دامنه‌ای که درخواست شده تشخیص می‌دهد باید کدام سایت را تحویل بدهد.
مثلاً درخواست HTTP/HTTPS شامل اطلاعاتی مثل این است:
یا در HTTPS، نام دامنه معمولاً از طریق SNI در TLS مشخص می‌شود:
این تکنیک به‌خصوص در Virtual Hosting خیلی رایج است.
یک دلیل مهم دیگر: CDN و Load Balancer
گاهی اصلاً IP مربوط به سرور اصلی سایت نیست.
مثلاً چندین سایت پشت یک CDN یا Load Balancer قرار گرفته‌اند:
در این حالت ممکن است صدها یا حتی تعداد بسیار زیادی دامنه، IPهای مشترک CDN را داشته باشند.
پس اگر یک IP را پیدا کردیم، نمی‌توانیم بگوییم «این IP متعلق به همین سایت است»
دقیقاً. ممکن است یک IP:
فقط یک سایت داشته باشد.
چند سایت روی یک سرور داشته باشد.
متعلق به Load Balancer باشد.
متعلق به CDN باشد.
بین چند مشتری یک سرویس ابری مشترک باشد.
در IPv4 به‌دلیل کمبود آدرس، بین سرویس‌های مختلف اشتراکی باشد.
برای همین در شناسایی زیرساخت یک سایت، صرفاً پیدا کردن IP کافی نیست و باید DNS، رکوردهای A/AAAA، CNAME، SNI، HTTP Host و معماری CDN/Load Balancer را هم در نظر گرفت.
@ModernLan
چون در اینترنت IP الزاماً نماینده‌ی یک سایت نیست؛ یک IP می‌تواند متعلق به یک سرور، کلاستر، Load Balancer یا سرویس ابری باشد و چندین دامنه روی همان زیرساخت میزبانی شوند.
فرض کن این دامنه‌ها را داریم:
site1.com
site2.com
site3.com
ممکن است DNS هر سه به یک IP اشاره کند:
site1.com → 185.10.20.30
site2.com → 185.10.20.30
site3.com → 185.10.20.30
وقتی کاربر به آن IP وصل می‌شود، وب‌سرور از روی نام دامنه‌ای که درخواست شده تشخیص می‌دهد باید کدام سایت را تحویل بدهد.
مثلاً درخواست HTTP/HTTPS شامل اطلاعاتی مثل این است:
Host: site1.com
یا در HTTPS، نام دامنه معمولاً از طریق SNI در TLS مشخص می‌شود:
Client
│
│ site1.com
▼
185.10.20.30
│
├── site1.com
├── site2.com
└── site3.com
این تکنیک به‌خصوص در Virtual Hosting خیلی رایج است.
یک دلیل مهم دیگر: CDN و Load Balancer
گاهی اصلاً IP مربوط به سرور اصلی سایت نیست.
مثلاً چندین سایت پشت یک CDN یا Load Balancer قرار گرفته‌اند:
┌── Web Server 1
site1.com ───────┤
├── Web Server 2
site2.com ──► CDN / Load Balancer
├── Web Server 3
site3.com ───────┤
└── Web Server 4
در این حالت ممکن است صدها یا حتی تعداد بسیار زیادی دامنه، IPهای مشترک CDN را داشته باشند.
پس اگر یک IP را پیدا کردیم، نمی‌توانیم بگوییم «این IP متعلق به همین سایت است»
دقیقاً. ممکن است یک IP:
فقط یک سایت داشته باشد.
چند سایت روی یک سرور داشته باشد.
متعلق به Load Balancer باشد.
متعلق به CDN باشد.
بین چند مشتری یک سرویس ابری مشترک باشد.
در IPv4 به‌دلیل کمبود آدرس، بین سرویس‌های مختلف اشتراکی باشد.
برای همین در شناسایی زیرساخت یک سایت، صرفاً پیدا کردن IP کافی نیست و باید DNS، رکوردهای A/AAAA، CNAME، SNI، HTTP Host و معماری CDN/Load Balancer را هم در نظر گرفت.
@ModernLan
👍5❤3👏1
AI Agent چیه؟
در واقع AI Agent فقط یه هوش مصنوعی نیست که ازش سؤال بپرسی و جواب بگیری؛ یه جور سیستم هوشمنده که بهش یه هدف میدی و خودش میتونه برای رسیدن به اون هدف چند مرحله رو پشت سر هم انجام بده. مثلاً بهش میگی «وضعیت سرورهای شبکه رو بررسی کن و اگه مشکلی وجود داشت گزارش بده»، Agent میاد اطلاعات رو از ابزارهای مختلف جمع می‌کنه، لاگ‌ها رو بررسی می‌کنه، وضعیت CPU و RAM و سرویس‌ها رو می‌بینه، مشکل احتمالی رو تحلیل می‌کنه و بعد بر اساس نتیجه تصمیم می‌گیره چه کاری انجام بشه.
حتی اگه به ابزارهای لازم دسترسی داشته باشه، میتونه با SSH به سرور وصل بشه، یه سرویس رو بررسی یا در شرایط مشخص Restart کنه، دوباره وضعیت رو تست کنه و در آخر نتیجه رو گزارش بده.
نتیجه رو بررسی می‌کنه و اگه لازم باشه دوباره مرحله بعدی رو انجام میده. تفاوت اصلی AI Agent با یه Chatbot معمولی هم دقیقاً همینجاست؛ Chatbot معمولاً منتظر سؤال می‌مونه و جواب میده، ولی Agent میتونه برای رسیدن به یه هدف، خودش چندین مرحله رو مدیریت کنه.
البته خود مدل زبانی به تنهایی لزوماً Agent نیست؛ معمولاً Agent از چند بخش تشکیل میشه، مثل مدل هوش مصنوعی، ابزارها و APIها، Memory برای نگهداری اطلاعات، منطق تصمیم‌گیری و دسترسی به سیستم‌هایی که قراره باهاشون کار کنه. مثلاً توی Network و Cyber Security میشه یه AI Agent ساخت که لاگ‌های Firewall و SIEM رو بررسی کنه، رفتارهای مشکوک رو پیدا کنه، وضعیت تجهیزات شبکه رو مانیتور کنه، برای Troubleshooting اطلاعات جمع کنه و حتی طبق Policy مشخص بعضی Actionها رو انجام بده.
@ModernLAN
در واقع AI Agent فقط یه هوش مصنوعی نیست که ازش سؤال بپرسی و جواب بگیری؛ یه جور سیستم هوشمنده که بهش یه هدف میدی و خودش میتونه برای رسیدن به اون هدف چند مرحله رو پشت سر هم انجام بده. مثلاً بهش میگی «وضعیت سرورهای شبکه رو بررسی کن و اگه مشکلی وجود داشت گزارش بده»، Agent میاد اطلاعات رو از ابزارهای مختلف جمع می‌کنه، لاگ‌ها رو بررسی می‌کنه، وضعیت CPU و RAM و سرویس‌ها رو می‌بینه، مشکل احتمالی رو تحلیل می‌کنه و بعد بر اساس نتیجه تصمیم می‌گیره چه کاری انجام بشه.
حتی اگه به ابزارهای لازم دسترسی داشته باشه، میتونه با SSH به سرور وصل بشه، یه سرویس رو بررسی یا در شرایط مشخص Restart کنه، دوباره وضعیت رو تست کنه و در آخر نتیجه رو گزارش بده.
نتیجه رو بررسی می‌کنه و اگه لازم باشه دوباره مرحله بعدی رو انجام میده. تفاوت اصلی AI Agent با یه Chatbot معمولی هم دقیقاً همینجاست؛ Chatbot معمولاً منتظر سؤال می‌مونه و جواب میده، ولی Agent میتونه برای رسیدن به یه هدف، خودش چندین مرحله رو مدیریت کنه.
البته خود مدل زبانی به تنهایی لزوماً Agent نیست؛ معمولاً Agent از چند بخش تشکیل میشه، مثل مدل هوش مصنوعی، ابزارها و APIها، Memory برای نگهداری اطلاعات، منطق تصمیم‌گیری و دسترسی به سیستم‌هایی که قراره باهاشون کار کنه. مثلاً توی Network و Cyber Security میشه یه AI Agent ساخت که لاگ‌های Firewall و SIEM رو بررسی کنه، رفتارهای مشکوک رو پیدا کنه، وضعیت تجهیزات شبکه رو مانیتور کنه، برای Troubleshooting اطلاعات جمع کنه و حتی طبق Policy مشخص بعضی Actionها رو انجام بده.
@ModernLAN
❤7👍4