რატომ თანაბარი ღირებულების მარშრუტები VPN-ის ხარვეზებს ძნელად შესამჩნევს ხდის
როცა რამდენიმე გვირაბი ერთ ღირებულებას იზიარებს, თითოეულ ნაკადს სხვა შეუძლია აირჩიოს. წარმატებული ping არაფერს ამბობს იმ გზაზე, რომელსაც თქვენი აპლიკაცია რეალურად იყენებს.
მომხმარებელი იუწყება, რომ შიდა აპლიკაცია ერთი მანქანიდან მუშაობს, მეორიდან კი ვერ მუშაობს, მაშინ როცა კარიბჭიდან გაშვებული ping ორივე შემთხვევაში წარმატებულია. თანაბარი ღირებულების რამდენიმე გვირაბის დროს ეს წინააღმდეგობა არ არის. თითოეული ნაკადი საკუთარ შემდეგ ნახტომზე თავსდება, ამიტომ თქვენი შემოწმება და მომხმარებლის სესია შესაძლოა უბრალოდ სხვადასხვა გზას იყენებდეს. ქვემოთ მოცემული მიმოხილვა ამ არჩევანს რაიმეს შეცვლამდე ამრავლებს.
ერთი ping, რამდენიმე შესაძლო გზა
როცა მარშრუტს ერთზე მეტი შემდეგი ნახტომი აქვს იმავე ღირებულებით, მარშრუტიზატორმა თითოეული პაკეტისთვის ერთი უნდა აირჩიოს. განხორციელებათა უმეტესობა პაკეტის ველებს ჰეშავს, ჩვეულებრივ წყაროსა და დანიშნულების მისამართებს პროტოკოლთან და პორტებთან ერთად, რათა პასუხები იმავე გზაზე დარჩეს. სხვადასხვა აპლიკაცია, ან თუნდაც ერთი აპლიკაციის სხვადასხვა კავშირი, სხვადასხვა ჰეშს ქმნის.
სწორედ ამიტომ კარიბჭიდან გაკეთებული დიაგნოსტიკა ასე ცოტას ამტკიცებს. კარიბჭის საკუთარ შემოწმებას საკუთარი მისამართები და პორტები აქვს, შესაბამისად საკუთარი ჰეშიც. შესაძლებელია ის ჯანსაღ გვირაბზე მოხვდეს, სანამ მომხმარებელი დაზიანებულზე აგრძელებს მოხვედრას.
როგორ ირჩევს პლატფორმა შემდეგ ნახტომს
არჩევანი ამრავლეთ და ნუ გამოიცნობთ. ჰკითხეთ ბირთვს, რომელ მარშრუტს გამოიყენებდა იმავე წყაროსა და დანიშნულებისთვის, რაც წარუმატებელ სესიას აქვს. ეს ძიება მოიცავს ველებს, რომლებსაც ჩვეულებრივი დანიშნულების ძიება უგულებელყოფს. გაუშვით ის მომუშავე კლიენტიდანაც და შეადარეთ ორი პასუხი:
ip route get 10.20.5.7 from 10.20.0.14iproute2-ის უფრო ახალი გამოშვებები პროტოკოლსა და დანიშნულების პორტსაც იღებენ, რაც მნიშვნელოვანია, როცა ჰეში მათ მოიცავს. შეადარეთ ეს გამოტანა იმავე ძიებას მომუშავე კლიენტიდან და განსხვავება ის მტკიცებულებაა, რაც გაკლდათ.
| Observation | Likely cause | First check |
|---|---|---|
| Ping works, application fails | A different flow hash selects another tunnel | Per-flow lookup from the client's address |
| Some users fail, others do not | One tunnel lacks a prefix or selector | Compare both tunnels' installed routes |
| Fails only at larger sizes | Tunnels have different effective MTU | Probe the same size over each path |
| Fails after a reconnect | Stateful asymmetry between paths | Session state on both gateways |
მიჰყევით წარუმატებელ ნაკადს და არა მარშრუტების ცხრილს
მარშრუტების ცხრილი ორივე გვირაბს ჩამოთვლის და განმარტებით სწორად გამოიყურება. კითხვა ისაა, რას აკეთებს თითოეული გვირაბი პაკეტთან არჩევის შემდეგ. დაადასტურეთ, რომ ორივეს ერთი და იგივე დაცული პრეფიქსები, იგივე გადაცემის ნებართვა და იმავე კლიენტამდე მიმავალი დაბრუნების გზა აქვს.
ყურადღება მიაქციეთ შუაში მდებარე მდგომარეობის მქონე მოწყობილობებს. თუ მოთხოვნა ერთი გვირაბიდან გადის და პასუხი მეორეთი ბრუნდება, მაშინ firewall ან NAT, რომელსაც საწყისი ნაკადი არასდროს უნახავს, მას გადააგდებს. ორივე გვირაბი ტრაფიკს სწორად გადასცემს და კავშირი მაინც იშლება.
შეამოწმეთ MTU თითოეული გზისთვისაც. დამატებითი ინკაფსულაციის მქონე გზა გამოსადეგ ზომას ამცირებს და გადაცემა, რომელიც ერთ გვირაბში წარმატებულია, მეორეში ზუსტად იმ ზომაზე ჩერდება, სადაც უფრო პატარა ტყდება.
შეადარეთ თითო გზა ცალ-ცალკე
სადაც დიზაინი ტექნიკურ მომსახურებას უშვებს, ერთი გვირაბი გამოიყვანეთ მომსახურებიდან და გაიმეორეთ მომხმარებლის ამოცანა. თუ ხარვეზი გაქრა, პრობლემა ამოღებულ გზას ეკუთვნის და შემდეგი ნაბიჯი მისი კონფიგურაციის მეზობელთან შედარებაა და არა მარშრუტიზაციის ცხრილის ხელახლა შესწავლა.
შეადარეთ რეალური აპლიკაცია და არა განმეორებითი ping-ები. ჩაწერეთ, მიჰყვება თუ არა ხარვეზი კონკრეტულ შემდეგ ნახტომს, პაკეტის ზომას ან ხელახალი დაკავშირების შემდგომ გადასვლას, რადგან ეს სამი ნიმუში სხვადასხვა შეკეთებაზე მიუთითებს.
ბოლოს ჩამოწერეთ, რატომ ითვლება გზები ეკვივალენტურად და როგორ უნდა გამოიყვანოს ხარვეზმა ერთი მათგანი მომსახურებიდან. მრავალგზიანობა უსაფრთხოა მხოლოდ მაშინ, როცა გზები ნამდვილად ურთიერთშემცვლელია და ეს საპროექტო განცხადებაა, რომლის შემოწმებაც ღირს და არა ვარაუდი.