როგორ წავიკითხოთ პირველი IKEv2 გაცვლა პაკეტების ჩაწერაში

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

დარწმუნდით, რომ საწყის გაცვლას უყურებთ

IKEv2 მოლაპარაკება იწყება IKE_SA_INIT-ით, გაცვლის ტიპი 34, შეტყობინების ID 0. ინიციატორი ირჩევს არანულოვან SPI-ს, ხოლო პასუხისმგებლის SPI ამ პირველ მოთხოვნაში ნულია, პასუხში კი არანულოვანი. ეს სამი ფაქტი გამოყოფს ახალ მცდელობას გასაღებების განახლებისგან ან IKE_AUTH შეტყობინებისგან, რომელიც შემთხვევით ჩანაწერის თავში აღმოჩნდა.

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

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

tshark -r ike.pcapng -Y "isakmp" -T fields -e frame.number -e ip.src -e udp.srcport -e isakmp.exchangetype -e isakmp.messageid -e isakmp.initiator_spi -e isakmp.responder_spi

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

წაიკითხეთ უარი, სანამ წარმატებას წაიკითხავთ

პასუხი ავტომატურად წინსვლა არ არის. პასუხისმგებელს შეუძლია უპასუხოს cookie შეტყობინებით და მოელოდოს, რომ ინიციატორი ხელახლა სცდის, ან INVALID_KE_PAYLOAD-ით, რომელიც ასახელებს ჯგუფს, რომელსაც ნაცვლად მიიღებდა. ორივე სწორად ფორმირებულ IKE შეტყობინებად მოდის და ორივე დასრულებულ გაცვლას ჰგავს მხოლოდ პაკეტების მთვლელ ფილტრს.

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

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

პორტი 4500 ერთი პროტოკოლი არ არის

საწყის გაცვლას ჩვეულებრივ UDP 500 ატარებს. NAT-ის ამოცნობის შემდეგ IKE გადადის 4500-ზე და ყოველი შეტყობინების წინ დებს ოთხბაიტიან ნულოვან არა-ESP ნიშანს. იმავე პორტზე დაბუდებული ESP პირიქით, იწყება არანულოვანი ESP SPI-ით, ხოლო ერთბაიტიანი NAT keepalive მესამე ფორმაა, რომელიც მაშინ ჩნდება, როცა სხვა არაფერი ხდება.

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

tshark -r ike.pcapng -Y "udp.port == 4500 && isakmp" -T fields -e frame.number -e isakmp.exchangetype
tshark -r ike.pcapng -Y "udp.port == 4500 && !isakmp" -T fields -e frame.number -e esp.spi

სიჩუმე აღწერს დაკვირვების წერტილს

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

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

tshark -r ike.pcapng -Y "icmp.type == 3" -T fields -e frame.number -e ip.src -e icmp.code

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