MTU iPhone-ის VPN-ში: ჯერ მფლობელი განსაზღვრეთ, შემდეგ რიცხვი შეცვალეთ
სამი კითხვა წყვეტს, შეუძლია თუ არა აპს, კარიბჭის პროფილს ან ტელეფონზე არავის შეცვალოს ზომა. უპასუხეთ მათ, სანამ Mac-იდან რიცხვს ისესხებთ.
iPhone VPN-ის პაკეტის ზომაზე ყოველი განხილვა საბოლოოდ გვთავაზობს იმავე Mac-ის ბრძანებას ppp0 სახელის ინტერფეისის წინააღმდეგ, ჩვეულებრივ თანდართული რიცხვით. ის არ გადადის და არც Mac-ზე იქნებოდა სწორი მართვის საშუალება, თუ ეს ინტერფეისი არ ეკუთვნიდა საკითხავ კავშირს. ტელეფონში რიცხვი ეკუთვნის მას, ვინც გვირაბს ახორციელებს: ოპერაციულ სისტემას მშობლიური პროფილისთვის, პაკეტური გვირაბის მომწოდებელს აპისთვის, ან კარიბჭეს, როცა დოკუმენტირებული ატრიბუტი მოლაპარაკდება. სამი კითხვა არკვევს, რომელ შემთხვევასთან გაქვთ საქმე.
პირველი კითხვა: რომელი კლიენტი მუშაობს
მშობლიური IKEv2 პროფილი, ჩაშენებული Cisco IPsec პროფილი და მესამე მხარის Cisco კლიენტი სამი განსხვავებული იმპლემენტაციაა მხარდაჭერილი ატრიბუტების სამი განსხვავებული ნაკრებით. პარამეტრებში პროფილის ტიპი გეუბნებათ, რომელი რეალურად გაუშვა ტელეფონმა, ხოლო აპების სია გეუბნებათ, საერთოდ არის თუ არა მომწოდებელი გზაზე. იქიდან დაიწყეთ, რადგან დანარჩენი გადაწყვეტილება აქედან გამომდინარეობს. თუ აპების სიაში მომწოდებელი არ გამოჩნდა, გვირაბი ოპერაციულ სისტემას ეკუთვნის.
ნუ გამოიტანთ იმპლემენტაციას კარიბჭის მომწოდებლიდან. Cisco-ს მთავარ კვანძს შეუძლია შეწყვიტოს იმ კლიენტების კავშირები, რომლებსაც მომწოდებლის სახელის გარდა არაფერი აქვთ საერთო. ძველი ვერსიის ძველი ნაგებობის ეკრანის სურათი გეუბნებათ, რას უჭერდა მხარს ის წყვილი და არა რას აკეთებს თქვენს ხელში არსებული ტელეფონი.
მეორე კითხვა: ვის ეკუთვნის მნიშვნელობა
Apple MTU თვისებას პაკეტური გვირაბის დეველოპერებს აძლევს ქსელის გაფართოების პარამეტრების ობიექტის მეშვეობით. ეს API-ა იმ მომწოდებლისთვის, რომელიც საკუთარ გვირაბს აწყობს და არა გადამრთველი, რომელსაც მომხმარებელი ან ადმინისტრატორი სხვის დაყენებულ კლიენტზე ჩართავს. მესამე მხარის აპს შეუძლია აირჩიოს მისი გამოჩენა, უგულებელყოფა ან მნიშვნელობის მყარად ჩაწერა.
მშობლიური პროფილისთვის ინტერფეისის ზომას ოპერაციული სისტემა ირჩევს და ტელეფონი ამისთვის არავითარ რედაქტორს არ გვთავაზობს. Cisco-ს დისტანციური წვდომის კარიბჭისთვის არსებობს კავშირის პროფილის დოკუმენტირებული ატრიბუტი და მისი გამოყენება დამოკიდებულია კლიენტზე, ვერსიასა და მოლაპარაკებულ ტრანსპორტზე. სწორედ იმ ნაპრალში, დოკუმენტირებულსა და დაცულს შორის, კოპირებული რიცხვი ცდება.
| Owner | Who can change it | Reachable from the phone |
|---|---|---|
| Packet-tunnel provider | The app vendor through its API | Only if the app exposes a setting |
| Native IKEv2 or Cisco IPsec profile | The operating system | No user control |
| Gateway group policy attribute | The gateway administrator | If the client honours it |
მესამე კითხვა: დამოკიდებულია თუ არა სიმპტომი ზომაზე
ზომის პრობლემებს აქვს ხელმოწერა: პატარა მოთხოვნები წარმატდება, დიდი ატვირთვები ან დიდი პასუხები იკიდება და იგივე სერვისი სხვა წვდომის ქსელში მუშაობს. ფილტრაციამ, აპის დატვირთვის ლიმიტმა და გაჩერებულმა სერვერმა შეიძლება მსგავსი ჩივილი გამოიწვიოს, ამიტომ ჩაწერეთ ერთი წარუმატებელი ოპერაცია მომუშავის გვერდით. თუ აპი ამას აცნობს, დაწერეთ ორივე დროებითა და ზომებით. ამ წყვილის გარეშე ყოველი შემდგომი ცვლილება ვარაუდია.
ჩაატარეთ იგივე ტესტი Wi-Fi-ზე და მობილურ ქსელში. ქსელს მიმყოლელი ხარვეზი გზაზე მიუთითებს; მოწყობილობას მიმყოლელი კლიენტზე ან პროფილზე და ორივეს სხვადასხვა მფლობელი სჭირდება. ორივე გაშვებისთვის გამოიყენეთ იგივე სერვისი და იგივე ანგარიში, თორემ შედარება არაფერს გეტყვით.
რატომ ჩნდება Mac-ის რეცეპტი კვლავ და კვლავ
PPP-ზე დაფუძნებული სამაგიდო VPN-ების წლებმა ინტერფეისის ზომის შეცვლა ლეგიტიმურ ლოკალურ გვერდის ავლად აქცია და ეს ინსტრუქციები მობილურ განხილვებში გადაკოპირდა. ტელეფონში არ არის shell, არ არის ასეთი ინტერფეისის სახელი და არ არის შენარჩუნება ხელახალი დაკავშირების შემდეგ. რეცეპტმა, რომელმაც 2011 წელს სამაგიდო პრობლემა გადაჭრა, იმ პირობებზე ბევრად შორს იმოგზაურა, რომლებიც მას სწორს ხდიდნენ. მობილური კლიენტები ამისთვის არავითარ shell ბრძანებას არ იღებენ, რაც არ უნდა ამტკიცებდეს განხილვა.
კოპირებულ მნიშვნელობას გზის შესახებ ჰიპოთეზად მოექეცით და არა როგორც პარამეტრს. თუ უფრო პატარა ზომა გადაცემას ამუშავებს და უფრო დიდი საიმედოდ ვარდება, გზის შესახებ მტკიცებულება გაქვთ; მაინც უნდა იპოვოთ კომპონენტი, რომელსაც ამაზე მოქმედების უფლება აქვს. ეს ძიება ჩვეულებრივ კარიბჭის პროფილში ან აპის მომწოდებელთან მთავრდება და იშვიათად ტელეფონში.
ტრანსპორტი პასუხს ცვლის
თუ სესია IPsec-ის ნაცვლად TLS-ზე მიდის, კარიბჭეზე TCP-ის სეგმენტაციის კორექტირება დაგეხმარებათ, რადგან ის TCP ნაკადებისთვის გამოცხადებულ სეგმენტის ზომას გადაწერს. UDP ტრაფიკზე ის არაფერს აკეთებს და მასში თანამედროვე ვების იმაზე მეტი ნაწილი შედის, ვიდრე ხალხი ელოდება. ცვლილების შეთავაზებამდე შეამოწმეთ მოლაპარაკებული ტრანსპორტი და ბილეთში მიუთითეთ, რომელ ტრანსპორტზე ელოდებით გავლენას.
გზის MTU-ის აღმოჩენა იმიტომ არსებობს, რომ ბოლოებმა ისწავლონ რეალური ზღვარი და არა გამოიცნონ. კავშირუკუქციის დაბლოკვა და მცირე ზომის მყარად ჩაწერა მუშა დიდ გადაცემას ცვლის მუდმივ, ფარულ ხარჯზე ყოველ კავშირზე.
რა ვკითხოთ კარიბჭის გუნდს
სთხოვეთ სამი რამ: ატრიბუტის ზუსტი სახელი და მისი არე, იცავენ თუ არა მას განლაგებული კლიენტები და რომელ ტრანსპორტზე შეთანხმდა სესია. ერთ ჯგუფურ პოლიტიკაზე გამოყენებული ცვლილება შემოწმებადია; გლობალური რედაქტირება არა და ის რისკს გადაიტანს მომხმარებლებზე, რომლებსაც პრობლემა არასდროს შეუტყობინებიათ. მოითხოვეთ დოკუმენტის მითითებაც, რადგან ატრიბუტების სახელები ვერსიებს შორის იცვლება.
შემდეგ შეცვალეთ ერთი რამ და ხელახლა შეამოწმეთ საწყისი წარუმატებელი ოპერაცია და არა სისწრაფის ტესტის ჩამოტვირთვა. შეინახეთ წინა და შემდგომი ჩანაწერი კლიენტის ვერსიასთან და წვდომის ქსელთან ერთად, რათა შემდეგი ანგარიში შედარდეს და არა ხელახლა განიხილონ.
თუ ოპერაცია მაინც ვარდება საწყის ზომაზე, ზომა მიზეზი არ იყო. ჩაწერეთ ეს დასკვნაც, რათა შემდეგმა ადამიანმა იგივე ჰიპოთეზა ხელახლა არ გახსნას.