مبانی شبکه در لینوکس: رابط، IP، مسیر و پورت

بدون مدل ذهنی روشن از «این جعبه چطور به بقیه وصل است»، هر خطای اتصال تبدیل به آزمون و خطای تصادفی می‌شود. لینوکس شبکه را با رابط‌ها (interfaces)، آدرس‌ها، مسیرها (routes) و سوکت‌ها توصیف می‌کند. ابزار مدرن خانوادهٔ `iproute2` است (`ip`، `ss`)؛ `ifconfig` و `netstat` قدیمی‌اند و روی بسیاری از نصب‌های مینیمال اصلاً نیستند.

این مقاله لایه‌های لازم برای کار روزمره روی یک سرور را می‌چیند — نه دورهٔ کامل CCNA.

پاسخ کوتاه

با `ip link` و `ip addr` ببینید کدام رابط بالاست و چه IP دارد. با `ip route` دروازهٔ پیش‌فرض و مسیرها را بخوانید. با `ss -tulpn` ببینید چه سرویسی روی چه پورت و آدرسی listen می‌کند. پیکربندی پایدار روی اوبونتو معمولاً از Netplan می‌آید نه از فرمان‌های موقت `ip`.

فرمان‌های ip تغییرات لحظه‌ای می‌سازند؛ برای ماندگاری بعد از reboot باید منبع پیکربندی توزیع را عوض کنید.

رابط شبکه چیست؟

رابط نقطهٔ اتصال پشتهٔ شبکه به دستگاه است: کارت فیزیکی (`eth0`/`ens*`/`enp*`)، وایرلس، bridge، tunnel، یا `lo` حلقه‌بسته. حالت UP بودن لینک لازم است ولی کافی نیست؛ باید آدرس و مسیر هم درست باشد.

bash

ip link show ip -br link ip addr show ip -br addr

نام‌های پیش‌بینی‌پذیر systemd/udev ممکن است به‌جای eth0 به شکل ens3 یا enp0s3 باشند. در مستند و اسکریپت به‌جای فرض نام ثابت، از مسیر پیکربندی یا MAC استفاده کنید.

آدرس IP، ماسک و چندآدرسی

هر آدرس با پیشوند (CIDR) معنا دارد: `192.0.2.10/24` یعنی میزبان در شبکهٔ 192.0.2.0/24. یک رابط می‌تواند چند آدرس IPv4/IPv6 داشته باشد. `127.0.0.1` فقط روی lo است؛ سرویس اگر فقط روی 127.0.0.1 گوش دهد از بیرون دیده نمی‌شود — اغلب عمدی و درست برای دیتابیس.

مسیریابی: بسته از کجا خارج می‌شود؟

bash

ip route show ip route get 1.1.1.1 ip -6 route show

جدول مسیر می‌گوید برای هر مقصد از کدام رابط و کدام gateway برو. `default via …` مسیر اینترنت/خروجی عمومی است. `ip route get` برای یک مقصد مشخص تصمیم کرنل را نشان می‌دهد — وقتی چند اینترفیس یا policy routing دارید طلایی است.

بدون مسیر درست، حتی با IP صحیح روی کارت، پینگ بیرونی شکست می‌خورد. برعکس، داشتن IP عمومی بدون مسیر برگشت در فایروال/امنیت‌گروه ابر هم «وصل نمی‌شود» را می‌سازد.

سوکت و پورت: ss به‌جای netstat

bash

ss -tulpn ss -tp | head ss -s

• -t TCP، -u UDP، -l فقط listening، -p پروسس (نیاز به مجوز کافی)، -n عددی بدون resolve نام.
• Local Address:Port نشان می‌دهد روی همهٔ آدرس‌ها (`0.0.0.0` یا `[::]`) یا فقط localhost گوش می‌دهد.
• برای دیدن اتصال‌های برقرار، بدون -l نگاه کنید.

فهم listen address جلوی باز کردن تصادفی سرویس روی اینترنت را می‌گیرد و عیب‌یابی «از بیرون نمی‌آید» را سریع می‌کند.

پیکربندی پایدار: Netplan و دیگران

روی اوبونتو سرور، Netplan YAML در `/etc/netplan/` رابط‌ها، DHCP یا IP ثابت، DNS و route را توصیف می‌کند و به backend مثل systemd-networkd می‌دهد. بعد از ویرایش: `netplan try` یا `netplan apply` — با احتیاط روی SSH تا قفل نشوید.

bash

ls /etc/netplan/ sudo netplan get # sudo netplan try # با مهلت بازگشت خودکار در صورت قطعی

توزیع‌های دیگر ممکن است NetworkManager، ifcfg، یا systemd-networkd خام داشته باشند. اصل یکی است: لایهٔ پایدار را بشناسید.

فایروال میزبان در تصویر کلی

حتی اگر سرویس listen کند، ufw/nftables/iptables یا Security Group ابر می‌تواند پکت را دور بیندازد. مبانی شبکه بدون دانستن «کجا فیلتر می‌شود» ناقص است؛ جزئیات عیب‌یابی در مقالهٔ بعدی و چک‌لیست امنیت اوبونتو آمده است.

جدول ابزارها

IPv6 را نادیده نگیرید

بسیاری از سرورها AAAA دارند و کلاینت مدرن اول IPv6 را امتحان می‌کند. اگر IPv6 نیمه‌پیکربندی باشد، تأخیرهای عجیب یا شکست‌های متناوب می‌بینید. یا IPv6 را درست کنید یا آگاهانه در سرویس/DNS مدیریتش کنید — نه با انکار وجودش.

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

• اتکا به ifconfig روی سیستم مینیمال.
• فرض eth0 همیشه نام درست است.
• باز کردن سرویس روی 0.0.0.0 بدون فایروال.
• تغییر IP با ip و تعجب از برگشت بعد از reboot.
• فراموش کردن اینکه Security Group ابر جدا از ufw محلی است.

چه زمانی این پایه کافی است؟

برای یک VM تک‌homed و سرویس‌های ساده، همین مدل کافی است تا وارد عیب‌یابی شوید. برای BGP، anycast، یا mesh پیچیده به مستندات شبکهٔ پیشرفته‌تر نیاز دارید.

مثال پیمایش یک اتصال خروجی

وقتی از سرور به `api.partner.com:443` وصل می‌شوید، کرنل با جدول مسیر مشخص می‌کند بسته از کدام اینترفیس و با کدام آدرس منبع خارج شود، ARP/ND همسایه را برای gateway حل می‌کند، و TCP handshake انجام می‌شود. اگر چند اینترفیس (عمومی و خصوصی) دارید، ممکن است پاسخ از مسیری برگردد که فایروال دوست ندارد — asymmetric routing. `ip route get` و تست از همان منبع به عیب‌یابی کمک می‌کند.

bash

ip route get 203.0.113.50 ss -tnp | rg 203.0.113.50 || true

localhost، socket یونیکس و سرویس‌های داخلی

بسیاری سرویس‌های داخلی بهتر است به‌جای TCP روی localhost، از Unix domain socket استفاده کنند (مثلاً برخی چیدمان‌های PostgreSQL یا PHP-FPM). این سطح حملهٔ شبکه را کم می‌کند. وقتی با ss فقط TCP را می‌بینید، سوکت‌های یونیکس را با `ss -xl` هم بررسی کنید تا تصویر کامل شود.

ابر: IP شناور و metadata

در ابر، آدرس عمومی گاهی روی ۱:۱ NAT است و اینترفیس میزبان فقط IP خصوصی دارد. پینگ «IP عمومی از خود سرور» ممکن است رفتار عجیب داشته باشد. برای فهم صحیح، مستند networking همان ابر را بخوانید و Security Group را بخشی از مدل ذهنی شبکه بدانید نه جزئیات اختیاری.

مدل سه‌جمله‌ای برای تازه‌واردها

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

وقتی سرویس را «باز کردید» و کار نکرد، ترتیب بررسی همان سه جمله است نه بازنویسی کامل کانفیگ. بیشتر حوادث شبکهٔ میزبان در یکی از این سه نقطه خلاصه می‌شوند. ابزارها فقط برای مشاهدهٔ همان نقاط‌اند.

در محیط‌هایی با چند جدول مسیر یا policy routing، تصمیم‌ها پیچیده‌تر می‌شود؛ ولی تا وقتی یک اینترفیس پیش‌فرض دارید، همان مدل کافی است. به‌محض افزودن VPN یا کارت دوم، `ip rule` و جداول اضافه را وارد مدل ذهنی کنید و در مستند شبکهٔ تیم بنویسید.

نام‌گذاری اینترفیس‌ها و برچسب‌های ابری را در موجودی دارایی نگه دارید. وقتی آلارم می‌گوید eth0 down ولی ماشین ens5 دارد، فقط زمان را سوزانده‌اید. موجودی کوچک و به‌روز بخشی از مبانی شبکهٔ عملیاتی است.

از مبانی تا آمادگی عیب‌یابی

اگر فقط یک عادت بعد از این مقاله بسازید، این باشد: قبل از تغییر، خروجی `ip -br addr`، `ip route` و `ss -tulpn` را ذخیره کنید. بعد از تغییر همان سه خروجی را مقایسه کنید. بیشتر regressهای شبکه با همین diff ساده پیدا می‌شوند. ابزار پیچیده وقتی لازم است که این سه تصویر متناقض یا ناکافی باشند.

دومین عادت: هر پورت listen را با یک دلیل در موجودی بنویسید. پورتی که صاحب ندارد باید بسته شود. این کار ساده سطح حمله را بیش از خیلی از تنظیمات مبهم پایین می‌آورد.

سوم: تفاوت پیکربندی موقت و پایدار را در تیم جدی بگیرید. اگر کسی با `ip addr add` آتش را خاموش کرد، همان روز مسیر Netplan/NM را به‌روز کند یا تیکت باز بگذارد. آتش خاموش‌شدهٔ بدون ثبت، هفتهٔ بعد برمی‌گردد.

با این عادت‌ها، مقالهٔ عیب‌یابی شبکه معنی اجرایی پیدا می‌کند و میزبان‌های شما برای چک‌لیست production قابل دفاع می‌شوند.

جمع‌بندی: برگهٔ تقلب دائمی

`ip -br link` برای بالا/پایین بودن کارت، `ip -br addr` برای آدرس، `ip route` برای خروج، `ss -tulpn` برای گوش‌دادن، و فایل Netplan برای ماندگاری. همین پنج مرجع روزانه ۸۰٪ کارهای شبکهٔ میزبان را پوشش می‌دهند. بقیه ابزارها برای ۲۰٪ سخت‌ترند.

وقتی چیزی را عوض می‌کنید، یک جمله در changelog ماشین بنویسید: چه چیزی، چرا، چگونه برگشت. شبکه بدون تاریخچه مثل کابل‌کشی بدون برچسب است — تا روز اول خوب به نظر می‌رسد.

با تسلط روی این مبانی، وارد عیب‌یابی لایه‌لایه شوید و از باز کردن تصادفی پورت به‌عنوان روش «دیباگ» دست بکشید. درک، جای آزمایش و خطا را پر می‌کند.

اتصال مبانی به امنیت و production

دانستن listen address همان نقطهٔ شروع سخت‌سازی است: چیزی که روی localhost گوش می‌دهد نیازی به قانون UFW عمومی ندارد. دانستن مسیر پیش‌فرض به شما می‌گوید ترافیک مدیریتی از کجا می‌آید تا در SG محدودش کنید. مبانی شبکه اگر به تصمیم امنیتی وصل نشوند، فقط فرمان حفظی می‌مانند.

در چک‌لیست production، سه خروجی شبکه را به‌عنوان شاهد روز صفر نگه دارید. وقتی شش ماه بعد کسی پورت جدید باز می‌کند، diff با همان شاهد سریع مشخص می‌کند چه چیز غیرمجاز اضافه شده است.

همین اتصال است که مقالهٔ بعدی عیب‌یابی و چک‌لیست امنیت را برای خوانندهٔ این متن قابل‌استفاده می‌کند.

اگر فردا فقط سه فرمان را به خاطر بسپارید، همان `ip -br addr`، `ip route` و `ss -tulpn` را انتخاب کنید؛ باقی را می‌توان در لحظه از man و مستند Netplan پیدا کرد. شهود پایدار از تکرار همین سه تصویر ساخته می‌شود نه از حفظ همهٔ گزینه‌های iproute2.

خلاصه

شبکهٔ میزبان لینوکس را با چهار سؤال جمع کنید: کدام رابط؟ چه آدرسی؟ کدام مسیر؟ چه پورتی باز است؟ ابزارهای ip و ss جواب می‌دهند؛ Netplan (یا معادل) ماندگاری را. با این پایه، مقالهٔ عیب‌یابی معنی‌دار می‌شود.

سوالات متداول

تفاوت bind به 0.0.0.0 و 127.0.0.1؟

اولی روی همهٔ آدرس‌های IPv4 میزبان گوش می‌دهد؛ دومی فقط محلی. برای سرویس داخلی دومی امن‌تر است اگر دسترسی دور لازم نیست.

چرا ping کار می‌کند ولی سرویس نه؟

ICMP جدا از TCP پورت شماست. فایروال ممکن است ping را اجازه و پورت را نبسته باشد یا برعکس.

ip و nmcli کدام؟

روی سرور اوبونتو اغلب networkd+Netplan؛ روی دسکتاپ NetworkManager. هر دو روی پشتهٔ کرنل یکسان سوارند.

منابع و مراجع

• ip(8) — show / manipulate routing, network devices: https://man7.org/linux/man-pages/man8/ip.8.html
• ss(8) — another utility to investigate sockets: https://man7.org/linux/man-pages/man8/ss.8.html
• Ubuntu Netplan documentation: https://netplan.readthedocs.io/
• Ubuntu Server — Introduction to networking: https://documentation.ubuntu.com/server/explanation/networking/introduction-to-networking/
• Ubuntu Server — About Netplan: https://documentation.ubuntu.com/server/explanation/networking/about-netplan/