DNS-ის ჩავარდნა თუ MTU-ის პრობლემა? სად ჩერდება მოთხოვნა სინამდვილში
სახელი, რომელიც არასდროს იხსნება, მარცხდება ნებისმიერ კავშირამდე; MTU-ის შეჩერება ხელის ჩამორთმევის შემდეგ იწყება. ჯერ ეტაპი იპოვეთ, შემდეგ ერთი შრე შეცვალეთ და ხელახლა შეამოწმეთ.
ორი ჩავარდნა მომხმარებლისგან ერთსა და იმავე წინადადებას იღებს: საიტი არ მუშაობს. ისინი სხვადასხვა შრეზე ხდება და ეს განსხვავება წყვეტს, რას შეცვლით. სახელის ამოხსნის ჩავარდნა ჩერდება მანამ, სანამ რაიმე კავშირი იარსებებს. პაკეტის ზომის ჩავარდნა ხდება მას შემდეგ, რაც სახელი ამოიხსნა და ხელის ჩამორთმევა დასრულდა, ამიტომ გვერდი იტვირთება და შემდეგ იკიდება. ეტაპი იპოვეთ პარამეტრის პოვნამდე.
ორი ჩავარდნა სხვადასხვა შრეზე
ამოხსნა სახელს მისამართად აქცევს და კავშირში სხვა ვერაფერი დაიწყება, ვიდრე ეს არ გამოვა. ბილიკის MTU-ის პრობლემები უფრო გვიან ხდება, როცა რომელიმე რგოლის ზღვარზე დიდი პაკეტი იყრება და გამომგზავნის ამის შესახებ არასდროს ეუბნებიან. ერთი ძებნაა; მეორე — მიწოდების ჩავარდნა, რომელიც მხოლოდ გარკვეულ ზომაზე მაღლა ჩნდება.
სიმპტომები იმგვარად განსხვავდება, რომ ყოველგვარი ხელსაწყოს გარეშე შეგიძლიათ დააკვირდეთ. DNS-ის ჩავარდნა მყისიერი და მუდმივია: ბრაუზერი ამბობს, რომ სერვერი ვერ მოიძებნა. MTU-ის ჩავარდნა ნაწილობრივია: გვერდი იწყება, რამდენიმე რესურსი აღწევს და დიდი პასუხი ან ატვირთვა იკიდება.
თუ თქვენი სიმპტომი ნაწილობრივია, შეწყვიტეთ DNS-ზე ყურება.
ეტაპი 1: იხსნება თუ არა სახელი საერთოდ
გამოიყენეთ პლატფორმის საძიებო ხელსაწყოები ზუსტად იმ ჰოსტის სახელით, რომელსაც აპლიკაცია იყენებს. ოფისის კერძო სახელს შეიძლება შიდა ამომხსნელი სჭირდებოდება, ხოლო ბრაუზერის საკუთარი უსაფრთხო DNS შეიძლება სხვანაირად მოიქცეს, ვიდრე ოპერაციული სისტემის ამომხსნელს, ამიტომ ორივე შეიძლება არ შეთანხმდენ ერთსა და იმავე სახელზე.
ჰკითხეთ ამომხსნელს, რომელსაც ოპერაციული სისტემა გამოიყენებდა, შემდეგ შეადარეთ:
dig +short vpn.example.com
dig +short vpn.example.com @10.0.0.53
თუ ამოხსნა ვერ მოხერხდა, პრობლემა იმ პოლიტიკასა და მის ხელმისაწვდომობაშია. ნუ გაუგზავნით კერძო სახელებს თვითნებურ საჯარო ამომხსნელებს მხოლოდ შედარების მისაღებად, რადგან თავად შედარება ამჟღავნებს იმ სახელებს, რომელებიც შიდა გსურდათ დარჩენილიყოთ.
ეტაპი 2: სად ჩერდება გადაცემა
თუ სახელი ამოიხსნა და კავშირი დაიწყოd, ჩაწერეთ, სად ჩერდება ოპერაცია. გვერდი, რომელიც იხატება და შემდეგ ერთ რესურსზე იკიდება, ატვირთვა, რომელიც მუდმივ წერტილში იღუპება, ან დიდი ჩამოტვირთვა, რომელიც არასდროს არ სრულდება, სანამ პატარა მოთხოვნები მუშაობენ, ყველა ზომის ფორმის სიმპტომია. პასუხი, რომელიც საერთოდ არ იწყება, სხვა ფორმისაა.
შედარებისას დამაგრებული დატოვეთ ბოლო წერტილი და აპლიკაციის დანიშნულება, თორემ ორ ცვლადს ერთდროულად ზომავთ. ამ ეტაპზე სხვა მიზეზებიც შესაძლებელია: სერვისის შეცდომები, დანაკარგი, ფილტრის ქცევა და გვირაბის ხელახლა დაკავშირება — ყველა შეჩერებას ქმნის.
ერთი განმეორებადი შეჩერება ათ ანეკდოტურ შეჩერებაზე მეტად ღირს.
რატომ აზიანებს MTU მხოლოდ ხელის ჩამორთმევის შემდეგ
TCP-ის ხელის ჩამორთმევა პატარა პაკეტებს იყენებს, ამიტომ წარმატებით სრულდება ბილიკზე, რომელსაც სრული ზომის სეგმენტი ვერ გადააქვს. ჩავარდნა მაშინ ჩნდება, როცა გამომგზავნი დაშლის ამკრძალავი ბიტით დიდ პაკეტს აგზავნის, რგოლი მას ყრის და ICMP-ის შეტყობინება, რომელიც ზღვარს შეატყობინებდა, არასდროს აღწევს, რადგან ფილტრმა შეჭამა. შემდეგ გამომგზავნი იმავე ზომას იმეორებს და გადაცემა იკიდება.
ამიტომ სიმპტომი ზომაზეა დამოკიდებული და განმეორებადია, არა შემთხვევითი. ეს ასევე ხსნის, რატომ არაფერს ამტკიცებს ჰოსტის ping-ი, რადგან პატარა ICMP-ის ექო შეიძლება გაატაროს ბილიკზე, რომელიც სრული ზომის დატვირთვას ვერ გადაიტანს. თუ შესაძლებელია, ზომა ბილიკის ორივე ბოლოდან გაზომეთ. ზღვარი, რომელიც მხოლოდ ერთი მიმართულებით ჩნდება, მარშრუტიზაციის ასიმეტრიაა და არა გვირაბის MTU.
ზომა ცხადად გაზომეთ, ნაცვლად იმისა, რომ დაასკვნთ:
ping -M do -s 1472 203.0.113.20
tracepath 203.0.113.20
შეცვალეთ ერთი შრე და შემდეგ დაამტკიცეთ
სახელებისთვის შეცვალეთ ამომხსნელის პოლიტიკა და ხელახლა გაუშვით იგივე ძებნა. ზომისთვის გამოიყენეთ MTU-ის პროცედურა ჩაწერილი საწყისი მნიშნელობებით და მზად უკუცევით, რადგან MSS-ის შეზღუდვა გვირაბის რეალური MTU-ის ცოდნის გარეშე ერთ შეჩერებას მეორეზე ცვლის.
გვერდი, რომელიც რამდენიმე პარამეტრის შეცვლის შემდეგ ერთხელ იტვირთება, არ განსაზღვრავს შეკეთებას. შეცვალეთ ერთი რამ, ხელახლა გაუშვით იგივე ტესტი და შედეგი შეინახეთ თქვენ მიერ ჩაწერილი პირველი წარუმატებული ეტაპის გვერდით.
ეს ჩანაწერია ის, რაც ხელს უშლის DNS-ს, პაკეტის ზომასა და ავთენტიფიკაციას გახდენ მუდმივი შემოვლითი გზების გროვა, რომელსაც ვერავინ ვერ ახსნის. ნედლი IP-ით ტესტირება კარგი მაგალითია იმ მოკლე გზისა, რომელიც TLS-ის იდენტობას ცვლის, ხოლო სერტიფიკატის შემოწმების გამრთოფა შედარების გასამართლებად დიაგნოზი არ არის.