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

کاربران
                │
                ▼
        ┌────────────────┐
        │  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

🔹 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های اون دسترسی پیدا می‌کنن.
مسیر ارتباطی تقریباً این شکلیه:

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

Anycast چیست؟

Anycast چیست؟


یک روش آدرس‌دهی و مسیریابی در شبکه است که در آن یک 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

🔎 از روی یک Packet مشکوک چطور بفهمیم حمله در حال رخ دادنه؟

تو 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 22

Unknown IP → SYN → Port 80

Unknown IP → SYN → Port 443

Unknown IP → SYN → Port 445

Unknown 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

🔥 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

یک روش تجربی برای بررسی مشکل در ارتباطات فیبر نکات : این روش برای ارتباطات مالتی مود بهتر و راحت تر جواب میده و در مسافتهای طولانی بخاطر تضعیف ممکنه جواب نگیرید پورت تجهیز باید فعال باشه (no shutdown)

با چشم مستقیم به sfpها نگاه نکنید که ممکنه به چشم اسیب بزنه این یک روش تجربی هست و میتونه خطا داشته باشه و در مواقعی که تجهیزات نداریم میتونه به ما کمک کنه.


@ModernLan

🌐 BGP چطور اینترنت رو به هم وصل می‌کنه؟

اینترنت در واقع یه شبکه بزرگ و یکپارچه نیست؛ از هزاران شبکه مختلف تشکیل شده که هر کدوم متعلق به یه 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 → AS300

AS300
صاحب یه 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های شبکه ترجیح داده میشه.

Windows XP❤️

چرا چند سایت یک IP دارند؟

چون در اینترنت 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

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

RAID
رو اگه بخوایم خیلی کامل نگاه کنیم، یه روشه برای اینکه چندتا هارد یا SSD رو کنار هم قرار بدیم تا بسته به نوع RAID، یا سرعت بیشتری بگیریم، یا اگر یکی از دیسک‌ها خراب شد اطلاعاتمون همچنان قابل دسترس باشه، یا ترکیبی از این دوتا داشته باشیم.

اولین مدل RAID 0 هست که تمرکزش روی سرعته. توی RAID 0 اطلاعات بین دیسک‌ها تقسیم میشه یا همون Striping؛ مثلاً اگه دو تا دیسک 1 ترابایتی داشته باشیم، بخشی از اطلاعات روی دیسک اول و بخش دیگه روی دیسک دوم نوشته میشه و چون هر دو دیسک همزمان کار می‌کنن، سرعت خواندن و نوشتن می‌تونه بیشتر بشه و کل ظرفیت هم حدود 2 ترابایت میشه، ولی یه ایراد خیلی مهم داره و اونم اینه که هیچ تحمل خرابی نداره؛ یعنی اگه فقط یکی از دیسک‌ها خراب بشه، کل RAID 0 از بین میره، پس برای اطلاعات مهم اصلاً گزینه مناسبی نیست.

بعد می‌رسیم به RAID 1 که بهش Mirroring هم میگن. اینجا اطلاعات روی دو دیسک به صورت یکسان ذخیره میشه؛ یعنی اگه روی دیسک اول اطلاعات A و B و C داشته باشیم، همون اطلاعات روی دیسک دوم هم وجود داره. در نتیجه اگه یکی از دیسک‌ها خراب بشه، دیسک دوم همچنان اطلاعات رو داره و سیستم می‌تونه به کارش ادامه بده.

مثلاً دو تا دیسک 1 ترابایتی در RAID 1 در مجموع فقط حدود 1 ترابایت فضای قابل استفاده بهت میدن، چون نصف ظرفیت صرف کپی اطلاعات میشه. RAID 5 یه مرحله حرفه‌ای‌تره و از ترکیب Striping و Parity استفاده می‌کنه. یعنی اطلاعات بین دیسک‌ها پخش میشه و در کنارش اطلاعات Parity هم ذخیره میشه تا اگر یکی از دیسک‌ها خراب شد، RAID بتونه اطلاعات از دست‌رفته رو از روی بقیه دیسک‌ها بازسازی کنه.

مثلاً اگه 4 تا دیسک 1 ترابایتی داشته باشیم، حدود 3 ترابایت فضای قابل استفاده داریم و می‌تونیم خرابی یک دیسک رو تحمل کنیم. البته موقع Rebuild کردن RAID 5 فشار زیادی روی دیسک‌های باقی‌مونده وارد میشه و مخصوصاً توی آرایه‌های بزرگ این موضوع مهمه. RAID 6 شبیه RAID 5 هست ولی به جای یک Parity، دو تا Parity داره؛ در نتیجه می‌تونه خرابی همزمان دو دیسک رو تحمل کنه. مثلاً با 6 تا دیسک 1 ترابایتی، حدود 4 ترابایت فضای قابل استفاده خواهیم داشت. طبیعتاً در مقابل امنیت بیشتری می‌گیریم ولی محاسبات و عملیات نوشتن پیچیده‌تر میشه و بخشی از ظرفیت هم برای دو Parity مصرف میشه. آخرش می‌رسیم به RAID 10 که ترکیبی از RAID 1 و RAID 0 هست و معمولاً با اسم RAID 1+0 هم می‌بینیمش.


اینجا اول دیسک‌ها به صورت Mirror جفت میشن و بعد اطلاعات بین این جفت‌ها Strip میشه؛ مثلاً با 4 تا دیسک 1 ترابایتی، حدود 2 ترابایت فضای قابل استفاده داریم، ولی همزمان Performance خوبی داریم و در برابر خرابی دیسک هم مقاوم‌تر هستیم. البته تحمل خرابی RAID 10 بستگی داره کدوم دیسک‌ها خراب بشن؛ اگر از هر جفت Mirror حداقل یک دیسک سالم باقی بمونه، آرایه می‌تونه به کارش ادامه بده، ولی اگر هر دو دیسک یک جفت از بین برن، اون بخش دیگه قابل بازیابی نیست.

@ModernLan

SCADA چیست؟


مخفف این فناوری Supervisory Control And Data Acquisition یعنی کنترل نظارتی و جمع‌آوری داده است. به زبان ساده، SCADA یک سیستم نرم‌افزاری و سخت‌افزاریه که برای مانیتورینگ، جمع‌آوری اطلاعات و کنترل تجهیزات صنعتی از یک نقطه مرکزی استفاده میشه.

مثلاً فرض کن یک کارخانه آب و فاضلاب داریم که ده‌ها پمپ، شیر، مخزن، سنسور فشار و سنسور دما داره. اپراتور لازم نیست کنار تک‌تک این تجهیزات باشه؛ سیستم SCADA اطلاعات اون‌ها رو جمع می‌کنه و روی یک صفحه مانیتور نشون میده و در بعضی موارد امکان ارسال فرمان به تجهیزات رو هم فراهم می‌کنه.
معماری معمول SCADA تقریباً این شکلیه:

Operator
            │
            ▼
      ┌─────────────┐
      │ SCADA Server│
      └──────┬──────┘
             │
       Industrial Network
             │
      ┌──────┴──────┐
      ▼             ▼
    PLC/RTU       PLC/RTU
      │             │
   Sensors       Actuators
   Motors         Valves
   Pumps          Relays

اجزای اصلی SCADA
1. PLC
کنترلرهای صنعتی هستن که مستقیماً با تجهیزات و سنسورها کار می‌کنن؛ مثلاً دمای یک مخزن رو می‌خونن یا فرمان روشن شدن یک موتور رو اجرا می‌کنن.
2. RTU
مخفف Remote Terminal Unit هست و بیشتر در مکان‌های دور از مرکز استفاده میشه؛ مثلاً ایستگاه‌های پمپاژ، خطوط انتقال نفت و گاز یا تأسیسات برق.
3. SCADA Server
مرکز جمع‌آوری و پردازش اطلاعاته. داده‌هایی که از PLC و RTU میان اینجا دریافت و ذخیره میشن.
4. HMI
رابط گرافیکی‌ایه که اپراتور از طریق اون وضعیت سیستم رو می‌بینه و در صورت مجاز بودن می‌تونه فرمان ارسال کنه.
مثلاً:

Pump 01 → RUNNING
Pump 02 → STOPPED
Tank Level → 78%
Pressure → 4.2 bar
Temperature → 31°C

5. Historian
اطلاعات و رخدادهای سیستم رو برای مدت طولانی ذخیره می‌کنه تا بعداً بشه روندها، خطاها و تغییرات رو بررسی کرد.
SCADA با شبکه معمولی چه فرقی داره؟
اینجا قسمت جالب ماجراست. SCADA معمولاً بخشی از یک شبکه صنعتی یا OT (Operational Technology) محسوب میشه.
در شبکه‌های IT معمولاً تمرکز زیادی روی چیزهایی مثل:

Confidentiality → Integrity → Availability

داریم، اما در محیط‌های صنعتی Availability و Safety اهمیت بسیار زیادی پیدا می‌کنن؛ چون از کار افتادن یک سیستم صنعتی ممکنه فقط باعث قطع یک سرویس نشه و روی تجهیزات فیزیکی و فرآیند واقعی تأثیر بذاره.

برای ارتباط بین تجهیزات هم پروتکل‌هایی مثل:
Modbus / Modbus TCP
DNP3
OPC UA
IEC 60870-5-104
IEC 61850
EtherNet/IP
PROFINET
استفاده میشن.
مثلاً یک سناریوی ساده:

Sensor
   ↓
PLC
   ↓
Industrial Switch
   ↓
SCADA Server
   ↓
HMI
   ↓
Operator

اپراتور روی HMI می‌بینه فشار یک خط بالا رفته، SCADA این داده رو از PLC دریافت کرده و PLC هم مقدار فشار رو از سنسور گرفته. اگر سیستم برای کنترل خودکار طراحی شده باشه، PLC می‌تونه بر اساس منطق کنترلی خودش یک شیر یا پمپ رو هم کنترل کنه.
نکته مهم: SCADA خودش لزوماً «کنترل‌کننده اصلی» نیست؛ در بسیاری از معماری‌ها SCADA بیشتر نقش نظارت، نمایش، ثبت داده و ارسال فرمان‌های سطح بالا رو داره و کنترل بلادرنگ فرآیند توسط PLC/RTU انجام میشه.

@ModernLan