شبکه به زبان ساده!
Photo
AI در SOC هوش مصنوعی دقیقاً چه کار میکند؟
در یک SOC معمولی، سیستمهایی مثل SIEM از منابع مختلف لاگ جمع میکنند؛ مثلاً Windows Event Log، Firewall، IDS/IPS، EDR، DNS، Proxy و تجهیزات شبکه. مشکل اینجاست که تعداد Alertها میتواند خیلی زیاد باشد و بررسی تکتک آنها زمانبر است. اینجاست که AI وارد میشود.
مثلاً فرض کن یک کاربر در مدت کوتاه چندین بار Login ناموفق داشته، بعد یک Login موفق از یک موقعیت غیرعادی اتفاق افتاده و بلافاصله روی چندین سیستم درخواست دسترسی کرده. AI میتواند این Eventها را کنار هم قرار بدهد و بهجای اینکه هرکدام را یک Alert جداگانه ببیند، آنها را بهعنوان یک زنجیره احتمالی حمله تحلیل کند.
یکی از کاربردهای مهم AI در SOC، Alert Triage است؛ یعنی بین Alertهای مختلف تشخیص بدهد کدام مورد احتمالاً False Positive است و کدام مورد ارزش بررسی بیشتری دارد.
کاربرد بعدی تشخیص رفتار غیرعادی است. مثلاً اگر یک حساب کاربری همیشه در ساعات اداری از یک سیستم مشخص استفاده میکند ولی ناگهان ساعت ۳ صبح وارد سیستم دیگری شود و حجم زیادی داده دریافت کند، این رفتار میتواند برای بررسی بیشتر Flag شود.
همچنین میتواند در Threat Hunting کمک کند؛ یعنی Analyst بهجای اینکه تکتک لاگها را دستی بررسی کند، از سیستم بخواهد الگوهای مشکوک، ارتباط بین Eventها یا رفتارهای غیرمعمول را پیدا کند.
در مرحله Incident Response هم میتواند مفید باشد؛ مثلاً Alert مربوط به یک Endpoint را با DNS Queryها، لاگ Firewall، Processهای اجراشده و ارتباطات شبکه آن Endpoint مرتبط کند و یک تصویر کاملتر از Incident بدهد.
یک سناریوی ساده:
مثلاً AI متوجه میشود:
نکته مهم اینه که AI بهتنهایی نباید تصمیم نهایی امنیتی بگیرد. چون ممکن است یک رفتار کاملاً قانونی را حمله تشخیص بدهد یا برعکس، یک حمله واقعی را از دست بدهد.
برای همین در SOC حرفهای معمولاً AI در کنار SIEM، EDR/XDR، SOAR و تحلیلگر انسانی قرار میگیرد.
در واقع معماری مدرن میتواند چیزی شبیه این باشد:
هوش مصنوعی قرار نیست SOC را حذف کند؛ هدف اصلیش اینه که Analyst بهجای غرق شدن بین هزاران Alert، روی Incidentهای مهمتر تمرکز کنه.
@ModernLan
در یک SOC معمولی، سیستمهایی مثل SIEM از منابع مختلف لاگ جمع میکنند؛ مثلاً Windows Event Log، Firewall، IDS/IPS، EDR، DNS، Proxy و تجهیزات شبکه. مشکل اینجاست که تعداد Alertها میتواند خیلی زیاد باشد و بررسی تکتک آنها زمانبر است. اینجاست که AI وارد میشود.
مثلاً فرض کن یک کاربر در مدت کوتاه چندین بار Login ناموفق داشته، بعد یک Login موفق از یک موقعیت غیرعادی اتفاق افتاده و بلافاصله روی چندین سیستم درخواست دسترسی کرده. AI میتواند این Eventها را کنار هم قرار بدهد و بهجای اینکه هرکدام را یک Alert جداگانه ببیند، آنها را بهعنوان یک زنجیره احتمالی حمله تحلیل کند.
یکی از کاربردهای مهم AI در SOC، Alert Triage است؛ یعنی بین Alertهای مختلف تشخیص بدهد کدام مورد احتمالاً False Positive است و کدام مورد ارزش بررسی بیشتری دارد.
کاربرد بعدی تشخیص رفتار غیرعادی است. مثلاً اگر یک حساب کاربری همیشه در ساعات اداری از یک سیستم مشخص استفاده میکند ولی ناگهان ساعت ۳ صبح وارد سیستم دیگری شود و حجم زیادی داده دریافت کند، این رفتار میتواند برای بررسی بیشتر Flag شود.
همچنین میتواند در Threat Hunting کمک کند؛ یعنی Analyst بهجای اینکه تکتک لاگها را دستی بررسی کند، از سیستم بخواهد الگوهای مشکوک، ارتباط بین Eventها یا رفتارهای غیرمعمول را پیدا کند.
در مرحله Incident Response هم میتواند مفید باشد؛ مثلاً Alert مربوط به یک Endpoint را با DNS Queryها، لاگ Firewall، Processهای اجراشده و ارتباطات شبکه آن Endpoint مرتبط کند و یک تصویر کاملتر از Incident بدهد.
یک سناریوی ساده:
User Login
↓
Windows Event Logs
↓
SIEM
↓
AI Analysis
↓
Correlation
↓
Risk Scoring
↓
SOC Analyst
↓
Incident Response
مثلاً AI متوجه میشود:
Failed Login × 30
+
Successful Login
+
PowerShell Execution
+
Suspicious DNS Query
+
Outbound Connection
↓
Possible Compromise
نکته مهم اینه که AI بهتنهایی نباید تصمیم نهایی امنیتی بگیرد. چون ممکن است یک رفتار کاملاً قانونی را حمله تشخیص بدهد یا برعکس، یک حمله واقعی را از دست بدهد.
برای همین در SOC حرفهای معمولاً AI در کنار SIEM، EDR/XDR، SOAR و تحلیلگر انسانی قرار میگیرد.
در واقع معماری مدرن میتواند چیزی شبیه این باشد:
Logs / Network / Endpoint
↓
SIEM / XDR
↓
AI / ML Analysis
↓
Correlation + Detection
↓
SOAR
↓
Automated Response
↓
SOC Analyst
هوش مصنوعی قرار نیست SOC را حذف کند؛ هدف اصلیش اینه که Analyst بهجای غرق شدن بین هزاران Alert، روی Incidentهای مهمتر تمرکز کنه.
@ModernLan
❤7
شبکه به زبان ساده!
Photo
اگر بخوایم فنی نگاه کنیم، یک پیام ساده در اینترنت فقط با یک پروتکل جابهجا نمیشه؛ معمولاً چندین لایه و پروتکل پشت سر هم درگیر میشن.
مثلاً وقتی در مرورگر
Application → Transport → Internet → Data Link → Physical
1. Application Layer
اینجا خود برنامه و پروتکل کاربردی قرار دارن:
HTTP / HTTPS
DNS
SMTP
SSH و...
مثلاً در HTTPS، دادهی HTTP قبل از ارسال توسط TLS رمزنگاری میشه.
2. Transport Layer
بسته به سرویس، معمولاً:
TCP → اتصالگرا، قابلاعتماد
UDP → سریعتر و بدون تضمین تحویل
QUIC → روی UDP، مورد استفادهی HTTP/3
مثلاً در HTTPS سنتی:
3. Internet Layer
اینجا IP وارد میشه:
IPv4
IPv6
ICMP
IP مشخص میکنه بسته از مبدأ به مقصد چطور مسیریابی بشه.
4. Data Link Layer
در شبکهی محلی پروتکلهایی مثل:
Ethernet
Wi-Fi
ARP
درگیر میشن. اینجا فریم ساخته میشه و MAC Address نقش مهمی داره.
5. Physical Layer
در نهایت بیتها واقعاً منتقل میشن:
مثلاً از طریق:
کابل Ethernet
فیبر نوری
Wi-Fi
شبکه موبایل
پس اگر یک پیام را از بالا به پایین دنبال کنیم، یک نمونه میتواند این باشد:
اما نکتهی مهم اینه که همهی ارتباطات اینترنتی دقیقاً همین ساختار رو ندارن. مثلاً در HTTP/3 مسیر میتونه این باشه:
و در هر روتر بین راه، معمولاً فریم لایه ۲ باز میشه و با فریم جدید دوباره ساخته میشه، ولی بستهی IP در طول مسیر برای رسیدن به مقصد مسیریابی میشه.
@ModernLan
مثلاً وقتی در مرورگر
https://Google.com رو باز میکنی، مسیر کلی این شکلیه:Application → Transport → Internet → Data Link → Physical
1. Application Layer
اینجا خود برنامه و پروتکل کاربردی قرار دارن:
HTTP / HTTPS
DNS
SMTP
SSH و...
مثلاً در HTTPS، دادهی HTTP قبل از ارسال توسط TLS رمزنگاری میشه.
2. Transport Layer
بسته به سرویس، معمولاً:
TCP → اتصالگرا، قابلاعتماد
UDP → سریعتر و بدون تضمین تحویل
QUIC → روی UDP، مورد استفادهی HTTP/3
مثلاً در HTTPS سنتی:
HTTP → TLS → TCP3. Internet Layer
اینجا IP وارد میشه:
IPv4
IPv6
ICMP
IP مشخص میکنه بسته از مبدأ به مقصد چطور مسیریابی بشه.
4. Data Link Layer
در شبکهی محلی پروتکلهایی مثل:
Ethernet
Wi-Fi
ARP
درگیر میشن. اینجا فریم ساخته میشه و MAC Address نقش مهمی داره.
5. Physical Layer
در نهایت بیتها واقعاً منتقل میشن:
0 و 1 → سیگنال الکتریکی / نوری / رادیوییمثلاً از طریق:
کابل Ethernet
فیبر نوری
Wi-Fi
شبکه موبایل
پس اگر یک پیام را از بالا به پایین دنبال کنیم، یک نمونه میتواند این باشد:
Application
↓
HTTP
↓
TLS
↓
TCP
↓
IP
↓
Ethernet / Wi-Fi
↓
Physical
اما نکتهی مهم اینه که همهی ارتباطات اینترنتی دقیقاً همین ساختار رو ندارن. مثلاً در HTTP/3 مسیر میتونه این باشه:
HTTP/3
↓
QUIC
↓
UDP
↓
IP
↓
Ethernet / Wi-Fi
↓
Physical
و در هر روتر بین راه، معمولاً فریم لایه ۲ باز میشه و با فریم جدید دوباره ساخته میشه، ولی بستهی IP در طول مسیر برای رسیدن به مقصد مسیریابی میشه.
@ModernLan
🔥7❤2
شبکه به زبان ساده!
Photo
لیست کامل منابع CVE و PoC🧨
CVE Official List
https://github.com/CVEProject/cvelistV5
CVE Project
https://github.com/CVEProject
CVE PoC Index
https://github.com/0xMarcio/pocindex
CVE PoC Search Engine
https://github.com/secnotes/searchpoc
CVE PoC Repository Index
https://github.com/tg12/PoC_CVEs
CVE 2026 PoC
https://github.com/SecureWithUmer/CVE-2026-PoCs
Vulnerability PoC
https://github.com/fankh/vulnerability-poc
Exploit Intel CVE/PoC
https://github.com/exploitintel/eip-pocs-and-cves
CVE PoC Collection
https://github.com/d2cy/CVEs
CVE PoC Monitor
https://github.com/zulloper/cve-poc
@ModernLan
CVE Official List
https://github.com/CVEProject/cvelistV5
CVE Project
https://github.com/CVEProject
CVE PoC Index
https://github.com/0xMarcio/pocindex
CVE PoC Search Engine
https://github.com/secnotes/searchpoc
CVE PoC Repository Index
https://github.com/tg12/PoC_CVEs
CVE 2026 PoC
https://github.com/SecureWithUmer/CVE-2026-PoCs
Vulnerability PoC
https://github.com/fankh/vulnerability-poc
Exploit Intel CVE/PoC
https://github.com/exploitintel/eip-pocs-and-cves
CVE PoC Collection
https://github.com/d2cy/CVEs
CVE PoC Monitor
https://github.com/zulloper/cve-poc
@ModernLan
❤5👍3
This media is not supported in your browser
VIEW IN TELEGRAM
حس رضایت محض مدیریت کابلِ تمیز و مرتب. کارِ تمیز و بینقص همیشه بهترین جلوه را دارد!
❤7👍3👏1
شبکه به زبان ساده!
Photo
🔐 TLS Handshake چیه و موقع باز کردن یک سایت امن چه اتفاقی میافته؟
وقتی وارد سایتی مثل HTTPS میشیم، قبل از اینکه اطلاعاتی مثل رمز عبور، کوکی یا محتوای صفحه بین مرورگر و سرور رد و بدل بشه، مرورگر و سرور باید با هم یک ارتباط امن ایجاد کنن. به این فرآیند میگن TLS Handshake.
اول مرورگر یک پیام به اسم ClientHello برای سرور میفرسته و داخلش اطلاعاتی مثل نسخههای TLS قابل پشتیبانی، Cipher Suiteهای مورد قبول و در TLS 1.3 یک Key Share قرار میده. سرور این اطلاعات رو بررسی میکنه و در ServerHello مشخص میکنه که از چه پارامترهایی برای ارتباط استفاده بشه و Key Share خودش رو هم ارسال میکنه.
بعد سرور Certificate خودش رو میفرسته. این Certificate شامل کلید عمومی سروره و توسط یک CA معتبر امضا شده تا کلاینت بتونه بررسی کنه واقعاً با همون سروری که ادعا میکنه در ارتباطه. بعد از اون CertificateVerify ارسال میشه که سرور با استفاده از Private Key خودش ثابت میکنه مالک Certificate مربوطه است.
حالا با استفاده از Key Exchange، معمولاً ECDHE، کلاینت و سرور میتونن به یک Secret مشترک برسن؛ بدون اینکه خود Secret رو مستقیم روی شبکه ارسال کنن. از این Secret، کلیدهای Session برای رمزنگاری ارتباط ساخته میشن.
در مرحله بعد پیام Finished رد و بدل میشه. این پیام عملاً به طرف مقابل میگه که مراحل Handshake با موفقیت انجام شده و از اینجا به بعد ارتباط با کلیدهای Session رمزنگاری میشه.
پس خیلی خلاصه، TLS Handshake سه کار اصلی انجام میده:
🔹 احراز هویت سرور با Certificate
🔹 توافق روی کلیدهای رمزنگاری
🔹 آمادهسازی یک کانال امن برای انتقال داده
در TLS 1.3 این فرآیند نسبت به TLS 1.2 سادهتر و سریعتر شده و معمولاً برای تکمیل Handshake به یک Round Trip نیاز داره.
یعنی وقتی مرورگرت HTTPS رو میبینه، قبل از اینکه اطلاعات حساس رو امن ارسال کنه، یک مذاکره رمزنگاریشده بین Client و Server انجام میشه تا مشخص بشه «با چه الگوریتمی ارتباط برقرار کنیم، سرور واقعاً کیه و کلیدهای رمزنگاری این ارتباط چی باشن.»
@ModernLAN
وقتی وارد سایتی مثل HTTPS میشیم، قبل از اینکه اطلاعاتی مثل رمز عبور، کوکی یا محتوای صفحه بین مرورگر و سرور رد و بدل بشه، مرورگر و سرور باید با هم یک ارتباط امن ایجاد کنن. به این فرآیند میگن TLS Handshake.
اول مرورگر یک پیام به اسم ClientHello برای سرور میفرسته و داخلش اطلاعاتی مثل نسخههای TLS قابل پشتیبانی، Cipher Suiteهای مورد قبول و در TLS 1.3 یک Key Share قرار میده. سرور این اطلاعات رو بررسی میکنه و در ServerHello مشخص میکنه که از چه پارامترهایی برای ارتباط استفاده بشه و Key Share خودش رو هم ارسال میکنه.
بعد سرور Certificate خودش رو میفرسته. این Certificate شامل کلید عمومی سروره و توسط یک CA معتبر امضا شده تا کلاینت بتونه بررسی کنه واقعاً با همون سروری که ادعا میکنه در ارتباطه. بعد از اون CertificateVerify ارسال میشه که سرور با استفاده از Private Key خودش ثابت میکنه مالک Certificate مربوطه است.
حالا با استفاده از Key Exchange، معمولاً ECDHE، کلاینت و سرور میتونن به یک Secret مشترک برسن؛ بدون اینکه خود Secret رو مستقیم روی شبکه ارسال کنن. از این Secret، کلیدهای Session برای رمزنگاری ارتباط ساخته میشن.
در مرحله بعد پیام Finished رد و بدل میشه. این پیام عملاً به طرف مقابل میگه که مراحل Handshake با موفقیت انجام شده و از اینجا به بعد ارتباط با کلیدهای Session رمزنگاری میشه.
پس خیلی خلاصه، TLS Handshake سه کار اصلی انجام میده:
🔹 احراز هویت سرور با Certificate
🔹 توافق روی کلیدهای رمزنگاری
🔹 آمادهسازی یک کانال امن برای انتقال داده
در TLS 1.3 این فرآیند نسبت به TLS 1.2 سادهتر و سریعتر شده و معمولاً برای تکمیل Handshake به یک Round Trip نیاز داره.
یعنی وقتی مرورگرت HTTPS رو میبینه، قبل از اینکه اطلاعات حساس رو امن ارسال کنه، یک مذاکره رمزنگاریشده بین Client و Server انجام میشه تا مشخص بشه «با چه الگوریتمی ارتباط برقرار کنیم، سرور واقعاً کیه و کلیدهای رمزنگاری این ارتباط چی باشن.»
@ModernLAN
❤6🆒3
شبکه به زبان ساده!
Photo
سوئیچ برای اینکه بفهمه یک Frame رو باید از کدوم Port خارج کنه، از MAC Address Table یا همون CAM Table استفاده میکنه.
مثلاً فرض کن این شبکه رو داریم:
وقتی PC-A برای PC-B فریم میفرسته، داخل Ethernet Frame یک Destination MAC وجود داره:
سوئیچ این کارها رو انجام میده:
1. یادگیری MACها
وقتی Frame از
یعنی میفهمه MAC مربوط به PC-A روی Port شماره 1 قرار داره.
بعد اگر از Port 2 فریمی با Source MAC مربوط به PC-B وارد بشه:
سوئیچ کمکم یک جدول مثل این میسازه:
2. بررسی Destination MAC
حالا Frame از PC-A وارد میشه:
سوئیچ MAC Table رو نگاه میکنه:
پس Frame رو فقط از Fa0/2 خارج میکنه.
یعنی سوئیچ برخلاف Hub، معمولاً Frame رو برای همه Portها نمیفرسته.
اگر MAC مقصد را نشناسد چی؟
اینجا قضیه جالب میشه.
اگر سوئیچ Destination MAC رو داخل جدولش پیدا نکنه، Frame رو Flood میکنه؛ یعنی از تمام Portهای مربوط به همان VLAN، بهجز پورتی که Frame از آن وارد شده، میفرسته.
مثلاً:
اگر مقصد ناشناخته باشه:
بعد که مقصد پاسخ بده، سوئیچ MAC اون دستگاه رو یاد میگیره و دفعات بعد Frame رو مستقیم به Port درست میفرسته.
یک نکته خیلی مهم
سوئیچ برای تصمیمگیری به Destination MAC نگاه میکنه، ولی برای یادگیری اینکه یک MAC روی کدام Port قرار دارد، به Source MAC فریم نگاه میکنه.
پس خلاصهاش:
و این فرآیند یکی از پایهایترین مفاهیم Ethernet Switching محسوب میشه.
@ModernLan
مثلاً فرض کن این شبکه رو داریم:
PC-A ── Fa0/1 ──┐
│
PC-B ── Fa0/2 ──┤ Switch
│
PC-C ── Fa0/3 ──┘
وقتی PC-A برای PC-B فریم میفرسته، داخل Ethernet Frame یک Destination MAC وجود داره:
Destination MAC: BB:BB:BB:BB:BB:BB
Source MAC: AA:AA:AA:AA:AA:AA
سوئیچ این کارها رو انجام میده:
1. یادگیری MACها
وقتی Frame از
Fa0/1 وارد میشه، سوئیچ به Source MAC نگاه میکنه:AA:AA:AA:AA:AA:AA → Fa0/1
یعنی میفهمه MAC مربوط به PC-A روی Port شماره 1 قرار داره.
بعد اگر از Port 2 فریمی با Source MAC مربوط به PC-B وارد بشه:
BB:BB:BB:BB:BB:BB → Fa0/2
سوئیچ کمکم یک جدول مثل این میسازه:
MAC Address Port
--------------------------------
AA:AA:AA:AA:AA:AA Fa0/1
BB:BB:BB:BB:BB:BB Fa0/2
CC:CC:CC:CC:CC:CC Fa0/3
2. بررسی Destination MAC
حالا Frame از PC-A وارد میشه:
Destination:
BB:BB:BB:BB:BB:BB
سوئیچ MAC Table رو نگاه میکنه:
BB:BB:BB:BB:BB:BB → Fa0/2
پس Frame رو فقط از Fa0/2 خارج میکنه.
یعنی سوئیچ برخلاف Hub، معمولاً Frame رو برای همه Portها نمیفرسته.
اگر MAC مقصد را نشناسد چی؟
اینجا قضیه جالب میشه.
اگر سوئیچ Destination MAC رو داخل جدولش پیدا نکنه، Frame رو Flood میکنه؛ یعنی از تمام Portهای مربوط به همان VLAN، بهجز پورتی که Frame از آن وارد شده، میفرسته.
مثلاً:
PC-A ── Fa0/1 ── Switch
├── Fa0/2 → PC-B
├── Fa0/3 → PC-C
└── Fa0/4 → PC-D
اگر مقصد ناشناخته باشه:
Fa0/1 → Switch
↓
┌────┼────┐
↓ ↓ ↓
Fa0/2 Fa0/3 Fa0/4
بعد که مقصد پاسخ بده، سوئیچ MAC اون دستگاه رو یاد میگیره و دفعات بعد Frame رو مستقیم به Port درست میفرسته.
یک نکته خیلی مهم
سوئیچ برای تصمیمگیری به Destination MAC نگاه میکنه، ولی برای یادگیری اینکه یک MAC روی کدام Port قرار دارد، به Source MAC فریم نگاه میکنه.
پس خلاصهاش:
Source MAC → یادگیری
Destination MAC → تصمیمگیری برای Forward کردن
MAC Table → MAC کجاست؟
Port → Frame از کجا خارج شود؟
و این فرآیند یکی از پایهایترین مفاهیم Ethernet Switching محسوب میشه.
@ModernLan
❤8🔥2👍1
کتاب آموزش فایروال Kerio Control | از صفر تا
پیادهسازی حرفهای.
#KerioControl #Kerio #Firewall #UTM #NetworkSecurity #CyberSecurity #امنیت_شبکه #فایروال #کریو_کنترل #شبکه #Network #NetworkPlus #آموزش_شبکه #امنیت_سایبری #مدیریت_شبکه #ModernLAN
@ModernLan
پیادهسازی حرفهای.
#KerioControl #Kerio #Firewall #UTM #NetworkSecurity #CyberSecurity #امنیت_شبکه #فایروال #کریو_کنترل #شبکه #Network #NetworkPlus #آموزش_شبکه #امنیت_سایبری #مدیریت_شبکه #ModernLAN
@ModernLan
🔥7❤6
شبکه به زبان ساده!
کتاب آموزش فایروال Kerio Control | از صفر تا پیادهسازی حرفهای. #KerioControl #Kerio #Firewall #UTM #NetworkSecurity #CyberSecurity #امنیت_شبکه #فایروال #کریو_کنترل #شبکه #Network #NetworkPlus #آموزش_شبکه #امنیت_سایبری #مدیریت_شبکه #ModernLAN @ModernLan
Kerio.Control.pdf
10.1 MB
Password 🔑 @ModernLan
❤9
شبکه به زبان ساده!
Photo
NAT
معمولاً روی روتر یا فایروالِ مرزی شبکه (Edge/Gateway) انجام میشود؛ یعنی جایی که ترافیک از شبکه داخلی به شبکه خارجی میرود.
مثلاً:
فرض کن PC این درخواست را بفرستد:
وقتی Packet به روتر میرسد، NAT آدرس خصوصی را به آدرس عمومی تبدیل میکند:
روتر هم یک جدول NAT نگه میدارد تا وقتی پاسخ برگشت:
نکته مهم
NAT الزاماً فقط «داخل روتر» نیست؛ میتواند روی Firewall، Router، NAT Gateway یا تجهیزات ISP/CGNAT هم انجام شود.
مثلاً در اینترنت موبایل ممکن است چندین کاربر یک IP عمومی مشترک داشته باشند:
اینجا NAT در سمت ISP انجام میشود، نه لزوماً روی مودم کاربر.
پس بهصورت خلاصه: NAT در نقطهای انجام میشود که دستگاه NATکننده بین دو فضای آدرسدهی قرار گرفته؛ معمولاً Gateway شبکه داخلی ↔ شبکه خارجی.
@ModernLan
معمولاً روی روتر یا فایروالِ مرزی شبکه (Edge/Gateway) انجام میشود؛ یعنی جایی که ترافیک از شبکه داخلی به شبکه خارجی میرود.
مثلاً:
PC
192.168.1.10
│
▼
Switch
│
▼
Router / Firewall
Inside: 192.168.1.1
Outside: 185.x.x.x
│
│ ← NAT اینجا اتفاق میافتد
▼
Internet
فرض کن PC این درخواست را بفرستد:
192.168.1.10:52341
↓
8.8.8.8:443
وقتی Packet به روتر میرسد، NAT آدرس خصوصی را به آدرس عمومی تبدیل میکند:
Before NAT:
192.168.1.10:52341 → 8.8.8.8:443
After NAT:
185.10.20.30:52341 → 8.8.8.8:443
روتر هم یک جدول NAT نگه میدارد تا وقتی پاسخ برگشت:
8.8.8.8:443
↓
185.10.20.30:52341
↓
192.168.1.10:52341
نکته مهم
NAT الزاماً فقط «داخل روتر» نیست؛ میتواند روی Firewall، Router، NAT Gateway یا تجهیزات ISP/CGNAT هم انجام شود.
مثلاً در اینترنت موبایل ممکن است چندین کاربر یک IP عمومی مشترک داشته باشند:
Phone A ─┐
Phone B ─┼──> ISP CGNAT ──> Internet
Phone C ─┘
اینجا NAT در سمت ISP انجام میشود، نه لزوماً روی مودم کاربر.
پس بهصورت خلاصه: NAT در نقطهای انجام میشود که دستگاه NATکننده بین دو فضای آدرسدهی قرار گرفته؛ معمولاً Gateway شبکه داخلی ↔ شبکه خارجی.
@ModernLan
❤6🔥3
This media is not supported in your browser
VIEW IN TELEGRAM
بدون فیبر نوری؟ این لینک مایکروویو چگونه دادهها را ارسال میکند!
🔥6❤5
Forwarded from NetShell
سلام رفقا👋
یه ابزار جدید به اسم netshell-mtu با کمک هوش مصنوعی توسعه دادم🛠️
برای وقتی که MTU سرور یا VPN درست تنظیم نیست و با چیزایی مثل fragmentation، packet loss یا افت پایداری سروکله میزنی.
خودش مسیر رو تست میکنه، بهترین MTU رو پیدا میکنه و حتی برای تونلهایی مثل WireGuard، GRE، VXLAN و… محاسبه رو در نظر میگیره.
یه حالت Autopilot هم داره که بعداً خودش وضعیت رو بررسی و در صورت نیاز MTU رو تنظیم میکنه.
🔗 سورس پروژه:
https://github.com/NetShell-IR/netshell-mtu
#NetShell #Linux #Networking #MTU #VPN #WireGuard
موفق باشید🥰
یه ابزار جدید به اسم netshell-mtu با کمک هوش مصنوعی توسعه دادم
برای وقتی که MTU سرور یا VPN درست تنظیم نیست و با چیزایی مثل fragmentation، packet loss یا افت پایداری سروکله میزنی.
خودش مسیر رو تست میکنه، بهترین MTU رو پیدا میکنه و حتی برای تونلهایی مثل WireGuard، GRE، VXLAN و… محاسبه رو در نظر میگیره.
یه حالت Autopilot هم داره که بعداً خودش وضعیت رو بررسی و در صورت نیاز MTU رو تنظیم میکنه.
https://github.com/NetShell-IR/netshell-mtu
#NetShell #Linux #Networking #MTU #VPN #WireGuard
موفق باشید
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
GitHub - NetShell-IR/netshell-mtu: MTU Optimizer
MTU Optimizer. Contribute to NetShell-IR/netshell-mtu development by creating an account on GitHub.
👍12
شبکه به زبان ساده!
چهار روش اصلی ارسال داده در شبکه؛ Unicast، Broadcast، Multicast و Anycast
Broadcast / Unicast / Multicast / Anycast
در شبکه وقتی یک دستگاه میخواد دادهای رو برای یک یا چند مقصد بفرسته، بسته بر اساس نوع آدرسدهی میتونه به شکل Unicast، Broadcast، Multicast یا Anycast ارسال بشه.
Unicast یعنی ارتباط یک به یک (1→1). فرستنده مشخصاً
یک مقصد رو انتخاب میکنه و بسته فقط برای همون مقصد ارسال میشه. مثلاً وقتی سیستم شما به IP یک Web Server وصل میشه، ترافیک بین کلاینت و همون سرور به صورت Unicast رد و بدل میشه. بیشتر ارتباطات معمول شبکه همین حالت رو دارن.
Broadcast
یعنی یک به همه (1→All). فرستنده بسته رو برای تمام دستگاههای یک Broadcast Domain ارسال میکنه و همه دستگاهها بسته رو دریافت میکنن، حتی اگر برای بعضیها کاربردی نداشته باشه. مثلاً در IPv4 آدرس
Multicast
یعنی یک به چند عضو مشخص (1→Many). اینجا فرستنده بسته رو برای یک گروه خاص میفرسته و فقط دستگاههایی که عضو اون Multicast Group هستن، ترافیک رو دریافت میکنن. مثلاً اگر 100 سیستم داخل شبکه باشن ولی فقط 10 سیستم عضو یک Multicast Group باشن، بسته برای همون 10 سیستم ارسال میشه، نه هر 100 دستگاه. پروتکلهایی مثل IGMP برای مدیریت عضویت کلاینتها در گروههای Multicast استفاده میشن.
Anycast
کمی متفاوتتره و بیشتر در طراحی سرویسهای توزیعشده دیده میشه. چند سرور میتونن یک آدرس مقصد مشترک داشته باشن و شبکه معمولاً بسته رو به یکی از نزدیکترین/مناسبترین مقصدها بر اساس Routing هدایت میکنه. مثلاً در زیرساخت DNS و CDN از Anycast استفاده میشه تا کاربر به یکی از نقاط سرویسدهنده که از نظر مسیر شبکه مناسبتره برسونه. بنابراین Anycast رو میشه به شکل یک به نزدیکترین/مناسبترین عضو (1→Nearest) در نظر گرفت.
خلاصه اگر بخوای خیلی راحت تو ذهنت بمونه:
تفاوت اصلی Multicast و Broadcast اینه که Broadcast به کل Broadcast Domain میره، ولی Multicast فقط به اعضای یک گروه مشخص میرسه؛ در نتیجه Multicast برای توزیع ترافیک به تعداد زیادی گیرنده میتونه بهینهتر باشه.
@ModernLan
در شبکه وقتی یک دستگاه میخواد دادهای رو برای یک یا چند مقصد بفرسته، بسته بر اساس نوع آدرسدهی میتونه به شکل Unicast، Broadcast، Multicast یا Anycast ارسال بشه.
Unicast یعنی ارتباط یک به یک (1→1). فرستنده مشخصاً
یک مقصد رو انتخاب میکنه و بسته فقط برای همون مقصد ارسال میشه. مثلاً وقتی سیستم شما به IP یک Web Server وصل میشه، ترافیک بین کلاینت و همون سرور به صورت Unicast رد و بدل میشه. بیشتر ارتباطات معمول شبکه همین حالت رو دارن.
Broadcast
یعنی یک به همه (1→All). فرستنده بسته رو برای تمام دستگاههای یک Broadcast Domain ارسال میکنه و همه دستگاهها بسته رو دریافت میکنن، حتی اگر برای بعضیها کاربردی نداشته باشه. مثلاً در IPv4 آدرس
255.255.255.255 یک Local Broadcast محسوب میشه. یکی از نمونههای معروفش DHCP Discover هست؛ کلاینت هنوز IP نداره و برای پیدا کردن DHCP Server درخواست رو Broadcast میکنه. نکته مهم اینکه Router معمولاً Broadcast را از یک شبکه به شبکه دیگر Forward نمیکند.Multicast
یعنی یک به چند عضو مشخص (1→Many). اینجا فرستنده بسته رو برای یک گروه خاص میفرسته و فقط دستگاههایی که عضو اون Multicast Group هستن، ترافیک رو دریافت میکنن. مثلاً اگر 100 سیستم داخل شبکه باشن ولی فقط 10 سیستم عضو یک Multicast Group باشن، بسته برای همون 10 سیستم ارسال میشه، نه هر 100 دستگاه. پروتکلهایی مثل IGMP برای مدیریت عضویت کلاینتها در گروههای Multicast استفاده میشن.
Anycast
کمی متفاوتتره و بیشتر در طراحی سرویسهای توزیعشده دیده میشه. چند سرور میتونن یک آدرس مقصد مشترک داشته باشن و شبکه معمولاً بسته رو به یکی از نزدیکترین/مناسبترین مقصدها بر اساس Routing هدایت میکنه. مثلاً در زیرساخت DNS و CDN از Anycast استفاده میشه تا کاربر به یکی از نقاط سرویسدهنده که از نظر مسیر شبکه مناسبتره برسونه. بنابراین Anycast رو میشه به شکل یک به نزدیکترین/مناسبترین عضو (1→Nearest) در نظر گرفت.
خلاصه اگر بخوای خیلی راحت تو ذهنت بمونه:
Unicast → 1 → 1 یک فرستنده → یک مقصد
Broadcast → 1 → All یک فرستنده → همه
Multicast → 1 → Many یک فرستنده → اعضای یک گروه
Anycast → 1 → Nearest یک فرستنده → یکی از چند مقصد مشابه
تفاوت اصلی Multicast و Broadcast اینه که Broadcast به کل Broadcast Domain میره، ولی Multicast فقط به اعضای یک گروه مشخص میرسه؛ در نتیجه Multicast برای توزیع ترافیک به تعداد زیادی گیرنده میتونه بهینهتر باشه.
@ModernLan
🔥6❤4👍1