TCP Traceroute روشی برای بررسی مسیر شبکه تا یک Destination با استفاده از TCP Probe است. این روش زمانی کاربرد دارد که traceroute یا tracert معمولی به دلیل Firewall یا Filtering نتیجه کاملی نمایش نمی‌دهد، در حالی که سرویس TCP موردنظر مانند HTTPS، SSH یا SMTP در دسترس است.

برای مثال ممکن است:

ping example.com

یا:

tracert example.com

در بخشی از مسیر Timeout شود، اما اتصال به:

TCP/443

برقرار باشد.

در چنین شرایطی می‌توان Trace را با TCP SYN روی همان Port سرویس انجام داد تا مسیر از دید Traffic مشابه Application بررسی شود.

در این مقاله روش اجرای TCP Traceroute در Linux و Windows، انتخاب Port مناسب و تفسیر نتیجه را بررسی می‌کنیم.

TCP Traceroute چگونه کار می‌کند؟

Traceroute با مقدار کم:

TTL

یا:

Time To Live

شروع می‌کند. این میزان نشان دهنده تعداد دفعاتی است که این packet می‌تواند بین routerهای درون مسیر جا به جا شود.

برای Probe اول:

TTL = 1

قرار داده می‌شود.

اولین Router مقدار TTL را صفر کرده و معمولاً پیام:

ICMP Time Exceeded

برمی‌گرداند.

Probe بعدی:

TTL = 2

دارد و به Router بعدی می‌رسد.

این روند ادامه پیدا می‌کند تا Destination نهایی شناسایی شود.

در TCP Traceroute به‌جای UDP یا ICMP Echo، شناساگر(probe)ها به شکل TCP Packet و معمولاً با Flag زیر ارسال می‌شوند:

SYN

نسخه Linux ابزار traceroute این روش را با -T ارائه می‌کند و از یک Destination Port ثابت استفاده می‌کند.

در مسیر ارتباطی TCP مقدار SYN بخش از اولین مراحل برقراری ارتباط و جزو TCP handshake محصوب می‌شود. این ارتباط بر خلاف ICMP Echo که در ping استفاده می‌شود در تمامی سرورهایی که از این پروتوکول استفاده می‌کنند باز است و محدود نمی‌شود.

تفاوت Traceroute معمولی با TCP Traceroute

Microsoft تأیید می‌کند که tracert داخلی Windows از ICMP Echo Request با TTL افزایشی استفاده می‌کند؛ بنابراین tracert یک TCP Traceroute واقعی نیست.

برای آموزش خود tracert می‌توانید مقاله بررسی دستور tracert در ویندوز را مطالعه کنید.

چرا TCP Traceroute کاربردی است؟

فرض کنید Website روی:

TCP/443

فعال است.

ممکن است Router یا Firewall در مسیر:

ICMP Echo

یا UDP Probeهای معمول Traceroute را محدود کند، اما Traffic مربوط به:

TCP/443

را عبور دهد.

Linux traceroute نیز TCP Mode را روشی برای عبور از Filterهایی معرفی می‌کند که ICMP یا UDP Traceroute را مسدود می‌کنند و توصیه می‌کند Port مرتبط با سرویس واقعی انتخاب شود.

برای مثال برای Mail Server:

TCP/25

و برای HTTPS:

TCP/443

انتخاب منطقی‌تری است.

نکته مهم درباره ICMP

TCP Traceroute به این معنی نیست که دیگر هیچ ICMPی در فرآیند وجود ندارد.

Routerهای میانه مسیر معمولاً همچنان برای TTL تمام‌شده پیام:

ICMP Time Exceeded

برمی‌گردانند.

تفاوت اصلی در Probe ارسال‌شده است که به‌جای ICMP Echo یا UDP، یک TCP Packet است.

بنابراین اگر یک Router تمام ICMP Time Exceededها را Drop کند، ممکن است حتی در TCP Traceroute نیز آن Hop با:

*

نمایش داده شود.

اجرای TCP Traceroute در Linux

در Linux ابزار استاندارد traceroute از TCP Mode پشتیبانی می‌کند.

ابتدا بررسی کنید نصب باشد:

traceroute --version

در صورتی که package نصب باشد این پیام برای شما نمایش داده خواهد شد:

در Ubuntu و Debian:

sudo apt update
sudo apt install traceroute

در AlmaLinux، Rocky Linux و سایر سیستم‌های مبتنی بر RHEL:

sudo dnf install traceroute

ساده‌ترین TCP Traceroute در Linux

Syntax اصلی:

traceroute -T -p PORT DESTINATION

برای مثال برای HTTPS:

sudo traceroute -T -p 443 example.com

در این دستور:

-T

به معنی استفاده از TCP Probe و:

-p 443

به معنی استفاده از Destination Port 443 است.

در TCP Mode، traceroute به‌صورت پیش‌فرض TCP SYN ارسال می‌کند و اگر Port مشخص نشود، Port پیش‌فرض TCP Trace برابر 80 است.

به عنوان نمونه به این مورد توجه کنید؛ در سمت راست تصویر دو مورد دسترسی به سایت trace-test.nix.vm (این سایت یک مورد تست است و وجود ندارد) ابتدا از طریق tracerout معمولی و سپس از طریق ping مسدود شده است. در حالی که در بخش سمت چپ با استفاده از tcp tracerout می‌توان به سرور مقصد دسترسی پیدا کرد.

در تنظیمات سرور این سایت دسترسی به ping و رنج‌های بالای UDP که مربوط به traceroute معمولی است مسدود است. ولی وبسایت از طریق port 443 ارائه می‌شود و از این رو امکان tcp tracerout بر روی آن وجود دارد.

مثال برای سرویس‌های مختلف

HTTPS

sudo traceroute -T -p 443 example.com

HTTP

sudo traceroute -T -p 80 example.com

SSH

sudo traceroute -T -p 22 server.example.com

SMTP

sudo traceroute -T -p 25 mail.example.com

cPanel

در صورتی که Panel روی Port پیش‌فرض باشد:

sudo traceroute -T -p 2083 server.example.com

هدف این است که Probe تا حد ممکن مشابه Connection واقعی‌ای باشد که در حال Troubleshooting آن هستید.

استفاده از IP به‌جای Domain

اگر احتمال می‌دهید DNS مشکل داشته باشد، ابتدا TCP Trace را مستقیماً به IP اجرا کنید:

sudo traceroute -T -p 443 192.0.2.10

اگر Trace به IP کار می‌کند اما Domain به IP مورد انتظار Resolve نمی‌شود، مشکل می‌تواند مربوط به DNS باشد.

عکس زیر مورد مشابه تست مقایسه قبلی است که به آدرس دامنه انجام شده بود ولی این بار با IP:

برای بررسی DNS می‌توانید از مقالات زیر استفاده کنید:

• آموزش کامل dig
• آموزش کامل nslookup
• عیب‌یابی تفاوت نتیجه DNS بین سرور و کامپیوتر شخصی

غیرفعال کردن Reverse DNS Lookup

برای سریع‌تر شدن نتیجه می‌توان گزینه:

-n

را استفاده کرد:

sudo traceroute -n -T -p 443 example.com

در این حالت IP مربوط به Hopها مستقیماً نمایش داده می‌شود و traceroute برای تبدیل آن‌ها به Hostname منتظر DNS نمی‌ماند.

این گزینه برای Troubleshooting اولیه معمولاً مناسب است.

همان طور که در ویدیو نیز مشخص است سرعت این دو مورد باهم متفاوت است. در صورتی که hopهای بین مسیر بیشتر هم باشند تاثیر این افزایش سرعت بیشتر خواهد بود.

تعیین حداکثر تعداد Hop

گزینه:

-m

حداکثر TTL یا تعداد Hop را مشخص می‌کند.

برای مثال:

sudo traceroute -T -p 443 -m 20 example.com

مقدار پیش‌فرض در traceroute برابر:

30

Hop است.

کاهش تعداد Probeها

به‌صورت معمول چند Probe برای هر Hop ارسال می‌شود.

برای ارسال فقط یک Probe در هر Hop:

sudo traceroute -T -p 443 -q 1 example.com

گزینه:

-q

تعداد Probeهای هر Hop را مشخص می‌کند. مقدار پیش‌فرض 3 است.

این گزینه برای اجرای سریع‌تر Trace یا کاهش تعداد Packetها مفید است.

نمونه خروجی

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

traceroute to example.com (203.0.113.20), 30 hops max

 1  192.168.1.1       0.8 ms
 2  10.10.20.1        2.4 ms
 3  198.51.100.1      8.1 ms
 4  * * *
 5  198.51.100.45     25.6 ms
 6  203.0.113.20      31.2 ms

هر خط یک:

Hop

در مسیر است.

عدد:

31.2 ms

زمان Round Trip(مسیر رفت و برگشت) مربوط به همان Probe را نشان می‌دهد.

علامت * در TCP Traceroute چه معنی دارد؟

مشاهده:

* * *

به معنی اثبات Packet Loss نیست.

ممکن است Router:

• ICMP Time Exceeded ارسال نکند.
• پاسخ‌های ICMP را Rate Limit کند.
• پاسخ Traceroute را Filter کند.
• برای Traffic عبوری پاسخ دهد اما خودش به Probe پاسخ ندهد.

برای مثال:

اگر Hopهای بعدی پاسخ می‌دهند، Hop شماره 11 واضحاً Traffic را Forward کرده است.

بنابراین نباید صرفاً وجود * در یک Hop را Packet Loss واقعی در نظر گرفت.

برای تشخیص صحیح Packet Loss مقاله تشخیص Packet Loss واقعی را مطالعه کنید.

استفاده از tcptraceroute در Linux

ابزار دیگری با نام:

tcptraceroute

نیز برای همین هدف وجود دارد.

Syntax معمول:

sudo tcptraceroute example.com 443

یا برای SSH:

sudo tcptraceroute server.example.com 22

این ابزار به‌صورت پیش‌فرض TCP SYN Probe ارسال می‌کند و امکان تعیین Maximum TTL، Timeout و تعداد Probeها را نیز دارد.

با این حال، روی بسیاری از Serverها همان:

traceroute -T

کافی است و نیاز به ابزار جداگانه ندارید.

در صورت علاقه می‌توانید مستندات tcptracerout را در این صفحه مطالعه کنید.

TCP Traceroute در Windows

یک نکته مهم این است که Command داخلی:

tracert

در Windows TCP Probe ارسال نمی‌کند.

برای مثال:

tracert example.com

از ICMP Echo Request استفاده می‌کند.

بنابراین برای یک TCP Traceroute واقعی در Windows نیاز به ابزار دیگری داریم.

یکی از گزینه‌های مناسب Nping است که همراه Nmap ارائه می‌شود و روی Windows، Linux و macOS قابلیت Route Tracing با TCP را دارد.

نصب Nping در Windows

Nping همراه Installer رسمی Nmap قابل نصب است.

Nmap برای Windows Installer رسمی ارائه می‌کند و در فایل نصبی، Nping و Npcap نیز جزو Componentهای قابل نصب هستند. Npcap برای بعضی قابلیت‌های Raw Packet در Nmap/Nping موردنیاز است.

اگر Nmap روی سیستم نصب شده است، ابتدا بررسی کنید:

nping --version

اگر Command شناسایی نشد، ممکن است Directory مربوط به Nmap در:

PATH

نباشد.

مسیر معمول نصب می‌تواند مشابه زیر باشد:

C:\Program Files (x86)\Nmap\

یا بسته به نسخه و نصب سیستم مسیر دیگری باشد.

برای نصب جدیدترین نسخه می‌توانید از لینک نصب نسخ ویندوز از سایت رسمی nmap استفاده فرمائید.

برای آموزش Nmap می‌توانید مقاله آموزش کامل nmap را مطالعه کنید.

اجرای TCP ping با Nping در Windows

Command Prompt یا PowerShell را با Administrator Permission باز کنید.

برای ping روی HTTPS:

nping --tcp --flags syn --traceroute -p 443 example.com

برای SSH:

nping --tcp --flags syn --traceroute -p 22 server.example.com

و برای SMTP:

nping --tcp --flags syn --traceroute -p 25 mail.example.com

همان طور که مشاهده می‌کنید در بررسی اول هیچ یک از ابزارهای عادی ping و tracert در ویندوز در صورت مسدود بودن ping بر روی سرور نمی‌توانند به آن متصل شوند.

در صورتی که بررسی همین ip با tcp ping نتیجه متفاوتی در بر خواهد داشت:

روش TCP tracerout در Windows: استفاده از Nmap

در Windows علاوه بر Nping می‌توان از Nmap نیز برای بررسی مسیر TCP استفاده کرد.

Nping بیشتر خروجی Packet-oriented نمایش می‌دهد و معمولاً نتیجه به شکل:

SENT
RCVD

دیده می‌شود. این خروجی برای بررسی دقیق Packetها مفید است، اما برای مشاهده مسیر به شکل جدول Hopها همیشه خواناترین گزینه نیست.

در مقابل، Nmap با گزینه:

--traceroute

می‌تواند نتیجه مسیر را به شکل واضح‌تری شامل:

HOP
RTT
ADDRESS

نمایش دهد.

بنابراین می‌توان از هر دو ابزار استفاده کرد:

اجرای TCP Traceroute با Nmap

PowerShell یا Command Prompt را با Administrator Permission باز کنید و اجرا کنید:

nmap -Pn -n -sS -p 443 --traceroute example.com

پارامترهای مهم:

خروجی مشابه تصویر زیر خواهد بود:

بخش مهم خروجی عبارت است از:

TRACEROUTE (using port 443/tcp)

که مشخص می‌کند Nmap برای Trace از TCP Port موردنظر استفاده کرده است.

برای سرویس‌های دیگر نیز می‌توان Port را تغییر داد.

SSH:

nmap -Pn -n -sS -p 22 --traceroute server.example.com

SMTP:

nmap -Pn -n -sS -p 25 --traceroute mail.example.com

RDP:

nmap -Pn -n -sS -p 3389 --traceroute server.example.com

در Troubleshooting بهتر است همان Port مربوط به سرویسی انتخاب شود که در حال بررسی آن هستید.

چرا Test-NetConnection -TraceRoute جایگزین TCP Traceroute نیست؟

در PowerShell می‌توان اجرا کرد:

Test-NetConnection example.com -TraceRoute

اما این Mode همان Traceroute مبتنی بر ICMP است.

همچنین:

Test-NetConnection example.com -Port 443

فقط TCP Connectivity به Port 443 را بررسی می‌کند.

در مستندات مایکروسافت، -Port و -TraceRoute در Parameter Setهای جداگانه قرار دارند؛ بنابراین Test-NetConnection به‌صورت Built-in مسیر TCP تا یک Port خاص را Trace نمی‌کند.

برای تست سریع خود Port، این Command بسیار مناسب است:

Test-NetConnection example.com -Port 443

اما برای دیدن Hopهای مسیر TCP از Nping یا ابزار مشابه استفاده کنید.

قبل از TCP Traceroute، خود Port را تست کنید

بهتر است ابتدا مشخص شود Port مقصد واقعاً قابل دسترسی است یا خیر.

در Linux می‌توانید از nc استفاده کنید:

nc -vz example.com 443

برای آموزش کامل ابزار می‌توانید مقاله آموزش کامل nc (NetCat) را مطالعه کنید.

در Windows:

Test-NetConnection example.com -Port 443

را اجرا کنید.

اگر خود TCP Connection برقرار نمی‌شود، TCP Traceroute می‌تواند برای بررسی مسیر و محدوده احتمالی Filtering مفید باشد.

انتخاب Port مناسب اهمیت دارد

برای Troubleshooting بهتر، همان Port سرویس واقعی را Trace کنید.

برای مثال اگر مشکل فقط روی HTTPS وجود دارد، نتیجه:

traceroute -T -p 443 example.com

ارزش بیشتری از Trace روی Port 80 دارد.

Firewall و Routing Policy ممکن است برای Portهای مختلف رفتار متفاوتی داشته باشند.

مقایسه TCP Trace با Traceroute معمولی

یکی از مفیدترین روش‌های Troubleshooting این است که دو Trace را مقایسه کنیم.

در Linux:

traceroute example.com

و:

sudo traceroute -T -p 443 example.com

در Windows:

tracert example.com

و:

nping --tcp --flags syn --traceroute -p 443 example.com

اگر Trace معمولی در یک نقطه متوقف می‌شود اما TCP Trace روی Port سرویس ادامه پیدا می‌کند، احتمالاً Filtering رفتار متفاوتی برای Protocolها یا Portهای مختلف دارد.

اما این موضوع به‌تنهایی محل قطعی مشکل را ثابت نمی‌کند.

تفاوت مسیر TCP و ICMP

در اینترنت همیشه تضمین نمی‌شود تمام Packetها دقیقاً یک Route یکسان داشته باشند.

مواردی مانند:

ECMP
Load Balancing
Policy-based Routing
Firewall Policy
Anycast

می‌توانند باعث شوند Trafficهای مختلف مسیر متفاوتی داشته باشند.

به همین دلیل TCP Traceroute روی Port سرویس موردنظر می‌تواند تصویر مرتبط‌تری از مسیر Application ارائه دهد.

همچنین اجرای Trace در زمان‌های مختلف ممکن است Hopهای متفاوتی نشان دهد.

چگونه نتیجه TCP Traceroute را تحلیل کنیم؟

فرض کنید خروجی به این شکل است:

1   192.168.1.1       1 ms
2   10.20.0.1         5 ms
3   198.51.100.10    20 ms
4   *                 *
5   *                 *
6   203.0.113.20     55 ms

وجود Timeout در Hopهای 4 و 5 لزوماً مشکل نیست؛ چون Destination در Hop 6 پاسخ داده است.

اما اگر:

1   192.168.1.1
2   10.20.0.1
3   198.51.100.10
4   * * *
5   * * *
...
30  * * *

و Destination نیز هرگز دیده نمی‌شود، باید بررسی بیشتری انجام شود.

احتمال‌ها شامل:

• Firewall Filtering
• Routing Problem
• Port Filtering
• Destination Down
• Asymmetric Routing
• عدم پاسخ ICMP از مسیر

است.

برای نتیجه‌گیری بهتر TCP Traceroute را همراه ابزارهای دیگر استفاده کنید.

TCP Traceroute به‌تنهایی Packet Loss را ثابت نمی‌کند

Traceroute ابزار اصلی اندازه‌گیری Packet Loss نیست.

Routerها معمولاً Traffic عبوری را با Priority متفاوتی نسبت به Packetهایی که خود Router باید به آن‌ها پاسخ دهد پردازش می‌کنند.

در نتیجه ممکن است Hopی:

60% timeout

نشان دهد اما تمام Traffic اصلی را بدون Loss عبور دهد.

برای بررسی Packet Loss طولانی‌مدت بهتر است از ابزارهایی مانند:

mtr
WinMTR

استفاده شود.

مقاله Linux:

بررسی دستور mtr در لینوکس

و در windows:

آموزش کامل WinMTR؛ بررسی Packet Loss و Latency در شبکه ویندوز

نکته درباره Firewall مقصد

اگر Port انتخاب‌شده توسط Firewall مقصد Drop شود، ممکن است Trace نتواند Final Hop را به شکل مورد انتظار نشان دهد.

به همین دلیل بهتر است Portی انتخاب شود که واقعاً روی Destination استفاده می‌شود.

قبل از Trace:

nc -vz example.com 443

یا در Windows:

Test-NetConnection example.com -Port 443

می‌تواند وضعیت Connection را مشخص کند.

بررسی IPv4 و IPv6

اگر Domain هم A Record و هم AAAA Record داشته باشد، ابتدا مشخص کنید مشکل مربوط به کدام Stack است.

در Linux می‌توانید IPv4 را Force کنید:

sudo traceroute -4 -T -p 443 example.com

و برای IPv6:

sudo traceroute -6 -T -p 443 example.com

traceroute از -4 و -6 برای انتخاب صریح IPv4 یا IPv6 پشتیبانی می‌کند.

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

Workflow پیشنهادی برای Troubleshooting

اگر کاربر گزارش می‌دهد اتصال به یک سرویس کند یا قطع است، می‌توان از ترتیب زیر استفاده کرد:

1. Resolve DNS
        ↓
2. Check destination IP
        ↓
3. Test TCP port
        ↓
4. Run normal traceroute/tracert
        ↓
5. Run TCP Traceroute on service port
        ↓
6. Compare the paths
        ↓
7. Run MTR / WinMTR if packet loss is suspected

برای مثال برای HTTPS:

Linux

dig example.com
nc -vz example.com 443
traceroute example.com
sudo traceroute -T -p 443 example.com

Windows

nslookup example.com
Test-NetConnection example.com -Port 443
tracert example.com
nping --tcp --flags syn --traceroute -p 443 example.com

این مجموعه اطلاعات بسیار بیشتری نسبت به یک ping ساده در اختیار Administrator قرار می‌دهد.

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

TCP Traceroute را همان tracert در نظر می‌گیریم

tracert در Windows از ICMP استفاده می‌کند و TCP Port مشخصی را Trace نمی‌کند.

Port نامرتبط انتخاب می‌کنیم

اگر مشکل HTTPS است، Port 443 را Trace کنید.

وجود * را Packet Loss قطعی می‌دانیم

یک Router می‌تواند به Probe پاسخ ندهد اما Traffic را کاملاً Forward کند.

فقط یک Trace می‌گیریم

برای مشکل‌های Intermittent بهتر است Trace در زمان مشکل و زمان Normal مقایسه شود.

نتیجه TCP Traceroute را مدرک قطعی محل مشکل می‌دانیم

Route می‌تواند Asymmetric یا Load-balanced باشد. Traceroute یک Diagnostic Evidence است، نه اثبات کامل اینکه همان Hop خراب است.

دستورات سریع

مطالعه بیشتر

مقالات مرتبط در دانشنامه:

• بررسی دستور tracert در ویندوز
• بررسی دستور mtr در لینوکس
• آموزش کامل nc (NetCat)
• آموزش کامل nmap
• تشخیص Packet Loss واقعی
• آموزش کامل WinMTR؛ بررسی Packet Loss و Latency در شبکه ویندوز

مستندات فنی:

• Linux traceroute manual
• Microsoft tracert documentation
• Nping Reference Guide
• Nmap installation

جمع‌بندی

TCP Traceroute زمانی کاربرد دارد که بخواهیم Route را با Probeهای TCP و روی Port واقعی سرویس بررسی کنیم.

در Linux ساده‌ترین روش:

sudo traceroute -T -p 443 example.com

است. گزینه -T TCP SYN Probe را فعال می‌کند و -p Destination Port را مشخص می‌کند.

در Windows، tracert داخلی از ICMP استفاده می‌کند و TCP Traceroute واقعی نیست. برای TCP Trace می‌توان از nmap استفاده کرد:

nmap -Pn -n -sS -p 443 --traceroute example.com

Nmap از TCP Traceroute پشتیبانی می‌کند و روی Windows نیز همراه Nmap قابل نصب است.

برای Troubleshooting عملی بهتر است TCP Traceroute همراه با DNS Check، تست Port، tracert یا traceroute معمولی و در صورت نیاز MTR/WinMTR استفاده شود. همچنین مشاهده * یا Timeout در یک Hop به‌تنهایی اثبات Packet Loss یا خرابی همان Router نیست.