მიეცით VPN მომხმარებლებს წვდომა ერთ სერვისზე და არა ქვექსელზე
ვიწრო მარშრუტი ავტორიზაციის პოლიტიკა არ არის. გადაწყვიტეთ, სად არის აღსრულება, რომელ წყაროს ხედავს სერვისი და როგორ რჩება აპის როლები ცალკე.
კონტრაქტორს სჭირდება ერთი შიდა ვებ აპლიკაცია და მეტი არაფერი, და მარტივი პასუხია, მივცეთ მას გვირაბი სერვერის ქვექსელში. ეს მუშაობს იმ დღემდე, სანამ ის დაასკანირებს. უფრო ვიწრო დიზაინი მეტ ფიქრს მოითხოვს, რადგან ხელმისაწვდომობა, მარშრუტიზაცია და აპლიკაციის ნებართვა სამი ცალკე კონტროლია, რომლებიც უნდა შეთანხმდნენ.
მოთხოვნა დაწერეთ როგორც სერვისი, და არა ქვექსელი
დაიწყეთ დანიშნულების ჰოსტით, პროტოკოლით და პორტით, შემდეგ დაამატეთ მომხმარებლის ან მოწყობილობის ჯგუფი, რომელმაც უნდა მიაღწიოს მას. კერძო DNS ზონა ჩართეთ მხოლოდ მაშინ, თუ აპლიკაცია წყვეტს სახელს, და იდენტობის მომწოდებელი მხოლოდ მაშინ, თუ შესვლის ნაკადს სჭირდება. დანარჩენი ყველაფერი დამოკიდებულებაა, რომელიც ჯერ არ გაქვთ დასაბუთებული.
ქვექსელი ქსელის გუნდის განხორციელების დეტალია, ხოლო სერვისი არის ის, რაც ბიზნესმა მოითხოვა, და ერთეული, რომლის განხილვაც და გაუქმებაც შეიძლება.
თუ დამოკიდებულებების სია სამ ერთეულს სცდება, აპლიკაციას, სავარაუდოდ, საკუთარი დიზაინის საუბარი სჭირდება.
მარშრუტიზაცია ვიწროდ, მაგრამ აღსრულება სხვაგან
ვიწრო მარშრუტი ან სელექტორი გვირაბს ეუბნება, რომელი პაკეტები გადაიტანოს; ეს ავტორიზაციის პოლიტიკა არ არის. კარიბჭის ფილტრი, დანიშნულების ჰოსტის ფაირვოლი და თავად აპლიკაციის ნებართვების მოდელი არის ის ადგილები, სადაც წვდომა წყდება. ერთ მისამართს დაფარვის მარშრუტი კარგი დასაწყისია და ეს არ არის ის კონტროლი, რომელიც გადაწყვეტილი მომხმარებლის შეჩერებას ახერხებს. სწორედ ეს განცალკევება გაძლევთ საშუალებას შეცვალოთ ფილტრი გვირაბის გადაპროექტების გარეშე.
პირიქით, ფართო მარშრუტი მკაცრი ფილტრით შეიძლება ლეგიტიმური იყოს, მაგრამ მხოლოდ მაშინ, თუ ყველა ჩართული იცის, რომელი მათგანი ასრულებს აღსრულებას.
დააფიქსირეთ აღსრულების წერტილი ცხადად, თორემ შემდეგი ცვლილება შემთხვევით გადააადგილებს მას.
შეამოწმეთ ის წყარო, რომელსაც სერვისი რეალურად ხედავს
სამიზნე ხედავს ან კლიენტის პულის მისამართს, ან კარიბჭის მისამართს, იმის მიხედვით, თარგმნით თუ არა. ჰოსტის ფაირვოლის წესები და ჟურნალები უნდა შეესაბამებოდეს რეალურ წყაროს. თუ რამდენიმე მომხმარებელი იზიარებს თარგმნილ წყაროს, ამ ჰოსტზე არც ერთი მომხმარებლის წესი ვერ განასხვავებს მათ, და ეს დიზაინის შეზღუდვაა, არა ხარვეზი.
აირჩიეთ თარგმნა განზრახ: ის ამარტივებს მარშრუტიზაციას და ანადგურებს წყაროს იდენტობას, რაც მნიშვნელოვანია აუდიტისთვის და მომხმარებლის წესებისთვის.
ჩაწერეთ, ორიდან რომელი აირჩიეთ, იმ წესის გვერდით, რომელიც მასზეა დამოკიდებული.
აპლიკაციის ავტორიზაცია სავალდებულოა
პორტამდე მიღწევა როლს არ ანიჭებს. აპლიკაციას მაინც სჭირდება საკუთარი შესვლა და საკუთარი ნებართვები, რადგან ქსელის დონე ვერ გამოხატავს, რომელი ჩანაწერების რედაქტირება შეუძლია მომხმარებელს. სერვისი, რომელიც ენდობა შიდა ქვექსელიდან მოსულ ყველა მოთხოვნას, ვიწრო გვირაბს სრულ წვდომად აქცევს ერთი კომპრომიტირებული სანდოობის მონაცემისთვის. გვირაბი წყვეტს, ვის შეუძლია სოკეტის გახსნა, და აპლიკაცია წყვეტს, რა შეიძლება გაკეთდეს მასთან.
აქ ვიწრო დიზაინი ორჯერ იხდის თავს, რადგან ნაკლები ხელმისაწვდომი ჰოსტი ნიშნავს ნაკლებ ადგილს, სადაც აპლიკაციის დონის შეცდომა შეიძლება გამოიყენონ.
შეინახეთ ქსელის წესი და აპლიკაციის როლი ცალკე სისტემებში და ცალ-ცალკე გააუქმეთ ისინი.
დაამტკიცეთ როგორც დაშვებული, ისე უარყოფილი გზა
დაუკავშირდით ავტორიზებულ მომხმარებლად და შეასრულეთ ერთი უვნებელი წარმომადგენლობითი ოპერაცია, შემდეგ სცადეთ დანიშნულება, რომელიც მიუწვდომელი უნდა იყოს. დიზაინი, რომელიც მხოლოდ პირველ ნახევარს ამოწმებს, შემოწმებული არ არის, და სწორედ უარყოფის ტესტი ამტკიცებს დიზაინს. ყოველი წესის ცვლილების შემდეგ სცადეთ ახალი სესია, და თუ მოთხოვნები მოდის, პასუხები კი არა, შეხედეთ დაბრუნების გზას.
ნუ გამორთავთ გადაგზავნის ფილტრებს მისაღები ტესტის გასავლელად, რადგან ეს ცვლის იმას, რაც მოწმდება.
როცა მომხმარებელს სერვისი აღარ სჭირდება, გააუქმეთ დისტანციური იდენტობა და აპლიკაციის როლი მათ შესაბამის სისტემებში, და ჩაწერეთ ორივე. strongSwan-ის გადაგზავნის სახელმძღვანელო მოიცავს გზის კარიბჭის მხარეს.