ping VPN-ის გავლით: რატომ უშვებენ ექოს პასუხის წესები უკანა გზას

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

პაკეტი ცვლის ტიპს და არა პორტს

ექოს მოთხოვნა არის ICMP ტიპი 8, კოდი 0, და ატარებს იდენტიფიკატორსა და მიმდევრობის ნომერს. პასუხი არის ტიპი 0, კოდი 0, იმავე იდენტიფიკატორითა და მიმდევრობით, ხოლო IP ბოლოები შეცვლილია. ეს ველები განსაზღვრულია RFC 792-ით, და სწორედ იდენტიფიკატორი აძლევს გამომგზავნს პასუხების საკუთარ მოთხოვნებთან შესაბამისობის საშუალებას.

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

პაკეტზე სამი კონტექსტი წყვეტს

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

ამ სამ კონტექსტს განსხვავებული წესების ჯაჭვები და განსხვავებული მთვლელები აქვს, და სწორედ მათი ერთად მიჩნევაა მიზეზი იმისა, რომ «firewall ICMP-ს უშვებს» მაინც შეიძლება წარუმატებელი ping გამოიღოს. გარე გვირაბი მეოთხე კონტექსტია: VPN-ის მსმენელის დაშვება ავტომატურად არ უშვებს დეკაპსულირებულ შიდა მოთხოვნას, ხოლო შიდა ნებართვა არაფერს ამბობს იმაზე, მუშაობს თუ არა გარე გვირაბი.

მდგომარეობის მქონე და უმდგომარეობო ფილტრები პასუხს სხვადასხვანაირად ამუშავებენ

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

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

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

თარგმანი იდენტიფიკატორსაც ცვლის

თუ წყაროს თარგმანი განზრახ ხდება, შორეულ ბოლოში არსებული კორტეჟი არ ემთხვევა კლიენტის გაგზავნილს. NAT-ს შეუძლია ICMP მოთხოვნის იდენტიფიკატორი მისამართებთან ერთად თარგმნას, ამიტომ იმის მოთხოვნა, რომ იგივე ნომერი ორივე მხარეს ჩანდეს, ყალბ შეუსაბამობას ქმნის.

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

ნუ შეაერთებთ ICMP შეცდომებს ექოს პოლიტიკაში

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

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

როცა ექოს გაცვლა მუშაობს, ცალკე შეამოწმეთ რეალური აპლიკაცია. წარმატებული ping ადასტურებს ერთი პროტოკოლის ორმხრივ გზას ერთ ზომაში ერთ დანიშნულებამდე, და ეს არ არის ლიცენზია ჩათვალოთ, რომ HTTPS, SMB ან ნებისმიერი სხვა ნაკადი დაშვებულია.