სასტუმროების ქსელები და კონფერენციების ფაირვოლები ხშირად აჩვენებენ მორგებულ დაშვების უჯრას, და ვიღაც წერს მასში 47-ს იმ იმედით, რომ PPTP იმუშავებს. წესი იქმნება, გვირაბი მაინც ვერ მუშაობს, და შემდეგი ცდა სხვა ნომერს იყენებს. შეცდომა თავად პაკეტშია: IPv4-ს აქვს პროტოკოლის ველი, რომელიც ასახელებს, რა მოდის IP თავსართის შემდეგ, ხოლო TCP-ს და UDP-ს აქვთ პორტის ველები, რომლებიც მხოლოდ მაშინ არსებობს, როცა ამ თავსართებიდან ერთის შიგნით ხარ. ეს ერთი და იმავე ნებართვის ორი მართლწერა არ არის.

IPv4-ის თავსართი ასახელებს შემდეგ პროტოკოლს

პროტოკოლის ველი IPv4-ის თავსართში ერთი ბაიტია და შეიცავს რიცხვს, რომელიც აღწერს დატვირთვას: 6 TCP-სთვის, 17 UDP-სთვის, 47 GRE-სთვის, 50 ESP-სთვის. ყველაფერი, რაც პაკეტებს ფილტრავს, ამ მნიშვნელობას უფრო ღრმად ყურებამდე კითხულობს, რადგან ღრმა თავსართს აზრი მხოლოდ ტიპის ცნობის შემდეგ აქვს. შეცვალე პორტი საუბრის შემდგომ ნაწილში, და ეს ველი არ გადაადგილდა.

ამიტომ 47-ე პროტოკოლის წინააღმდეგ დაწერილი წესი IP ფენას აღწერს. არც ერთი პორტი არ მონაწილეობს გადაწყვეტილებაში.

პორტები TCP-ისა და UDP-ის შიგნით არსებობს, სხვაგან არსად

პორტები თექვსმეტბიტიანი იდენტიფიკატორებია TCP-ისა და UDP-ის თავსართებში, და მათი ამოცანა ერთ მისამართზე მყოფი საუბრების გამოყოფაა. GRE-ის თავსართი ატარებს პროტოკოლის ტიპის მნიშვნელობას, ხშირად EtherType-ს, დამატებით მრავალჯერადობისთვის არასავალდებულო გასაღებებს. ამიტომ ფრაზა პორტი 47 არ ასახელებს არაფერს, რასაც GRE პაკეტი შეიძლება დაემთხვეს.

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

PPTP ორივე ფენას ერთდროულად იყენებს

PPTP ყველაზე ნათელი მაგალითია, რადგან განზრახ ყოფს თავის საქმეს ორ ფენად. საკონტროლო კავშირი TCP სესიაა 1723 პორტზე, და მონაცემთა გზა GRE-ია, პროტოკოლი 47, არსად რომ არ მონაწილეობდეს პორტი. ფაირვოლი, რომელიც 1723-ს უშვებს და სხვა არაფერს, მოლაპარაკებას დაწყების საშუალებას აძლევს და შემდეგ დატვირთვას ყრის. გვირაბი ავთენტიფიკაციის შემდეგ ჩამოკიდებულად გამოიყურება, ნაცვლად იმისა რომ დაკავშირება ვერ შეძლოს, და ამიტომ სიმპტომს ხშირად პაროლის პრობლემად აცნობენ.

PathOuter protocolPort
Control channelTCP, protocol 61723
Data channelGRE, protocol 47None

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

რატომ ვერ გამოხატავს პორტის გადამისამართების გვერდი GRE-ს

გადამისამართების ფორმა, რომელიც მხოლოდ TCP-ს და UDP-ს იღებს, ვერ აღწერს GRE-ს, როგორც არ უნდა ერქვას ფორმას. მისამართების თარგმნა მეორე სირთულეს ამატებს, რადგან GRE-ს პორტები არ აქვს და მთარგმნელმა ნაცვლად ამისა ზარის იდენტიფიკატორს უნდა მიჰყვეს. ზოგი საყოფაცხოვრებო როუტერი დამხმარესთან ერთად მოდის, რომელიც ამას აგვარებს; ბევრი არა, და არც ერთი დამატებითი TCP ნებართვის ჩანაწერი არ შექმნის ამ ქცევას.

სადაც თანამედროვე გვირაბი ნამდვილი მოთხოვნაა, აირჩიე დიზაინი, რომელიც განზრახ იყენებს TCP-ს ან UDP-ს, იმის იმედის ნაცვლად რომ მთარგმნელი სწორად გამოიცნობს.

ინკაფსულაცია განსაზღვრავს, რას ხედავს ფილტრი

ინკაფსულაცია ცვლის გარე პაკეტს, და წესი სწორედ გარე პაკეტს ემთხვევა. მშობლიური ESP პროტოკოლი 50-ია, ხოლო NAT-ის გავლა ESP-ს UDP 4500-ის შიგნით ახვევს, რათა მან მისამართების თარგმნას გაუძლოს. ფილტრი, რომელიც UDP 4500-ს უშვებს, 50-ე პროტოკოლს არასდროს ხედავს, და 50-ე პროტოკოლისთვის დაწერილი ფილტრი არასდროს ემთხვევა შეფუთულ ფორმას.

იკითხე, რომელ ინკაფსულაციაზე შეთანხმდნენ კლიენტი და კარიბჭე, შემდეგ დაწერე წესი ზუსტად იმ გარე ფორმისთვის და მეტისთვის არა.

დაწერე წესი ისე, რომ ვინმემ შეძლოს მისი შემოწმება

ყოველი წესი გამოხატე როგორც მისამართების ოჯახი, გარე პროტოკოლი, ტრანსპორტის პორტები თუ არის, მიმართულება და ორივე ბოლო წერტილი. მიმომხილველს შეუძლია ეს წინადადება პაკეტების ჩანაწერს შეადაროს და გადაწყვეტილებამდე მივიდეს. 47-ის გახსნის მითითებას ვერავინ შეამოწმებს, და ამიტომ ის წლების განმავლობაში პროცედურების წიგნებში რჩება.

დაამატე ტესტი, რომელიც ამას ამტკიცებს: დაუკავშირდი გარე ინტერფეისზე ჩაწერის დროს, და დაადასტურე გარე პროტოკოლი და პორტი, რომლებიც რეალურად ჩნდება კვალში.

დაკავშირებული სტატიები