L2TP ავტომატიზაცია Android-ზე: სკრიპტს შეუძლია მოითხოვოს, არა ააგოს

მითია, რომ L2TP Android-ზე კიდევ ერთი რამაა, რისი გაშვებაც shell სკრიპტს შეუძლია: დაამატე მარშრუტი, დაურეკე ძველ სერვისს, დასრულდა. ასე არ შეიძლება იყოს, რადგან ოთხ სხვადასხვა შრეს უნდა შეთანხმდეს, სანამ გვირაბი პაკეტს გადაიტანს. IPsec შრე იცავს გზას, L2TP ატარებს სესიას, PPP აწარმოებს მოლაპარაკებას ბმაზე, და Android-მა უნდა დაარეგისტრიროს შედეგი როგორც VPN, რომლის ირგვლივაც შეუძლია მარშრუტიზაცია. მე ეს ორჯერ ვნახე კოპირებული ბრძანებებით, და ორივეჯერ მარშრუტი არსებობდა, მაშინ როცა არაფერი იყო დაშიფრული.

რას აკეთებს სინამდვილეში მარშრუტის შეცვლა

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

იგივე ეხება ძველი გამოშვებიდან კოპირებულ სერვისის გამოძახებას. Android-ის შიდა VPN მილსადენი გამოქვეყნებული ავტომატიზაციის API არ არის, და სხვა ვერსიის დანომრილი ტრანზაქცია შეიძლება სხვა ოპერაციას მოხვდეს ან მოითხოვოს უფლებები, რომლებიც სკრიპტს არ აქვს. პაროლის მატარებელი ავტომატიზაცია არასოდეს უნდა იყოს დამოკიდებული გამოცნობილ შიდა არგუმენტებზე, რადგან წარუმატებლობის ფორმა ან ჩუმი no-op-ია, ან ნახევრად შექმნილი პროფილი, რომელსაც არავინ წმენდს.

ოთხი მფლობელი, და სკრიპტი არც ერთი მათგანია

აიღეთ ისინი რიგით. IPsec აყალიბებს და ინარჩუნებს დაცულ გზას და ამოწმებს პარტნიორებს. L2TP ატარებს სესიას მასზე, და სწორედ შრეებად დაყოფაა მიზეზი, რომ სტანდარტი მათ ცალკე მექანიზმებად თვლის და არა ერთ პროტოკოლად. მის შიგნით PPP აწარმოებს მოლაპარაკებას ბმის პარამეტრებზე, რომლებსაც კლიენტი გამოიყენებს. შემდეგ Android ფლობს პლატფორმის მხარეს: რეგისტრირებული VPN ინტერფეისი, აპლიკაციის მიხედვით არეალი, always-on მდგომარეობა და სასიცოცხლო ციკლი, რომელიც წყვეტს, რა მოხდება აპლიკაციის მოკვლისას.

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

რატომ დემონიც არ არის მოკლე გზა

მოწყობილობაზე პრივილეგირებული Linux დემონის გაშვება დაკარგულ ნაწილად გამოიყურება, და ხშირად ის ნამდვილად აწევს გვირაბს. რასაც ის არ აკეთებს, არის ამ გვირაბის Android-ში რეგისტრაცია. ინტერფეისი არსებობს ბირთვის შიგნით, მაგრამ პლატფორმის VPN არჩევანმა, აპლიკაციის მიხედვით მარშრუტიზაციამ, always-on პოლიტიკამ და სასიცოცხლო ციკლმა არ იციან მის შესახებ, და თავად დემონის მარშრუტისა და DNS-ის ცვლილებები კონკურენციას უწევს ქსელის მმართველს იმავე ცხრილებისთვის.

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

როგორ გამოიყურება მხარდაჭერილი გზები

თუ ორგანიზაციას შეუძლია გადავიდეს პროფილზე, რომელსაც თავად Android უზრუნველყოფს, პლატფორმის გზა პატიოსანია. API 30-დან VpnManager მხარს უჭერს პლატფორმის VPN პროფილების მიწოდებას და კონტროლს აპლიკაციების მიერ, მოწვევი აპლიკაციაზე მიბმული ავტორიზაციის ნაკადით. ეს არ არის L2TP გარდამქმნელი: პროფილის მოდელი, რომელსაც ის IKEv2-ისთვის აწვდის, არ თარგმნის არსებულ L2TP კონფიგურაციას, და პროტოკოლის შეცვლა მიგრაციაა, არა გადარქმევა. იდენტობები, მარშრუტები, კერძო DNS და წვდომის ნებართვები განზრახ უნდა გადავიდეს.

თუ სერვისი უნდა დარჩეს L2TP/IPsec-ად, მხარდაჭერილი კომბინაციაა კლიენტი და OS-ის გამოშვება, რომელსაც ოპერატორი ნამდვილად ადოკუმენტებს, და მისი ავტომატიზაციის ხელშეკრულება, თუ არსებობს. როცა დოკუმენტირებული უყურადღებო კონტროლი არ არსებობს, სწორი პასუხია მხარდაჭერილი ხელით კავშირი და არა მტვრევადი პრივილეგირებული სკრიპტი, რომელიც შემთხვევით მუშაობს ერთ ბილდზე.

რას აკეთებს სწორი ავტომატიზაცია

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

ჩაწერეთ, რომელი კომპონენტი ფლობს რომელ შრეს, სანამ დაწერთ პირველ ხაზს, და შეამოწმეთ შედეგი ამის მიმართ:

• IPsec-ს და PPP-ს კლიენტი მართავს, არა სკრიპტის მარშრუტები.
• კავშირი ჩნდება პლატფორმის VPN მდგომარეობაში, ამიტომ აპლიკაციის მიხედვით არეალი და always-on მასზე ვრცელდება.
• არც ერთი შიდა სერვისის გამოძახება, ტრანზაქციის ნომერი ან გამოცნობილი არგუმენტი არ ატარებს სერტიფიკატს.
• ნებისმიერ ნაბიჯზე წარუმატებლობა არ ტოვებს ნახევრად რეგისტრირებულ პროფილს.