traceroute-ისა და MTR-ის კითხვა საკუთარი თავის მოტყუების გარეშე

აი მოკლე ვერსია, რადგან სწორედ ეს ნაწილი მიჰყავს ხალხს არასწორ დასკვნამდე: პაკეტების დაკარგვა, რომელიც ტრასის შუაში ერთ hop-ზე ჩანს და ბოლო hop-მდე არ გრძელდება, არაფერს ნიშნავს. ეს traceroute-ის ყველაზე გავრცელებული არასწორი წაკითხვაა, უამრავ support ticket-ს ბადებს და იმით არის გამოწვეული, რომ router-ები განზრახ ამცირებენ იმ პასუხების პრიორიტეტს, რომლებზეც traceroute არის დამოკიდებული. მნიშვნელოვანია მხოლოდ დაკარგვა, რომელიც დანიშნულებამდე აღწევს. იგივე ეხება დაყოვნების ნახტომს ერთ hop-ზე, რომელიც ბოლომდე არ გადადის.

მეორე, რაც უნდა იცოდე: traceroute გაჩვენებს ერთ მიმართულებას, და საპასუხო პაკეტები დაბრუნდნენ მარშრუტით, რომელსაც ვერ ხედავ. სწორედ ამიტომ არის სასარგებლო ანგარიში ყოველთვის ორი ტრასა, ერთი თითო ბოლოდან, ერთსა და იმავე დროს გადაღებული. ქვემოთ ყველაფერი ისაა, როგორ მიიღო ისინი, როგორ წაიკითხო და რა გააკეთო პასუხთან - რომელიც ზოგჯერ არის "არაფერი, და აი რატომ".

როგორ მუშაობს traceroute რეალურად#

ყოველ IP პაკეტს აქვს TTL - hop მრიცხველი, რომელსაც IPv6-ში hop limit ჰქვია. ყოველი router, რომელიც პაკეტს გადაამისამართებს, მას ერთით ამცირებს, და router, რომელიც მას ნულამდე დაიყვანს, პაკეტს აგდებს და გამგზავნს უკან ICMP Time Exceeded შეტყობინებას უგზავნის.

Traceroute ამას განზრახ ბოროტად იყენებს. ის აგზავნის probe-ს TTL 1-ით, და პირველი router პასუხობს "time exceeded" - ახლა იცი hop 1. ის აგზავნის კიდევ ერთს TTL 2-ით, და მეორე router პასუხობს. ასე მიდის გარეთ, ნაგულისხმევად სამი probe თითო hop-ზე, სანამ რამე თავად დანიშნულებიდან არ გამოპასუხდება და არა time-exceeded შეტყობინებით.

თავად probe-ები ხელსაწყოს მიხედვით განსხვავდება, და ეს იმაზე მეტად მნიშვნელოვანია, ვიდრე ხალხი ელის:

შედეგი: firewall, რომელიც UDP-ს აგდებს და ICMP-ს უშვებს, აწარმოებს ტრასას, რომელიც ერთ ხელსაწყოთი შუაში კვდება და მეორეთი სრულდება, და არც ერთი შედეგი არაფერს ამბობს იმაზე, გადის თუ არა შენი თამაშის ტრაფიკი. თუ კონკრეტული სერვისი გაინტერესებს, probe გაუშვი იმ პროტოკოლითა და პორტით, რომელსაც ის რეალურად იყენებს.

mtr არის traceroute და ping ერთად. ის გზას ისევ და ისევ გადის და თითო hop-ზე სტატისტიკას ინახავს, რაც ერთადერთი გზაა დაკარგვისა და jitter-ის სანახავად ერთი ნიმუშის ნაცვლად. დიაგნოსტიკისთვის გამოიყენე mtr და დაივიწყე, რომ უბრალო traceroute არსებობს.

ბრძანებები, რომლებიც ღირს ცოდნად#

# The one to use. Report mode, 100 cycles, wide output, ASNs and IPs shown.$ mtr -rwzbc 100 203.0.113.10# Probe the port the game actually uses, so ECMP hashes the same flow.$ mtr -rwzbc 100 -T -P 25565 mc.example.com$ mtr -rwzbc 100 -u -P 27015 cs.example.com# Plain traceroute over TCP to a web port, when ICMP is filtered.$ traceroute -T -p 443 example.com# Fast, numeric, no reverse DNS delays.$ mtr -rwnc 100 203.0.113.10

Windows-ზე დააყენე WinMTR - ის GUI-ა, იგივე საქმეს აკეთებს და უმეტესი ჰოსტი სწორედ მას ითხოვს. ჩაშენებული ხელსაწყოები უფრო სუსტია, მაგრამ მაინც გამოსადეგი:

tracert -d 203.0.113.10pathping -q 100 203.0.113.10

tracert -d გამოტოვებს reverse DNS-ს, რაც შეჩერებებს აქრობს, რომლებიც ხელსაწყოს გაჭედილად აჩვენებს. pathping თითო hop-ზე probe-ების დიდ რაოდენობას აგზავნის და თითო hop-ზე დაკარგვას ბეჭდავს, ამიტომ mtr-ს უფრო უახლოვდება; ის ასევე რამდენიმე წუთს მოითხოვს გრძელ გზაზე, ამიტომ გაუშვი და სხვა საქმეს მიხედე.

გაუშვი მინიმუმ 100 ციკლი. ათ probe-ს არ შეუძლია 0% დაკარგვის გარჩევა 10%-იანისგან რაიმე დარწმუნებით, და ანგარიში, რომელშიც -c 10 წერია, არაფრის მტკიცებულება არ არის.

MTR-ის ანგარიშის კითხვა სვეტ-სვეტ#

$ mtr -rwzbc 100 203.0.113.10Start: 2026-09-21T14:02:11+0200HOST: laptop                    Loss%  Snt  Last   Avg  Best  Wrst StDev 1. AS???     192.168.1.1        0.0%  100   0.6   0.8   0.5   3.1   0.3 2. AS64500   100.64.0.1         0.0%  100   8.9   9.4   8.1  21.0   1.6 3. AS64500   198.51.100.9      12.0%  100   9.8  10.2   8.9  30.4   2.1 4. AS64501   192.0.2.17         0.0%  100  24.1  24.6  23.8  40.2   1.9 5. AS64502   192.0.2.201        0.0%  100  25.0  25.3  24.6  33.1   1.1 6. AS64502   203.0.113.10       0.0%  100  25.2  25.5  24.8  35.0   1.2

ეს ანგარიში ჯანსაღია. Hop 3 აჩვენებს 12% დაკარგვას და მის შემდეგ ყველაფერი არაფერს, რაც არის router, რომელიც საკუთარ პასუხებს ზღუდავს და არა router, რომელიც ტრაფიკს აგდებს. თუ hop 3 მართლა რვა პაკეტიდან ერთს აგდებდა, hop-ები 4, 5 და 6 ვერანაირად ვერ იქნებოდნენ 0%-ზე - მათი probe-ები მასზე გადიან.

წაიკითხე ამ რიგით: ჯერ ბოლო ხაზი დაკარგვისთვის, შემდეგ Avg ბოლო ხაზზე დაყოვნებისთვის, შემდეგ StDev და Best-დან Wrst-მდე სხვაობა ბოლო ხაზზე jitter-ისთვის. მხოლოდ მაშინ, როცა ბოლო ხაზი პრობლემას აჩვენებს, ხდება შუა hop-ები საინტერესო, და მაშინაც მხოლოდ იმის საპოვნელად, საიდან იწყება პრობლემა.

AS ნომრები ამბის მეორე ნახევარია. ისინი გეუბნებიან, ვის ქსელს ეკუთვნის თითო hop, ასე რომ ხედავ, სად გადასცემს შენი ISP ტრაფიკს transit პროვაიდერს და სად გადასცემს ეს პროვაიდერი ჰოსტინგის ქსელს. hop, სადაც AS იცვლება, არის peering წერტილი, და peering წერტილებში ცხოვრობს ჩახშობა რეალურად.

ოთხი რამ, რაც გაუმართაობას ჰგავს და არ არის#

ICMP rate limiting. Time Exceeded პასუხის გენერირება router-ის control პროცესორისთვის სამუშაოა, და დატვირთული core router სიამოვნებით გადაამისამართებს მილიონობით პაკეტს წამში და მხოლოდ რამდენიმე traceroute probe-ს უპასუხებს. ის ისე არის დაკონფიგურირებული, რომ თავი დაიცვას. სიმპტომი: დაკარგვა ან გიჟური დაყოვნება ერთ hop-ზე, მის შემდეგ სუფთა hop-ებით.

Control-plane დაყოვნება. იგივე მიზეზი, განსხვავებული სიმპტომი. Hop აჩვენებს 200 ms-ს, მაშინ როცა დანიშნულება ორი hop-ის შემდეგ 25 ms-ს. router-მა გვიან შექმნა პასუხი პაკეტზე, რომელიც მყისიერად გადაამისამართა. დაყოვნება, რომელიც წინ არ ვრცელდება, დაყოვნება არ არის, რომელიც შენმა ტრაფიკმა განიცადა.

*** * * hop-ზე.** router, რომელიც დაკონფიგურირებულია Time Exceeded შეტყობინებებს საერთოდ არ აგზავნიდეს, ან firewall, რომელიც მათ აგდებს. ძალიან გავრცელებულია ოპერატორების ქსელებში და cloud პროვაიდერების გარშემო. თუ ტრასა მის შემდეგ გრძელდება და სრულდება, hop უხილავია და არა გატეხილი. თუ ტრასა hop-იდან ბოლომდე * * *-ია და არასდროს სრულდება, ეს სხვაა - რაღაც შენს probe-ის ტიპს ბლოკავს, და TCP ტრასა პორტზე, რომელსაც დანიშნულება რეალურად უსმენს, ჩვეულებრივ გაივლის.

კერძო მისამართები და ფანტომური hop-ები. 10.x, 172.16-31.x, 192.168.x და 100.64.0.0/10 დიაპაზონი ტრასაში ნორმალურია - ოპერატორები შიდა ტრანსპორტისთვის კერძო სივრცეს იყენებენ, და 100.64 კონკრეტულად carrier-grade NAT-ია. ცალკე, კლასიკური traceroute ყოველ probe-ზე დანიშნულების პორტს ცვლის, და იქ, სადაც ქსელი რამდენიმე თანაბარ-ღირებულების გზაზე ანაწილებს დატვირთვას, ყოველ probe-ს შეუძლია სხვა გზა აიღოს. ეს ქმნის hop-ებს, რომლებიც ჩნდება და ქრება, და დაკარგვის მაჩვენებლებს, რომლებსაც აზრი არ აქვს. პორტის -P-ით დაფიქსირება ყველა probe-ს ერთ გზაზე ინახავს და შედეგს განმეორებადს ხდის.

კიდევ ორი მცირე: MPLS tunnel-ებს შეუძლიათ მათში მყოფი ყველა router დამალონ, ამიტომ ტრასა შეიძლება ერთი ქალაქიდან მეორეზე ერთ hop-ში გადახტეს დაყოვნების ზრდით, რომელიც შემაშფოთებლად გამოიყურება და უბრალოდ მანძილია; და ტრასა, რომელიც გადაიღეს მარშრუტის ცვლილების შემდეგ ქსელის რეკონვერგენციისას, აჩვენებს მარშრუტის ერთ ნახევარს და შემდეგ მეორეს.

როგორ გამოიყურება ნამდვილი გაუმართაობა#

HOST: laptop                    Loss%  Snt  Last   Avg  Best  Wrst StDev 1. AS???     192.168.1.1        0.0%  100   0.7   0.9   0.5   4.2   0.4 2. AS64500   100.64.0.1         0.0%  100   9.1   9.6   8.2  19.7   1.4 3. AS64500   198.51.100.9       0.0%  100  10.0  10.4   9.1  24.0   1.8 4. AS64501   192.0.2.17         6.0%  100  24.3  38.9  23.9 210.4  31.7 5. AS64502   192.0.2.201        6.0%  100  25.4  40.1  24.7 214.8  32.9 6. AS64502   203.0.113.10       6.0%  100  25.6  40.6  24.9 219.1  33.4

სამი რამ ხდის ამას რეალურად, და სამივე უნდა იყოს, სანამ ხმამაღლა იტყვი:

1. დაკარგვა იწყება ერთ hop-ზე და გრძელდება დაახლოებით იმავე მაჩვენებლით ბოლომდე. 6% hop 4-ზე, 6% ყოველ hop-ზე შემდეგ. Probe-ებს, რომლებიც hop 6-ს აღწევენ, hop 4 უნდა გადაერჩინათ.
2. დაყოვნების გაუარესება რჩება. Avg 10-დან 39-მდე გადახტა hop 4-ზე და იქ დარჩა. შეადარე Best Avg-ს: Best ისევ 24 ms-ია, ამიტომ გზას 24 ms შეუძლია და რაღაც რიგში აყენებს.
3. `StDev` და `Wrst` ერთად ფეთქდება. Best 24-ით და Wrst 210-ით, სტანდარტული გადახრით 32, არის ჩახშობილი არხი და არა გრძელი. წმინდა მანძილი გაძლევს მაღალ Avg-ს დაბალი StDev-ით.

ეს ნიმუში - დაბალი Best, მაღალი Wrst, მაღალი StDev, რომელიც ერთ hop-ზე იწყება - არის ჩახშობა, თითქმის ყოველთვის peering წერტილზე დღის კონკრეტულ დროს. მაღალი Avg მჭიდრო გავრცელებით და დაკარგვის გარეშე არის მანძილი, და მანძილი ფიზიკაა. დაყოვნება, jitter და პაკეტების დაკარგვა არის უფრო მოკლე ვერსია იმისა, თუ რატომ ერევა ეს სამი.

ორივე მიმართულება, რადგან უკან გზა განსხვავებულია#

ინტერნეტის მარშრუტიზაცია ნაგულისხმევად ასიმეტრიულია. მარშრუტს შენგან სერვერამდე შენი ISP და მისი transit პროვაიდერები ირჩევენ; უკან გზას დამოუკიდებლად ირჩევს ჰოსტინგის ქსელი და მისი პროვაიდერები. ისინი ხშირად ერთი და იგივე გზა არ არის, და შეიძლება სრულიად განსხვავებული ჩახშობა ჰქონდეთ.

შენს ტრასაში ყოველი რიცხვი round trip-ია, ამიტომ სუფთად გამოიყურებადი წინა გზა ცუდი რიცხვებით ბოლოში შეიძლება იყოს უკან გზის პრობლემა, რომლის ვერცერთ ნაწილს ვერ ხედავ. მისი დანახვის ერთადერთი გზა არის ტრასა, გაშვებული მეორე ბოლოდან შენსკენ.

უკან ტრასის გასაშვებად სერვერზე shell გჭირდება. VDS-ზე გაქვს, ამიტომ mtr -rwzbc 100 <your-address> სულ ესაა. კონტეინერზე დაფუძნებულ თამაშის ან აპლიკაციის გეგმაზე shell არ გეძლევა - პანელის კონსოლი აპლიკაციის საკუთარი გამოტანა და ბრძანების ხაზია და არა ტერმინალი - ამიტომ სურათის ეს ნახევარი ticket-იდან უნდა მოვიდეს. ჩართე შენი საკუთარი საჯარო მისამართი, თორემ ტრასა გაეშვება არსაიდანაც სასარგებლო არსად.

თუ სახლში CGNAT-ის უკან ხარ, უკან სატრასო მისამართი არ არსებობს, და საპირისპირო მიმართულების ტესტი მანქანიდან უნდა გაკეთდეს, რომელსაც საჯარო მისამართი აქვს. ღირს ამის ცოდნა, სანამ ამაზე საღამოს დახარჯავ.

ტრასის შესაბამისობა იმასთან, რასაც მოთამაშეები იუწყებიან#

ტრასა სასარგებლოა მხოლოდ თუ ის ემთხვევა საჩივარს. სამი შემოწმება, სანამ დასკვნებს გამოიტან:

• Probe გაუშვი სწორ რამეზე. უმეტესი თამაში UDP-ა - TCP თუ UDP გეიმ სერვერებისთვის განიხილავს, რატომ - და გზას, რომელიც ICMP-სთვის სუფთაა, მაინც შეიძლება ჰქონდეს firewall ან rate limit თამაშის პორტის წინ. გააკეთე ტრასა -u -P-ით თამაშის პორტზე, ან -T -P-ით TCP თამაშებისთვის, როგორიცაა Minecraft, და დაადასტურე, რომ პორტი ისაა, რასაც ფიქრობ, გეიმ სერვერის პორტები ახსნილი-ით.
• გამოცადე, როცა ცუდია. 11:00-ზე გადაღებული ტრასა არაფერს გეუბნება ჩახშობაზე, რომელსაც ყველა 21:00-ზე გრძნობს. Peering ჩახშობა საღამოს მოვლენაა. გაუშვი mtr ცუდ ფანჯარაში, რამდენიმე წუთი.
• ჯერ სერვერი გამორიცხე. ლაგი, რომელიც ყველა მოთამაშეს ერთდროულად ეხება, მათი ადგილსამყოფლის მიუხედავად, ჩვეულებრივ ქსელი არ არის. ტრასას შეხებამდე შეამოწმე პანელის CPU და მეხსიერების გრაფიკები და tick rate - სერვერის დატვირთვის გრაფიკის კითხვა და რას ნიშნავს რეალურად tick rate ამ პასუხის უფრო სწრაფი გზაა, ხოლო Minecraft-ისთვის კონკრეტულად - რატომ ეცემა TPS.

ერთი მოთამაშის ლაგი ამ მოთამაშის კავშირია. ყველა მოთამაშის ლაგი სერვერი ან მისი uplink-ია. ერთი ქვეყნის მოთამაშეების ლაგი მარშრუტია.

რა შეგიძლია გააკეთო თითოეულ პასუხზე#

Hop 1 ან 2 ცუდია. ეს შენი საკუთარი ქსელია: wifi, იაფი router, გადატვირთული upload ან სახლში ვინმე სხვა, რომელიც სტრიმინგს აკეთებს. სხვა რამემდე გამოსცადე კაბელით. wifi კავშირი, რომელიც შენს საკუთარ router-მდე 30 ms jitter-ს აჩვენებს, მთელი პრობლემაა და ვერცერთი ჰოსტი ვერ გამოასწორებს.

შენი ISP-ის საკუთარი ქსელი ცუდია. მათი support ჩვეულებრივ MTR-ს არ მიიღებს, მაგრამ მიიღებს "პაკეტების დაკარგვას თქვენს მოწყობილობასა hop 3-ზე და ჩემს კავშირს შორის". იყავი კონკრეტული, ჩართე დროის ნიშნულები დროის სარტყლით და გაიმეორე ტესტი რამდენიმე დღე, რომ ვერ უწოდონ ერთჯერადი.

შუაში transit ქსელი ცუდია. ეს არის პატიოსანი და უკმაყოფილებელი შემთხვევა: არც შენ და არც შენს ჰოსტს ამ ქსელთან ხელშეკრულება არ გაქვთ, და არცერთს არ შეგიძლიათ პირდაპირ მისი შემოვლა. რაც ჰოსტს ზოგჯერ შეუძლია, არის ზემოქმედება იმაზე, საკუთარი transit პროვაიდერებიდან რომელს იყენებს დაბრუნებული ტრაფიკი, და სწორედ ამიტომ სჭირდება ტრასა შენი ბოლოდან. გაგზავნე და მოითმინე.

დანიშნულების ქსელი ცუდია. დაკარგვა, რომელიც ბოლო hop-ზე ან ორზე იწყება, ყველას ეხება და დღეების განმავლობაში გრძელდება. ეს ticket-ს იმსახურებს მტკიცებულებით. RE:NODE-ზე ticket პანელიდან აღწევს მთელ პერსონალს და იღებს კერძო დანართებს, რაც სწორი ადგილია ტრასებისა და screenshot-ებისთვის.

გაითვალისწინე, რას ვერ გეუბნება ტრასა. ის ვერ არჩევს ჩახშობას მიმდინარე შეტევისგან; დიდი მოცულობითი ნაკადები ზემოთ იგდება, ხოლო ტრაფიკი, რომელიც რეალურ მოთამაშეებად არის ფორმირებული, საერთოდ არ ფილტრება - DDoS შეტევები გეიმ სერვერებზე განმარტავს, სად გადის ეს საზღვარი. და ჩვეულებრივი რჩევა "აირჩიე უფრო ახლო ლოკაცია" აქ არ მუშაობს: RE:NODE-ს ერთი ლოკაცია აქვს, გერმანიაში, ჩვენს მიერ მართულ აპარატურაზე. თუ შენი მოთამაშეები ბრაზილიაში არიან, არანაირი კონფიგურაცია არ ცვლის სინათლის სიჩქარეს ატლანტიკაზე, და სწორი პასუხია, ეს იცოდე ყიდვამდე და არა შემდეგ. სად უნდა იცხოვროს შენმა სერვერმა ამ კომპრომისის პატიოსანი ვერსიაა.

ანგარიშის გაგზავნა, რომელზეც რეაგირებენ#

ვინც შენს ticket-ს კითხულობს, შენი დასკვნის გამეორება უნდა და არა შენი შეგრძნებისა. ჩართე:

1. ორივე მიმართულება, თუ შეგიძლია, რამდენიმე წუთის ფარგლებში გადაღებული.
2. მინიმუმ 100 ციკლი, ტექსტად და არა screenshot-ად, რომ ძებნადი და ციტირებადი იყოს.
3. დროის ნიშნულები დროის სარტყლით. mtr report რეჟიმი ბეჭდავს დაწყების დროს. თქვი, როდის ხდება პრობლემა და როდის არა.
4. მისამართი და პორტი, და რომელი პროტოკოლით გამოსცადე.
5. ვისზეა გავლენა: ერთი მოთამაშე, რეგიონი თუ ყველა, და როდიდან.
6. შედარება. სუფთა ტრასა სხვა სერვერზე იმავე ქალაქში ანეგდოტს მტკიცებულებად აქცევს.

რა არ უნდა ჩართო: ერთი tracert ოთხი probe-ით თითო hop-ზე და წითელი წრე შუაში მყოფი hop-ის გარშემო. ეს არის ანგარიში, რომლის თავიდან ასაცილებლადაც ეს მთელი პოსტი არსებობს.

FAQ#

რატომ აჩვენებს ერთი hop 50% დაკარგვას, დანარჩენი კი არაფერს?

ამ hop-ზე router ზღუდავს ICMP პასუხებს, რომლებიც traceroute-ს სჭირდება, რაც ნორმალურია და განზრახულია. ის შენს რეალურ ტრაფიკს კარგად გადაამისამართებს, რასაც ამტკიცებს მის შემდეგ hop-ები, რომლებიც დაკარგვას არ აჩვენებენ. რეალურია მხოლოდ დაკარგვა, რომელიც ბოლო hop-მდე გრძელდება.

traceroute გამოვიყენო თუ MTR?

MTR, ყველაფრისთვის, რაზეც მოქმედებას აპირებ. Traceroute იღებს სამ ნიმუშს თითო hop-ზე, რაც დაკარგვისა და jitter-ის გასაზომად საკმარისი არ არის. MTR გზას განუწყვეტლივ იმეორებს და გაძლევს დაკარგვას, საშუალოს, საუკეთესოს, უარესს და სტანდარტულ გადახრას თითო hop-ზე. WinMTR არის Windows ვერსია.

რამდენი პაკეტი გავგზავნო?

მინიმუმ 100, -c 100-ით. ამაზე ნაკლებზე დაკარგვის პროცენტი ხმაურია. თუ წყვეტილ პრობლემას მისდევ, გაუშვი რამდენიმე წუთი ცუდი პერიოდის განმავლობაში და არა ერთხელ.

რატომ არის დაყოვნება უფრო მაღალი, ვიდრე ping-ი იმავე მისამართზე?

ბოლო hop-ზე არ უნდა იყოს - ის ხაზი ფაქტობრივად ping-ია. თუ შუალედური hop-ები დანიშნულებაზე მაღალ რიცხვებს აჩვენებენ, ეს control-plane დაყოვნებებია პასუხების გენერირებაში და არა დაყოვნებები, რომლებიც შენმა ტრაფიკმა განიცადა. წაიკითხე ბოლო ხაზი.

აჩვენებს ტრასა გზას, რომელსაც ჩემი თამაშის ტრაფიკი გადის?

მხოლოდ თუ probe-ს იმავე პროტოკოლითა და პორტით აგზავნი, და მაშინაც მხოლოდ დაახლოებით. ქსელები დატვირთვას თანაბარ-ღირებულების გზებზე ანაწილებენ მისამართებისა და პორტების hash-ით, ამიტომ განსხვავებული პორტი პოტენციურად განსხვავებული გზაა. გამოიყენე -T ან -u -P-ით, დაყენებული რეალურ პორტზე.

ტრასა შუაში ჩერდება და სერვერს არასდროს აღწევს. სერვერი გათიშულია?

ჩვეულებრივ არა. სადღაც firewall აგდებს შენი probe-ის ტიპს ან პასუხზე უარს ამბობს, მაგრამ რეალურ ტრაფიკს მაინც აგზავნის. სცადე TCP ტრასა პორტზე, რომელსაც სერვერი რეალურად უსმენს. თუ თამაში უკავშირდება, გზა კარგადაა, ტრასა რასაც არ უნდა ამბობდეს.