Ping მტკიცებულება არ არის: შეამოწმეთ ბილიკი ორ საიტს შორის

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

დაიწყეთ იმ კლიენტიდან, რომელსაც სერვისი სჭირდება

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

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

გაიარეთ ბილიკი თითოეულ კიდეზე

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

ip route get 10.10.0.5
sudo tcpdump -ni any host 10.10.0.5 and port 445
sudo tcpdump -ni any net 10.10.0.0/24 and net 10.20.0.0/24

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

გამოიყენეთ ის პროტოკოლი, რომელსაც აპლიკაცია იყენებს

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

nc -vz 10.10.0.5 445
curl -sv --max-time 5 https://files.corp.internal/ -o /dev/null
openssl s_client -connect 10.10.0.5:443 -servername files.corp.internal

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

გაამრავლეთ ის პირობა, რომელშიც ფუჭდება

მხოლოდ დიდი გადაცემისას გამოვლენილი ჩავარდნები ზომის პრობლემაა, არა კავშირის. გაგზავნეთ დიდი პაკეტი ჩართული don't-fragment ბიტით და დააკვირდით, სად ჩერდება. თუ პატარა მოთხოვნა წარმატებულია, დიდი კი ჩერდება, გვირაბის MTU და MSS-ის დამუშავება შესასვლელებზე შემდეგი ეჭვმიტანილები არიან.

ping -M do -s 1400 10.10.0.5
ping -M do -s 1472 10.10.0.5
curl -sS --max-time 30 -F file=@./sample.bin https://files.corp.internal/upload

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

შესწორების შემდეგ გაიმეორეთ იგივე ტესტი

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

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