სად უნდა იცხოვროს Android-ის firewall-ის წესმა, როცა VPN ჩართულია
მხოლოდ ერთი VpnService შეიძლება იყოს აქტიური, ამიტომ firewall აპი და VPN აპი ერთმანეთზე არ დგას. გაიარეთ ერთი სამუშაო მოთხოვნა და თითოეული წესი იქ დადეთ, სადაც მისი ტრაფიკი ნამდვილად გადის.
თქვენ გაქვთ ერთი წინადადების პოლიტიკა: ამ აპს შეუძლია სამუშაო სერვისამდე მიაღწიოს და სხვა არაფერამდე. შემდეგი კითხვა პროდუქტის არჩევანს ჰგავს, მაგრამ ადგილის კითხვაა, რადგან ყოველი შესაძლო აღსრულების წერტილი ტელეფონის ტრაფიკის სხვადასხვა ნაწილს ხედავს. კარიბჭე ხედავს მხოლოდ იმას, რაც გვირაბში შედის. ტელეფონის მხარეს არსებული ფილტრი ხედავს მხოლოდ იმას, რისი დაკვირვებაც ნებადართულია. ერთი მოთხოვნის ორივეზე გატარება პასუხს ცხადს ხდის.
დაიწყეთ წინადადებით, არა პროდუქტით
გაავრცელეთ მოთხოვნა, სანამ რამეს აირჩევთ. ეს ნიშნავს პაკეტს და პროფილს, რომელშიც ის მუშაობს, რადგან სამუშაო პროფილის აპი სხვა მომხმარებელია, ვიდრე იგივე აპი პირად პროფილში. ეს ნიშნავს დანიშნულებას: ჰოსტი, პორტი და პროტოკოლი, არა სერვისის სახელი. ეს ნიშნავს DNS გზას, რომელიც ამ სახელს წყვეტს, და ნიშნავს, რა უნდა მოხდეს, როცა გვირაბი მიუწვდომელია.
წერილობით, მაგალითის პოლიტიკა ოთხი ხაზია: სამუშაო აპს შეუძლია სამუშაო სერვისამდე მიაღწიოს; სხვა არაფერამდე ვერ მიაღწევს; სხვა აპები უცვლელი რჩება; გვირაბის გარეშე სამუშაო აპს უარყოფენ, პირდაპირ გზაზე დავარდნის ნაცვლად. ყოველ ხაზს ჰყავს მფლობელი და ყველა ერთი და იგივე მფლობელი არ არის.
ნაბიჯი 1: რა შეუძლია თავად ტელეფონს აღასრულოს
Android-ის firewall root-ის გარეშე არის VpnService, რომელიც ტრაფიკს ლოკალურად იჭერს, მაშინაც კი, როცა უკან დისტანციური გვირაბი არ არის. Android ნებას რთავს ერთ აქტიურ VPN სერვისს მომხმარებლის პროფილზე, ამიტომ მეორე firewall აპი პირველის უკან არ ჯაჭვდება. ის მას ცვლის და ინტერფეისი, რომელსაც პირველი აპი ფილტრავდა, ქრება.
ამიტომ VPN კლიენტის გვერდით firewall-ის დაყენება იშვიათად იძლევა იმ კომბინაციას, რომელსაც ხალხი ელის. თუ firewall ირთვება და VPN ითიშება, არაფერი გაერთიანებულა; ორივემ ადგილი შეიცვალა. ინტერფეისის ჩანაცვლება თანამშრომლობა არ არის და სიმპტომია გვირაბი, რომელიც ყოველ ჯერზე ვარდება, როცა მეორე აპი იხსნება.
მხარდაჭერილი ვარიანტები არსებობს: ფილტრაცია ჩაშენებული თქვენს მიერ უკვე გამოყენებულ VPN კლიენტში, მართული პლატფორმის კონტროლი მოწყობილობის პოლიტიკის კონტროლერის ან სამუშაო პროფილის მეშვეობით, ან არქიტექტურა, რომელსაც მწარმოებელი ადასტურებს. დანარჩენი ყველაფერი ექსპერიმენტია, რომელიც ყოველი აპის განახლების შემდეგ ხელახლა უნდა შემოწმდეს.
ნაბიჯი 2: რა შეუძლია კარიბჭეს აღასრულოს
როცა ტრაფიკი შორეულ ბოლოში გაშიფრულია, კარიბჭეს შეუძლია გადაგზავნილი პაკეტები შეზღუდოს დამტკიცებული მისამართებით, სერვისებით ან ავთენტიფიცირებული VPN იდენტობებით. ეს ნამდვილი აღსრულებაა ყველაფრისთვის, რაც იქიდან გადის, და ეს არის სწორი ადგილი კერძო ქვექსელებზე წვდომის შესაზღუდად.
რასაც ის არ იღებს, არის ტელეფონის აპის იდენტობა, რომელიც ყოველ ჩვეულებრივ IP პაკეტს ერთვის. ერთ გვირაბის მისამართს გამზიარებელი რამდენიმე აპი კარიბჭისთვის ერთი სუბიექტია, თუ დიზაინი მათ ცალკე მისამართებს ან ცალკე ავთენტიფიცირებულ იდენტობებს არ აძლევს. ამიტომ კარიბჭეზე მომხმარებლის მიხედვით წესი ტელეფონზე აპის მიხედვით წესი არ არის, როგორც არ უნდა უწოდოს მას მართვის კონსოლმა.
ნაბიჯი 3: ჩამოთვალეთ, რაც არასდროს ჩამოდის
VPN-იდან გამორიცხული აპი, რომელიც ახლო მოწყობილობას უკავშირდება, კარიბჭემდე არასდროს აღწევს, ამიტომ გამავალი firewall ვერ უარყოფს პაკეტს, რომელსაც არასდროს იღებს. იგივე ეხება შეფერხების დროს განზრახვის გარეშე წარმოქმნილ პირდაპირ გზას და ლოკალურ წვდომის ქსელში შემომავალ ზემოქმედებას. ეს განმარტებით ლოკალური საზღვრებია.
საპირისპიროც მართალია: კავშირის ნებადამრთველი ლოკალური წესი წვდომას არ იძლევა კარიბჭის კერძო ქსელის ACL-ის მეშვეობით. ერთი მოთხოვნა შეიძლება ორივე საზღვრის ქვეშ იყოს და ერთის დაკმაყოფილება მეორეზე არაფერს ამბობს.
ნაბიჯი 4: თითოეული წესი გზას მიაკუთვნეთ
გადაწყვეტილება ცხრილში ჩადეთ, სანამ რამეს დააკონფიგურირებთ, რადგან ცარიელი უჯრებია ადგილი, სადაც დიზაინები ფარდებიან.
| გზა | ვის შეუძლია აღასრულოს | ბრმა წერტილი |
|---|---|---|
| სამუშაო აპი სამუშაო სერვისამდე, გვირაბი ჩართული | კარიბჭის ACL მისამართსა და სერვისზე, პლუს ლოკალური ბლოკირება სხვა გზებზე | კარიბჭე ვერ ხედავს, რომელმა აპმა გაგზავნა პაკეტი |
| სამუშაო აპი სხვა დანიშნულებებზე, გვირაბი ჩართული | აპის გაცნობიერებული ლოკალური ფილტრი, ან კარიბჭე, თუ ეს დანიშნულებები იქ არის მისამართებული | ლოკალური ფილტრი უნდა იყოს აქტიური VpnService |
| სამუშაო აპი გვირაბის გარეშე | ლოკალური უარი, რათა აპმა პირდაპირი გზა ვერ აიღოს | მოითხოვს, რომ ფილტრმა გვირაბის გაქრობა გადაიტანოს |
| ახლო LAN მოწყობილობა | მხოლოდ ლოკალური პოლიტიკა | კარიბჭე მას არასდროს ხედავს |
მომუშავე ფორმა ორი საზღვარია ორი ამოცანით. აპის გაცნობიერებული ლოკალური საზღვარი მართავს ტელეფონის ქცევას, მათ შორის პირდაპირ დავარდნას, ხოლო კარიბჭის საზღვარი მართავს დისტანციურ რესურსებს. კარიბჭის მხარეს შეუძლია სამუშაო სერვისის დაშვება და ყოველი სხვა კერძო ქვექსელის უარყოფა, ხოლო ტელეფონის მხარეს პოლიტიკა თავად წყვეტს პირდაპირი გზის საკითხს, რომელსაც აპი სხვაგვარად აიღებდა.
ნაბიჯი 5: შეინარჩუნეთ ტრანსპორტი ცოცხალი და შემდეგ შეამოწმეთ
რომელი ლოკალური პოლიტიკაც არ უნდა აირჩიოთ, მან უნდა დაუშვას ტრანსპორტი, რომელიც VPN-ს ამყარებს და ინარჩუნებს. ამ ტრანსპორტის ბლოკირება ტელეფონს ტოვებს გვირაბისა და პოლიტიკის გარეშე, რაც არაფერს ასრულებს თანმიმდევრულად და ძნელად დიაგნოსტირდება, რადგან აპს უბრალოდ ქსელი არ აქვს.
შემდეგ შეამოწმეთ საწყისი წინადადების თითოეული ხაზი და არა საერთო შთაბეჭდილება: სამუშაო აპი აღწევს სამუშაო სერვისამდე, იმავე აპს უარყოფენ სხვა დანიშნულებაზე, არასამუშაო აპი ისე იქცევა, როგორც ადრე, და გაჩერებული გვირაბით სამუშაო აპი პირდაპირ კავშირზე არ ვარდება. DNS გზა ცალკე შეამოწმეთ, რადგან კერძო DNS ან დაშიფრული გადამწყვეტი შეიძლება გვერდი აუაროს ფილტრს, რომელიც მხოლოდ მისამართებს ამოწმებს.
თუ ამ ნაბიჯებიდან ერთი მაინც ვერ სრულდება ტელეფონზე, მოთხოვნა არქიტექტურის კითხვაა და არა firewall-ის პარამეტრი. პოლიტიკის გაყოფა თქვენ მიერ კონტროლირებულ მოწყობილობასა და კარიბჭეს შორის ჩვეულებრივ პატიოსანი პასუხია, და Android VPN კავშირის დოკუმენტაცია არის ადგილი, სადაც ადასტურებთ, რას დაუშვებს და რას არ დაუშვებს პლატფორმა ერთ სერვისზე.