iPhone Always On VPN: ორი გვირაბი შეიძლება ერთ ვირტუალურ IP-ს იზიარებდეს

მართული Always On პროფილის მქონე ზედამხედველობის ქვეშ მყოფ iPhone-ზე ტელეფონი ინახავს გვირაბს ყოველი აქტიური IP ინტერფეისისთვის, ამიტომ ფიჭური ქსელი და Wi-Fi თითოეული თავისას იღებს. შემდეგ სერვერი ერთი მოწყობილობისთვის ორ IKE უსაფრთხოების ასოციაციას ჩამოთვლის, ხშირად ერთ ვირტუალურ მისამართს იზიარებს, და პირველი იმპულსია ამას rekey ციკლი ვუწოდოთ და ტაიმერების შეცვლა დავიწყოთ. ეს იმპულსი ჩვეულებრივ მცდარია. გაიარეთ ქვემოთ მოცემული ნაბიჯები იმ თანმიმდევრობით, რომლითაც მტკიცებულებები სერვერზე ჩნდება, და დატოვეთ ტელეფონის პარამეტრები უცვლელად, სანამ სერვერი არ გეტყვით, რომელი შემთხვევა გაქვთ.

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

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

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

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

IKEv2 rekey და make-before-break ხელახალი ავთენტიფიკაცია განზრახ ქმნიან მოკლე გადაფარვას, ახალი ასოციაციის დამყარებით ძველის წაშლამდე. დროის ნიშნები წყვეტენ საქმეს, რადგან ძველი SA, რომელიც ქრება ახლის გამოჩენიდან ერთი ან ორი წამის შემდეგ, განახლებაა, რომელიც თავის საქმეს აკეთებს. დამოუკიდებელი ინტერფეისური გვირაბები არასდროს ასე არ გამოიყურება, რადგან თითოეული რჩება მანამ, სანამ მისი ინტერფეისი ჩართულია, და ერთის წაშლა არ გამომდინარეობს მეორის შექმნიდან.

Apple-ის მართული Always On ქცევა ინტერფეისის მიხედვითაა, ამიტომ ზედამხედველობის ქვეშ მყოფი მოწყობილობა შეიძლება ლეგიტიმურად უფრო დაკავებული გამოიყურებოდეს, ვიდრე ხელით გამართული პროფილი. პროვაიდერის აპის ავტომატური დაკავშირების გადამრთველი იგივეს არ ნიშნავს, და ჩვეულებრივი on-demand წესიც არა. Apple-ის გაშლის მიმოხილვა აღწერს ინტერფეისის მიხედვით მოდელს; შეადარეთ თქვენი ორი სტრიქონი მას, სანამ ციკლს ჩათვლით. ორივე ფორმა ერთი და იმავე სერვერული აუზიდან იღებს, ამიტომ გადაფარვა თქვენი ერთადერთი ადრეული სიგნალია.

ნახეთ, რატომ ამტვრევს ერთი ვირტუალური მისამართი ორი გვირაბის პასუხებს

ტელეფონზე პასუხი შიდა მისამართზეა მიმართული, და ბირთვი გამავალ გვირაბს ირჩევს დანიშნულებისა და პოლიტიკის მიხედვით, და არა იმ ინტერფეისის მიხედვით, რომელიც ტელეფონმა გამოიყენა. ერთსა და იმავე ვირტუალურ IP-ს მქონე და დამთხვევადი პოლიტიკების მქონე ორი ერთდროული ასოციაცია მარშრუტიზაციის გადაწყვეტილებას ტოვებს იმის თქმის გზის გარეშე, რომელ სესიას ეკუთვნის პასუხი. ზოგი პასუხი არასწორ გვირაბში გადის, და ტელეფონი აჩვენებს ერთი მიმართულებით მომუშავე ან Wi-Fi-ის აწევისას მკვდარ კავშირს. ორი ბრძანების გამოტანა ამტკიცებს მდგომარეობას: swanctl --list-sas აჩვენებს ერთსა და იმავე ვირტუალურ IP-ს ორივე SA-ზე, და ip xfrm policy აჩვენებს ორ იდენტურ სელექტორს.

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

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

შეცვალეთ აუზი ან პარალელურობის მოდელი, და არა rekey ტაიმერი

swanctl კონფიგურაციაში უნიკალურობა კავშირზე აშკარა პოლიტიკაა: unique = replace შლის ძველ კავშირს, როცა ახალი მყარდება, და unique = keep უარყოფს ახალმოსულს. ორივე მნიშვნელობა მოქმედებს კავშირის დაყენებისას, და არა მის შიგნით არსებულ შვილობილ SA-ებზე.

connections {
  ios-alwayson {
    unique = replace
  }
}

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

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

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

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