Cisco CCNA · 200-301 v2.0

Local Network، Remote Network و Default Gateway

قبل از ارسال هر Packet، Client باید بفهمد مقصد در شبکه Local خودش است یا باید Packet را به Router بدهد. این تصمیم با IP و Prefix انجام می‌شود و Default Gateway فقط برای مقصدهای Remote وارد مسیر می‌شود. اگر این منطق را درست بفهمی، بسیاری از خطاهای Gateway و Mask بدون حدس قابل تشخیص می‌شوند.

در پایان این درس باید بتوانی
  • Local و Remote Network را بر اساس Prefix تشخیص بدهی
  • نقش Default Gateway را دقیق توضیح بدهی
  • بفهمی Client برای مقصد Local و Remote چه تصمیمی می‌گیرد
  • رابطه ARP و Gateway را در Ethernet دنبال کنی
  • IP و Gateway را در Windows و Cisco IOS بررسی کنی
  • خطای Mask یا Gateway را از روی رفتار Client تشخیص بدهی

Local Network و Remote Network

وقتی Source و Destination با Prefix خودشان در یک Subnet قرار می‌گیرند، مقصد برای Source محلی یا Local است. مثلاً 192.168.10.20/24 و 192.168.10.80/24 هر دو Network Address برابر 192.168.10.0 دارند، پس در یک Local Network هستند. در Ethernet، سیستم برای فرستادن Frame به مقصد محلی باید MAC Address مقصد را پیدا کند. این کار با ARP انجام می‌شود که در درس Switching کامل‌تر بررسی می‌کنیم. فعلاً مهم است بدانی برای مقصد Local، Packet ابتدا به Default Gateway فرستاده نمی‌شود. اگر Network Address مقصد با شبکه Source یکسان نباشد، مقصد Remote است. مثلاً Source برابر 192.168.10.20/24 و Destination برابر 192.168.20.50/24 است. یکی در 192.168.10.0/24 و دیگری در 192.168.20.0/24 قرار دارد. کامپیوتر عادی معمولاً مسیر همه شبکه‌های Remote را جداگانه نمی‌شناسد. برای مقصدهایی که مسیر مشخص‌تری ندارند، از Default Gateway استفاده می‌کند. Client برای هر مقصد باید تصمیم بگیرد آن مقصد داخل شبکه Local خودش است یا در یک شبکه Remote قرار دارد. این تصمیم از مقایسه IP مقصد با IP و Prefix خود Client انجام می‌شود. اگر Network Address مقصد با Network Address خود Client یکی باشد، مقصد Local در نظر گرفته می‌شود و Client تلاش می‌کند مستقیماً در همان شبکه به آن برسد. اگر متفاوت باشد، مقصد Remote است و Packet باید به Router سپرده شود.

به همین دلیل Prefix روی رفتار Client اثر مستقیم دارد. دو سیستم ممکن است IPهایی شبیه هم داشته باشند ولی به دلیل Prefix متفاوت درباره Local بودن یکدیگر تصمیم متفاوت بگیرند. همین وضعیت می‌تواند ارتباط یک‌طرفه و خطاهای عجیب ایجاد کند، چون هر طرف مسیر برگشت را بر اساس Mask خودش می‌سازد.

Default Gateway و تصمیم Client

Default Gateway معمولاً IP یک Router Interface یا Layer 3 Interface داخل همان Subnet کاربر است. سیستم Packet مربوط به مقصد Remote را به این Gateway می‌دهد تا Router تصمیم بعدی را بگیرد.

نمونه تنظیم Client
IP Address:      192.168.10.20
Subnet Mask:     255.255.255.0
Default Gateway: 192.168.10.1

Gateway باید از دید Client داخل همان Local Subnet قابل دسترس باشد. اگر Client برابر 192.168.10.20/24 باشد ولی Gateway را 192.168.20.1 تنظیم کنی، سیستم نمی‌تواند به شکل عادی Frame را مستقیم به آن Gateway برساند چون Gateway در Subnet دیگری است. سیستم برای مقصد 192.168.10.80/24 محاسبه می‌کند که مقصد Local است، پس به دنبال MAC همان مقصد می‌رود. برای مقصد 8.8.8.8، نتیجه Remote است، پس MAC خود 8.8.8.8 را در LAN جست‌وجو نمی‌کند؛ به MAC مربوط به Default Gateway نیاز دارد و Frame را به Gateway می‌فرستد. این تفاوت خیلی مهم است. IP مقصد داخل Packet همان 8.8.8.8 باقی می‌ماند، ولی MAC مقصد Frame در شبکه محلی MAC Gateway است. جزئیات Encapsulation و تغییر Headerها در مسیر در بخش‌های بعدی شبکه باز می‌شود. Default Gateway معمولاً IP یک Interface از Router یا Layer 3 Switch در همان Subnet Client است. وقتی مقصد Remote باشد و Route مشخص‌تری روی Client وجود نداشته باشد، Client Packet را برای Gateway آماده می‌کند. Gateway باید از نظر Layer 3 در شبکه Local خود Client قابل دسترس باشد؛ قرار دادن یک Gateway خارج از Subnet معمولاً Configuration اشتباه است.

Gateway قرار نیست برای ارتباط دو Host داخل یک Subnet استفاده شود. اگر PC1 و PC2 هر دو در 192.168.10.0/24 باشند، ارتباط مستقیم در همان LAN انجام می‌شود و Router وسط مسیر نیست. بنابراین اگر ارتباط داخلی همان Subnet خراب است، تغییر Default Gateway معمولاً اولین اقدام منطقی نیست.

ARP، Route Table و انتخاب مسیر

اگر Default Gateway اشتباه باشد، ممکن است دو سیستم داخل همان Subnet هنوز با هم ارتباط داشته باشند. دلیلش این است که برای مقصد Local به Gateway نیاز ندارند. پس ممکن است کاربر بتواند Printer داخل همان شبکه را Ping کند ولی هیچ شبکه Remote یا اینترنتی را نبیند. این الگو یک سرنخ خوب در Troubleshooting است: Local Connectivity سالم ولی Remote Connectivity خراب می‌تواند توجهت را به Gateway، Routing یا مسیر بالاتر جلب کند. وقتی مقصد Local تشخیص داده شد، سیستم باید Frame Ethernet را به MAC Address همان مقصد بفرستد. اگر MAC را نداند، از ARP برای پرسیدن «چه دستگاهی این IPv4 را دارد؟» استفاده می‌کند. پاسخ ARP باعث می‌شود IP مقصد به MAC آن در شبکه محلی مرتبط شود. برای مقصد Remote، Client دنبال MAC خود مقصد دوردست نمی‌گردد. در عوض MAC Default Gateway را پیدا می‌کند و Frame را به Gateway می‌دهد. این تفاوت بعداً در Switching و Routing چند بار استفاده می‌شود. سیستم‌عامل فقط یک Gateway ساده ندارد؛ یک Routing Table محلی هم نگه می‌دارد. Route مربوط به شبکه مستقیم خودش و Default Route معمولاً در این Table دیده می‌شوند. روی Windows دستور route print و روی Linux دستور ip route می‌تواند آن را نشان دهد.

نمونه ساده Linux
$ ip route
default via 192.168.10.1 dev eth0
192.168.10.0/24 dev eth0

خط دوم می‌گوید شبکه 192.168.10.0/24 مستقیم روی Interface محلی است. خط اول می‌گوید مقصدهای دیگری که Route مشخص ندارند به 192.168.10.1 داده شوند. مفهوم کامل Routing Table در مرحله Routing باز می‌شود. برای ارسال داخل Ethernet، Client به MAC Address مقصد بعدی نیاز دارد. اگر مقصد Local باشد، MAC خود مقصد را با ARP پیدا می‌کند. اگر مقصد Remote باشد، IP مقصد داخل Packet همان مقصد نهایی باقی می‌ماند، اما Frame Ethernet به MAC Address Gateway ارسال می‌شود. این تفاوت مهم است: Router مقصد IP را عوض نمی‌کند فقط چون Gateway است؛ Frame در هر Hop عوض می‌شود ولی IP مقصد تا رسیدن به مقصد نهایی معمولاً ثابت می‌ماند. خود سیستم‌عامل هم Route Table دارد. Route مربوط به شبکه Local از Prefix Interface ساخته می‌شود و Default Route معمولاً به Gateway اشاره می‌کند. بنابراین تصمیم Local/Remote فقط یک مفهوم نظری Cisco نیست؛ Windows، Linux و سایر سیستم‌ها هم قبل از ارسال Packet جدول مسیر خودشان را بررسی می‌کنند.

بررسی Gateway در Windows و Cisco IOS

روی Windows دستور ipconfig اطلاعات پایه IP، Mask و Gateway را نشان می‌دهد. ipconfig /all جزئیات بیشتری مثل DHCP و DNS هم می‌دهد.

نمونه
C:\> ipconfig

IPv4 Address . . . . . : 192.168.10.20
Subnet Mask  . . . . . : 255.255.255.0
Default Gateway  . . . : 192.168.10.1

بعد از دیدن این اطلاعات، اولین کار این است که بررسی کنی Gateway داخل همان Subnet است. بعد می‌توانی خود Gateway را Ping کنی تا ببینی ارتباط Local با آن برقرار است یا نه. روی Router یا Layer 3 Switch، Interface مربوط به Client باید IP متناسب با همان Subnet داشته باشد. مثلاً اگر Gateway کاربران 192.168.10.1 است، Interface مربوط به آن LAN باید همین IP یا IP طراحی‌شده دیگری از همان Subnet را داشته باشد.

نمونه Interface
interface GigabitEthernet0/0
 ip address 192.168.10.1 255.255.255.0
 no shutdown

اگر IP Client و Gateway از نظر Prefix در یک Subnet نباشند، قبل از هر Routing پیچیده‌ای باید همین Addressing اصلاح شود. در Windows با ipconfig /all می‌توانی IP، Subnet Mask و Default Gateway را ببینی. بعد با route print جدول مسیر را بررسی می‌کنی. اگر Gateway خالی است، ممکن است ارتباط Local کار کند ولی مقصدهای Remote در دسترس نباشند. اگر Gateway در Subnet اشتباه است، ابتدا Addressing را اصلاح می‌کنی و بعد سراغ DNS یا Router می‌روی.

بررسی روی Windows
ipconfig /all
route print
ping <default-gateway>

روی Cisco IOS، اگر Interface نقش Gateway شبکه را دارد، show ip interface brief برای دیدن IP و وضعیت Interface مناسب است و Configuration دقیق Mask را در running-config یا show ip interface بررسی می‌کنی. اگر Interface Gateway down باشد، مشکل فقط Client نیست؛ کل Subnet ممکن است دسترسی Remote را از دست بدهد.

خطاهای Prefix و Gateway در عیب‌یابی

اگر Client Gateway را Ping می‌کند، فقط ثابت شده ارتباط Local تا Gateway برقرار است و Gateway پاسخ ICMP داده. هنوز ممکن است Router مسیر اینترنت نداشته باشد، NAT مشکل داشته باشد یا سرویس مقصد در دسترس نباشد. همین محدوده نتیجه‌گیری مهم است. هر تست یک بخش از مسیر را بررسی می‌کند. عیب‌یابی خوب یعنی نتیجه هر تست را بیش از چیزی که ثابت کرده بزرگ نکنی. فرض کن Client A برابر 192.168.10.20/24 و Client B برابر 192.168.10.130/25 است. Client A شبکه را 192.168.10.0/24 می‌بیند و B را Local حساب می‌کند. Client B شبکه خودش را 192.168.10.128/25 می‌بیند و A را Remote حساب می‌کند. همین تفاوت می‌تواند ارتباط نامتقارن و رفتار گیج‌کننده ایجاد کند. وقتی یک سمت ارتباط کار می‌کند و سمت دیگر رفتار متفاوت دارد، Prefixهای دو طرف را با هم مقایسه کن. Addressing ناسازگار همیشه به شکل «همه چیز قطع است» ظاهر نمی‌شود. یک Router می‌تواند چند Interface داشته باشد و هر Interface به یک Subnet متفاوت متصل باشد. برای کاربران هر Subnet، IP همان Interface محلی یا یک Virtual Gateway به‌عنوان Default Gateway استفاده می‌شود. پس یک Gateway واحد با یک IP نمی‌تواند بدون طراحی مناسب برای Subnetهای نامرتبط محلی باشد.

بعداً در Inter-VLAN Routing می‌بینی که یک Switch لایه ۳ یا Router می‌تواند برای چند VLAN Gatewayهای متفاوت داشته باشد. پایه فهم آن همین قانون است: هر Gateway باید در Subnet مربوط به Client قابل دسترس باشد. Ping شدن Gateway فقط بخشی از مسیر را تأیید می‌کند. اگر Client Gateway را Ping می‌کند ولی اینترنت ندارد، ارتباط Client تا Router و مسیر Local احتمالاً کار می‌کند؛ بعد باید Routing بعد از Gateway، NAT، DNS یا ارتباط ISP بررسی شود. برعکس، اگر Gateway در همان Subnet Ping نمی‌شود، رفتن مستقیم سراغ DNS منطقی نیست. Mask اشتباه می‌تواند Client را وادار کند یک مقصد Remote را Local تصور کند. مثلاً Client با /16 ممکن است 192.168.20.10 را Local بداند، در حالی که طراحی واقعی /24 است و مقصد باید از Router عبور کند. Client در این حالت ARP می‌فرستد و Gateway را دور می‌زند. در عیب‌یابی چنین مشکلی، اصلاح Prefix مسئله را حل می‌کند نه اضافه کردن Route روی Router.

سناریوی عملی

Client برابر 10.10.20.50/24 است. Printer برابر 10.10.20.80/24 و Gateway برابر 10.10.30.1 است. Client می‌تواند Printer را ببیند چون هر دو Local هستند، ولی برای Remote Network مشکل خواهد داشت چون Gateway در Subnet 10.10.30.0/24 قرار گرفته و از دید Client Local نیست.

اشتباهات رایج

اشتباه‌های رایج در Gateway

  • برای ارتباط دو Host داخل یک Subnet، Gateway را علت اول ندان
  • Gateway را خارج از Subnet خود Client تنظیم نکن
  • Local و Remote را فقط از روی شباهت ظاهری IP تشخیص نده
  • موفق بودن Ping یک Host محلی را دلیل سالم بودن مسیر اینترنت حساب نکن
تمرین عملی

تمرین Local و Remote

  1. برای 192.168.50.20/26 مشخص کن 192.168.50.40 و 192.168.50.100 Local هستند یا Remote
  2. یک Gateway معتبر برای 192.168.50.20/26 انتخاب کن
  3. روی سیستم خودت ipconfig یا ابزار معادل را اجرا کن و IP/Mask/Gateway را بررسی کن
  4. سناریویی بساز که Local Connectivity کار کند ولی Gateway اشتباه باشد

نکته‌هایی که باید با خودت ببری

  • Local بودن با یکسان بودن Network Address تعیین می‌شود
  • مقصد Remote از طریق Gateway یا Route مناسب دنبال می‌شود
  • Default Gateway باید از دید Client قابل دسترس و معمولاً در همان Subnet باشد
  • Local Connectivity می‌تواند با Gateway اشتباه همچنان کار کند
  • محاسبه Subnet قبل از Troubleshooting Gateway ضروری است
خودسنجی

Local و Remote را تشخیص بده

آیا 192.168.1.10/24 و 192.168.1.200/24 Local هستند؟

بله، هر دو در 192.168.1.0/24 هستند.

Gateway برای 192.168.1.10/24 می‌تواند 192.168.2.1 باشد؟

در طراحی عادی نه؛ Gateway باید در Subnet قابل دسترس همان Client باشد.

اگر Gateway اشتباه باشد، ارتباط با Host محلی ممکن است هنوز کار کند؟

بله، چون مقصد Local به Gateway نیاز ندارد.

منابع رسمی

منابع مرجع این درس

مطالعه همیشه آزاد است

برای ذخیره پیشرفت وارد حساب شو

حساب کاربری برای آزمون و ثبت مرحله‌ها استفاده می‌شود

ورود یا ثبت‌نام