فضای آموزشیِ تصویرسازی‌شدهٔ آکادمی ویونیکس با مسیر TCP، بستهٔ بزرگ، پیام ICMP و مراحل تشخیص PMTU، بدون حضور افراد

WIUNIX ACADEMY

تشخیص PMTU black hole و ارسال مجدد TCP در لینوکس

اتصال‌های کند رو با مسیر واقعی، شمارندهٔ socket و probe محدود بررسی کن؛ فرق مشکل اندازهٔ بسته، تلفات شبکه و مرحلهٔ TLS یا برنامه رو با شواهد روشن کن.

پیشرفته35 دقیقه مطالعهبه‌روزرسانی
محیطت رو انتخاب کن

آموزش متناسب با محیط تو

کجا اجرا می‌کنی؟

سیستم‌عامل و نسخهٔ سرورت رو انتخاب کن تا مراحل، دستورها و راه‌حل‌های همون محیط رو ببینی.

Red Hat Enterprise Linux 9بررسی‌شده با مستندات رسمی ·

آموزش متناسب با مقادیر تو

تنظیمات این آموزش

مقادیر نمونه رو با مشخصات سرورت عوض کن تا متن و دستورها با هم تغییر کنن. رمز، کلید خصوصی و توکن اینجا وارد نکن. مقدارها فقط توی همین زبانه می‌مونن و به سرور یا لینک اشتراک‌گذاری فرستاده نمی‌شن. قبل از اجرا، DNS، گواهی‌ها و تنظیمات دسترسی شبکه رو روی سرورت بررسی کن.

اگر آی‌پی، دامنه یا پورت‌های نمونه با سرورت فرق دارن، بخش تنظیمات پایین رو باز کن. مقدارها رو عوض کن و «اعمال در آموزش» رو بزن؛ بعد دستورهای تازه رو کپی کن.

تنظیم مقادیر برای محیط من6 مقدار قابل‌تغییر

از اینجا شروع کن

آخر این آموزش چی خواهیم داشت؟

اتصال‌های کند رو با مسیر واقعی، شمارندهٔ socket و probe محدود بررسی کن؛ فرق مشکل اندازهٔ بسته، تلفات شبکه و مرحلهٔ TLS یا برنامه رو با شواهد روشن کن.

سیستم‌عامل‌ها و نسخه‌های پوشش‌داده‌شده

مسیر ابزارها در Ubuntu 26.10 و LTSهای 26.04/24.04، Debian 13/12، RHEL/Rocky/AlmaLinux 10/9 و Arch/Manjaro غلتان در ۲۰۲۶-۱۱-۰۵ با مستندات بررسی شده. کدها به IPv4 TCP و فضای شبکهٔ کلاینت محدودن؛ شواهد اجرای همهٔ محیط‌ها نیستن.

قبل از شروع

  • دسترسی مجاز به کلاینت درگیر و مقصد مجاز، tuple اتصال و زمان شکست مشخص.
  • ابزارهای بررسی‌شدهٔ توزیع و مجوز جدا برای probe فعال یا مشاهدهٔ محدود بسته؛ در صورت نبود مجوز، همان شاخه رو ادامه نده.
  • نام و آدرس واقعی endpoint عمومیِ بی‌خطر که HEAD و اتصال مستقیم رو مجاز می‌دونه، فقط اگر پنل اختیاری HTTPS رو لازم داری.
  • محل خصوصی برای نگه‌داری آدرس، پورت و خروجی تشخیص؛ رمز و دادهٔ مشتری وارد فرم و فرمان‌ها نمی‌شه.

اتصال برقرار می‌شه، ولی کار جلو نمی‌ره

ممکنه TCP وصل بشه یا ping کوچک جواب بده، اما بستهٔ بزرگ‌تر از مسیر رد نشه. از یک کلاینت درگیر، آدرس IPv4 مقصد، پورت TCP و زمان مشخص شروع می‌کنیم. بعد می‌بینیم واقعاً ارسال مجدد رخ داده، مشکل به اندازهٔ بسته ربط داره یا کار در مرحلهٔ TLS و خود برنامه متوقف شده. هر timeout رو black hole مربوط به PMTU حساب نمی‌کنیم.

مسیر دقیق این آموزش TCP معمولی روی IPv4 و یک کلاینت لینوکسی موجوده. QUIC و HTTP3 از UDP استفاده می‌کنن و IPv6 پیام Packet Too Big و فیلتر متفاوت می‌خواد؛ این پنل‌ها برای اون‌ها نیستن. VPN، کانتینر، پراکسی، NAT و load balancer هم می‌تونن مسیر رو عوض کنن. باید در همون فضای شبکه‌ای باشی که اتصال واقعاً از اون شروع می‌شه.

اول وضعیت socket و رابط رو بدون تغییر تنظیم می‌بینیم. probeهای فعال ICMP و UDP و یک درخواست اختیاری HTTPS از نوع HEAD فقط برای مقصد و زمان مجاز هستن. محتوای خصوصیِ برنامه رو ضبط نمی‌کنیم و فایل packet نمی‌سازیم؛ MTU، MSS، فایروال، offload و تنظیم کرنل هم عوض نمی‌شن.

مقادیر نمونه رو با مسیر واقعی تطبیق بده

فرم مقادیر نمونه رو باز کن و آدرس‌های مخصوص مستندات رو با مقصد مجاز و آدرس مبدأِ از قبل تنظیم‌شده روی همین کلاینت عوض کن. رابط خروجی واقعی رو هم انتخاب کن؛ eth0 رو حدس نزن. نام HTTPS فقط برای بررسی اختیاری HEAD است و باید همین حالا در همون آدرس و پورت گواهی معتبر داشته باشه.

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

01

قدم بعدی

ابزارها رو روی خود کلاینت بررسی کنیم

بسته‌های پایین ابزارهای کلاینت رو فراهم می‌کنن و سروری نصب نمی‌کنن. در DEB و Arch، ابزارهای ip و ss داخل iproute2 هستن؛ نام بسته در خانوادهٔ RPM به‌جاش iproute است. در DEB دو بستهٔ iputils-ping و iputils-tracepath جدا هستن، ولی در خانوادهٔ RHEL و Arch هر دو از iputils میان. نسخهٔ نصب‌شده و راهنمای همون ابزار رو ملاک بگیر، نه یک نسخهٔ فرضیِ مشترک.

بررسی هویت و ابزار چیزی نصب نمی‌کنه. اگر توزیع انتخاب‌شده با میزبان نمی‌خونه، ادامه نده. نبود مجوز ping یا capture یا ندیدن اطلاعات proc و netlink یعنی آماده‌سازی کامل نیست. SELinux، AppArmor و محدودیت capability کانتینر رو نگه دار؛ برای تمرین دسترسی کلی نده و حفاظت میزبان رو خاموش نکن.

از مخزن رسمی همین RHEL با entitlement معتبر یا مخزن رسمی Rocky/Alma در نسخهٔ جزئی پشتیبانی‌شده استفاده کن. SELinux ممکنه مستقل از مجوز عادی، capture رو محدود کنه؛ پیام denial رو با مسئول میزبان بررسی کن و سیاست رو خاموش نکن.

bash

ترمینال مجازِ میزبان کلاینت در همان فضای شبکهٔ درگیر

cat /etc/os-release
uname -r
rpm -q iproute iputils tcpdump curl coreutils
command -v ip ss ping tracepath tcpdump curl timeout date
ip -V
ss -V
ping -V
curl --version
از کجا بفهمم درست انجام شده؟

خانوادهٔ سیستم و نسخهٔ ابزارهای موجود مشخصن؛ قبل از بخش اختیاری مربوط، نبود ابزار یا مجوز رو حل کن.

02

قدم بعدی

اگر ابزاری نیست، در زمان نگه‌داری آماده‌اش کن

اگر ابزارها موجودن، از این پنل رد شو. روی محیط آزمایش یا در زمان مجاز نگه‌داری، تغییرهای پیشنهادی مدیر بسته رو بررسی کن و فقط از مخزن رسمیِ فعال همین توزیع بگیر. مدیر شبکهٔ کلاینت رو جایگزین نمی‌کنیم، daemon ضبط بسته نمی‌سازیم و سرویس تازه‌ای روشن نمی‌کنیم.

مشاهدهٔ بسته در بخش بعدی به دسترسی مدیریتیِ مصوب برای همین کار نیاز داره؛ نصب ابزار به‌تنهایی مجوز ضبط نیست. اگر سیاست میزبان اجازه نمی‌ده، شواهد socket و probe رو نگه دار و از مسئول شبکه بخواه مشاهدهٔ متناظر سمت روتر رو بررسی کنه.

bash

ترمینال مجازِ میزبان کلاینت در همان فضای شبکهٔ درگیر

sudo dnf install iproute iputils tcpdump curl coreutils
command -v ip ss ping tracepath tcpdump curl timeout
از کجا بفهمم درست انجام شده؟

بعد از نصبِ بررسی‌شده، فرمان‌ها موجودن؛ سرویس یا capability دائمیِ ضبط فعال نکردیم.

03

قدم بعدی

مبدأ، رابط و مسیر انتخاب‌شده رو ببینیم

در فضای شبکهٔ همون کلاینت کار کن. ببین 192.0.2.10 واقعاً روی eth0 تنظیم شده و بعد مسیر انتخابی برای 198.51.100.20 و پورت TCP شمارهٔ 443 رو بخون. MTU رابط فقط سقف همون رابط محلیه، نه PMTU کل مسیر. سربار تونل هم می‌تونه اندازهٔ قابل‌استفاده برای بستهٔ داخلش رو کمتر کنه.

خواندن مسیر، بستهٔ آزمایشی نمی‌فرسته و رسیدن به مقصد رو ثابت نمی‌کنه. قانون مسیریابی، mark، پراکسی و توزیع ECMP ممکنه جریان واقعی برنامه رو از این جست‌وجوی ساده متفاوت کنن؛ در بخش بعد tuple خود socket رو مقایسه می‌کنیم. اگر مبدأ یا رابط انتخابی فرق داشت، قبل از probe علتش رو روشن کن.

bash

ترمینال مجازِ میزبان کلاینت در همان فضای شبکهٔ درگیر

ip -4 address show dev 'eth0'
ip link show dev 'eth0'
ip -4 route get '198.51.100.20' from '192.0.2.10' ipproto tcp dport '443'
ip -s link show dev 'eth0'
از کجا بفهمم درست انجام شده؟

آدرس محلی، MTU رابط و مسیر با محدودهٔ خودشون ثبت شدن. خطا یا drop رابط یک مشاهده است، نه درصد تلفات در مسیر دوردست.

04

قدم بعدی

همون اتصال TCP رو در چند لحظه ببینیم

وقتی عملیات مجاز برنامه به مشکل می‌خوره، اتصال موجودش رو می‌بینیم؛ پنل پایین ترافیکی تولید نمی‌کنه. هر اتصال رو با چهار جزء آدرس مبدأ، پورت مبدأ، آدرس مقصد و پورت مقصد می‌شناسیم؛ به این مجموعه tuple می‌گن. این چهار مقدار رو بین نمونه‌ها کامل تطبیق بده تا مربوط به همون اتصال باشن. socket کوتاه‌عمر ممکنه ناپدید بشه و اتصال تازه هم شمارندهٔ تازه داره؛ عدد دو اتصال مختلف رو از هم کم نکن.

اگر کرنل و ابزار نصب‌شده نشون می‌دن، pmtu، mss، RTT و RTO، اطلاعات ارسال مجدد و پیشرفت بایت‌های تأییدشده رو کنار هم بخون. ارسال مجدد می‌تونه از ازدحام، جابه‌جایی ترتیب، گم‌شدن ACK یا افت بستهٔ بزرگ‌تر بیاد. رشد شمارنده فقط ارسال مجدد رو ثابت می‌کنه، نه محل و علت گم‌شدن رو. ستون غایب هم دادهٔ در دسترس‌نبوده است، نه صفر.

bash

ترمینال مجازِ میزبان کلاینت در همان فضای شبکهٔ درگیر

for sample in 1 2 3; do
  date -u +%FT%TZ
  ss -4 -t -i -n 'dst 198.51.100.20 and dport = :443'
  if test "$sample" != 3; then sleep 3; fi
done
از کجا بفهمم درست انجام شده؟

سه مشاهدهٔ زمان‌دار، هویت اتصال و پیشرفت یا شمارنده‌های در دسترس رو نشون می‌دن؛ نبودن یا جایگزین‌شدن socket پنهان نمی‌مونه.

همهٔ آموزش‌های آکادمی ↗