SSH იჭედება SSH2_MSG_KEX_ECDH_REPLY-ზე: მიზეზი ყოველთვის MTU არ არის

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

წაიკითხეთ კვალი, რომ ნახოთ, საერთოდ ელოდნენ თუ არა პასუხს

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

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

რატომ შეიძლება პატარა პასუხი მაინც ძალიან დიდი იყოს

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

განსაზღვრეთ ზომა, ნაცვლად ვარაუდისა. წაიკითხეთ გვირაბის MTU ip link show tun0-ით, შემდეგ გაგზავნეთ ცდები, რომლებიც არ უნდა დაიყოს: ping -4 -M do -s 1352 host, გაიმეორეთ უფრო მცირე დატვირთვებით. გარკვეულ ზომაზე წარუმატებლობიდან წარმატებაზე გადასვლა მტკიცებულებაა; ერთგვაროვანი წარუმატებლობა ნიშნავს, რომ ICMP იფილტრება და არაფერს გეუბნებათ.

დროებითი შემცირება სწრაფად ადასტურებს თეორიას, ხოლო მუდმივი ვერსია პროფილში ან MSS შეზღუდვად იმ როუტერზეა, რომელიც გვირაბს გადასცემს:

sudo ip link set dev tun0 mtu 1200
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

ორი მიზეზი, რომლებიც ზომის პრობლემას ბაძავს

გასაღების ფაილი, რომელსაც კლიენტი ვერ კითხულობს, იწვევს იგივე ლოდინს, გაფრთხილების გარეშე დეტალურ გამოტანაშიც. known_hosts-ის ერთი ნიმუში ამას აადვილებს: @cert-authority ჩანაწერი, რომელიც CA-ის საჯარო გასაღებზე მიუთითებს და მხოლოდ ერთ ანგარიშს შეუძლია მისი წაკითხვა. ანგარიში, რომელიც ფაილს ფლობს, უკავშირდება, დანარჩენი ყველა ანგარიში კი იჭედება. თუ ხარვეზი მომხმარებელს მიჰყვება და არა მასპინძელს, შეამოწმეთ ფაილის რეჟიმები პაკეტების ზომებამდე.

განახლებამ შეიძლება ასევე მოხსნას ალგორითმი, რომელსაც ორივე მხარე ადრე იზიარებდა. დაამაგრეთ ერთი მეთოდი, რომელსაც სერვერი ჯერ კიდევ გვთავაზობს, დიაგნოსტიკისთვის: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. დაუყოვნებლივ წარმატებული კავშირი ამტკიცებს, რომ გზა რიგზეა და შესწორება ორივე მხარის მოლაპარაკების პოლიტიკაშია.

სამი ფაქტი, რომლებიც ღირს ჩაწერად

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

ისინი ასევე ხელს უშლიან შემდეგ ადამიანს MTU-ის დაწევაში იმ ხარვეზის გამო, რომელიც არასდროს ზომას არ ეხებოდა.

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