მონაცემთა ბაზის მოთხოვნა IPsec-ზე იკიდება: UDP-ის გადალაგება თუ TCP?
სუფთა handshake-ის შემდეგ ჩამოკიდებული მოთხოვნა გვირაბის გზის შიგნით მიუთითებს. სამი პირობა წყვეტს, გზა გამოსწორდეს თუ 443-ზე TCP-ზე დავბრუნდეთ.
TCP handshake-ის შემდეგ ჩამოკიდებული მოთხოვნა მარშრუტიზაციის პრობლემა არ არის. მარშრუტის ხარვეზები handshake-ს ამცდება, ამიტომ სესია, რომელიც დამყარდება და შემდეგ გაჩუმდება, გზის შიგნით მიუთითებს: ინსპექცია, MTU ან ის, თუ როგორ ჩამოდის გვირაბის UDP პაკეტები. თქვენ წინაშე გადაწყვეტილებაა, გაასწოროთ ეს გზა თუ გვირაბი TCP-ზე გადაიტანოთ. სამი პირობა წყვეტს ამას და არც ერთი მათგანი მონაცემთა ბაზაზე არ არის.
დააკლასიფიცირეთ გაჩერება, სანამ გვირაბს დაადანაშაულებთ
ოთხი შედეგი მომხმარებლისთვის ერთნაირად გამოიყურება და ინჟინრისთვის სრულიად სხვადასხვას ნიშნავს.
| What the client sees | What it rules out |
|---|---|
| Connection refused | Nothing is listening on the address and port the client reached |
| Timeout before the handshake | A filter, a missing route, or the wrong address |
| Handshake completes, query hangs | The session exists, so look at inspection, MTU and packet order |
| Stalls that recover on retry | Often reordering, or a state table entry expiring |
მხოლოდ ბოლო ორი სტრიქონი ამართლებს გვირაბზე დახარჯულ დროს. VPN-ის გავლით უარყოფილი კავშირი ჩვეულებრივ ნიშნავს, რომ მონაცემთა ბაზა მხოლოდ loopback-ზე უსმენს, რაც მსმენელის პრობლემაა, ხოლო handshake-მდე ტაიმაუტი ფილტრი ან მარშრუტია. არც ერთი არ უმჯობესდება ინკაფსულაციის შეცვლით.
ჯერ ჩაწერეთ კლასიფიკაცია ტიკეტში. ეს ყველაზე იაფი ნაბიჯია და ძიების სივრცის უმეტეს ნაწილს აშორებს.
სამი პირობა, რომელიც UDP-სა და TCP-ს შორის წყვეტს
ინკაფსულირებული IPsec ტრაფიკი UDP-ზე მოძრაობს და UDP გზას აძლევს თავისუფლებას გადაალაგოს და ჩამოაგდოს ვინმესთვის თქმის გარეშე. როცა გადალაგება პაკეტებს გვირაბის გამეორების საწინააღმდეგო ფანჯრის გარეთ უბიძგებს, ისინი ჩუმად იშლება და შიდა TCP სესია უბრალოდ ელოდება. ეს არის მექანიზმი წარმატებული handshake-ისა და არასდროს დაბრუნებული მოთხოვნის უკან.
გზის გასწორება ან TCP-ზე დაბრუნება სამ რამეზეა დამოკიდებული. პირველი, არის თუ არა რეალური პაკეტის დაკარგვა გზაზე, თუ მხოლოდ გადალაგება? მეორე, შეგიძლიათ შეცვალოთ სად ხდება ინსპექცია, ან გამორიცხოთ ეს გვირაბი გადამალაგებელი კომპონენტიდან? მესამე, მგრძნობიარეა თუ არა დატვირთვა გაჩერების შაბლონის მიმართ, მაგალითად ერთ ბმულზე გაზიარებული მრავალი მულტიპლექსური სესია?
თუ პირველი პასუხი დაკარგვაა, მეორე კი არა,443-ის TCP პრაგმატული ალტერნატივაა. თუ მეორე პასუხი კი არის, გაასწორეთ გზა და დატოვეთ UDP.
წაიკითხეთ firewall-ის ჩანაწერი და არა აპლიკაციის შეცდომა
აპლიკაცია ტაიმაუტს აცხადებს, რაც მიზეზზე არაფერს ამბობს. თავად firewall-ის ჟურნალი არის ადგილი, სადაც ჩამოგდება ან ბლოკირება ჩნდება, ამიტომ გაფილტრეთ მონაცემთა ბაზისა და აპლიკაციის მისამართებით და მოძებნეთ როგორც ჩამოგდებები, ისე მიღებები.საფრთხის პრევენციის მოდულებს შეუძლიათ პაკეტების ჩამოგდება აპლიკაციის დონეზე შეცდომის შექმნის გარეშე, და ეს ზუსტად ჩამოკიდებული მოთხოვნის ფორმაა. სიჩუმე ჟურნალში მონაცემიც არის: ის მიუთითებს იმაზე, რაც არ ლოგდება, მაგალითად გადალაგებაზე.
შეამოწმეთ კლასტერიც. არასწორად კონფიგურირებულ კლასტერს შეუძლია სესია ერთი წევრის მდგომარეობის ცხრილში შეინახოს, სანამ პაკეტები მეორე წევრის გზას გადის, ამიტომ პასუხები იქ მოდის, სადაც მდგომარეობა არ არსებობს. ასეთი გაჩერებები შემთხვევითი ჩანს და დატვირთვას არ ემთხვევა.
შეადარეთ ორივე ბოლო, სანამ რამეს შეცვლით, და შეადარეთ ჩამოსვლის რიგი და არა პაკეტების რაოდენობა:
tcpdump -ni any udp port 4500 -w /tmp/encap.pcap
tcpdump -ni any tcp port 5432 -w /tmp/inner.pcapრა უჯდება თქვენ რეალურად 443-ის TCP
გვირაბის TCP-ზე გადატანა აშორებს გადალაგების სიმპტომს, რადგან შუამავალი ყუთი ახლა დალაგებულ ნაკადს ხედავს. ის ასევე ქმნის TCP-over-TCP-ს. გარე კავშირი თავიდან აგზავნის იმას, რაც შიდა კავშირმა უკვე თავიდან გაგზავნა, და ერთმა დაკარგვამ შეიძლება ერთდროულად გააჩეროს ყველა მულტიპლექსური სესია. სუფთა გზაზე ეს უხილავია. დანაკარგებიან გზაზე წამალი სიმპტომზე უარესია.
გაცვლა მისაღებია, როცა ალტერნატივა კავშირის სრული არარსებობაა, და ის უნდა დოკუმენტირდეს გამონაკლისად პასუხისმგებელ პირთან ერთად და არა მიღებული იქნას როგორც ნორმა.
ჩაწერეთ ტრანსპორტი, პორტი, სანიმუშო მოთხოვნა და გაზომილი შედეგი, ასევე თარიღი. ამ ჩანაწერის გარეშე შემდეგი ინჟინერი გაიმეორებს ექსპერიმენტს და გამონაკლისი ჩუმად არქიტექტურად იქცევა.
შეინარჩუნეთ გადაწყვეტილება გადასინჯადი
გზის დიაგნოზი სწრაფად ძველდება. შუამავალი ყუთი იცვლება, მოდულის კონფიგურაცია იცვლება, ბმული განახლდება და 443-ის TCP-ის მიზეზი ქრება, კონფიგურაცია კი რჩება. დაუსვით გადასინჯვის თარიღი გამონაკლისს და დაასახელეთ პირობა, რომელიც UDP-ზე დაბრუნების საშუალებას მოგცემთ.
გამოსცადეთ ორივე ტრანსპორტი პატარა მოთხოვნით და დიდი შედეგების ნაკრებით. გადალაგება ზომაზე დამოკიდებული გაჩერებებით ვლინდება, ხოლო მსმენელის ხარვეზი ორივე ზომას თანაბრად აჩერებს.