სამი მისამართის გადაწყვეტილება, სანამ IoT სენსორებს VPN-ის უკან განათავსებთ
სამი მისამართი სამ სამუშაოს ასრულებს: საჯარო კვანძი, ავთენტიფიცირებული საიტის წყვილი და სენსორის კერძო მისამართი. დაგეგმეთ თითოეული, სანამ რაიმე საჯაროს გამოყოფთ.
სამი მისამართი ერთმანეთში ირევა ყოველ IoT-VPN გეგმაში და ისინი ერთი ტიპის გადაწყვეტილება არ არის. ერთი არის, როგორ პოულობს დისტანციური ოპერატორი გვირაბის ბოლო წერტილს, მეორე — როგორ ამტკიცებს საიტი, რომ სწორედ ის არის საიტი, და მესამე — სად უსმენს რეალურად სენსორის სერვისი. უპასუხეთ მათ ამ თანმიმდევრობით და დიზაინი თითქმის თავისით გამოვა. უპასუხეთ როგორც ერთ კითხვას და მიხვალთ იქამდე, რომ საჯარო მისამართებს ანიჭებთ მოწყობილობებს, რომლებსაც ეს არასდროს სჭირდებოდათ. გამავალი საიტის გვირაბის უკან მყოფი სენსორი ხელმისაწვდომია უფლებამოსილი ოპერატორისთვის სენსორზე მიმართული შემომავალი წესის გარეშე.
დაიწყეთ იმით, თუ ვინ იწყებს
ვინ ურეკავს, თითქმის ყველაფერს წყვეტს შემდგომში. როცა საიტი კვანძს ურეკავს, საიტს შემომავალი ხელმისაწვდომობა არ სჭირდება, ხოლო კვანძს სჭირდება სახელი ან მისამართი, რომელსაც საიტი ამოხსნის. ეს ერთი არჩევანი აშორებს სტატიკური საჯარო მისამართების დავის უმეტეს ნაწილს დაწყებამდე.
შემდეგ სამი როლი სუფთად იყოფა და ქვემოთ მოცემული ცხრილი გადაწყვეტილების უმოკლესი ფორმაა.
| Decision | What you are actually choosing | Usual default |
|---|---|---|
| Hub endpoint | How the tunnel service is published | A DNS name, no inbound rule toward the site |
| Site peer | How the site proves its identity and which prefixes it carries | One key pair or certificate per site, prefix in the tunnel config |
| Sensor service | How the application is addressed inside the site | A stable private address from the site plan |
თითოეულ სტრიქონს სხვა მფლობელი ჰყავს და ეს არის ნამდვილი აზრი. კვანძი ეკუთვნის მას, ვინც VPN სერვისს მართავს, საიტის წყვილი — ქსელის გუნდს, ხოლო სენსორის მისამართი — მას, ვისაც მოწყობილობა აქვს.
კვანძის მისამართი გაშვებაა და არა დანიშნულება
შენახული საჯარო მისამართისკენ ამოხსნადი სახელი კვანძისთვის საკმარისია. DNS ჩანაწერს შეუძლია ბოლო წერტილს მიჰყვეს, როცა ის გადაადგილდება, ყოველი საიტის კონფიგურაციის ხელით რედაქტირების გარეშე. რასაც DNS არ აკეთებს, ეს არის ხელმისაწვდომობის შექმნა ან ძველი პასუხის ქეშირებადი კლიენტის განახლება, და ეს ცალკე პრობლემებია ცალკე გადაწყვეტებით.
თუ მართავთ საიტ-საიტ გვირაბებს კვანძის გარეშე, იგივე ლოგიკა სხვა ფორმით მოქმედებს: ერთ მხარეს სჭირდება ხელმისაწვდომი ბოლო წერტილი, ან ორივე მხარე მესამე მხარეს ურეკავს. ვიღაც მაინც უნდა ფლობდეს ამ მისამართს და მის განახლებებს.
საიტის წყვილი იდენტობაა მიმაგრებული პრეფიქსით
წყვილი ჯერ იდენტობაა, შემდეგ პრეფიქსი. WireGuard-ის ტერმინებში წყვილი ინახავს გასაღების წყვილს და კვანძის AllowedIPs ჩანაწერი ამ გასაღებს საიტის პრეფიქსს უკავშირებს. IKEv2-ის ტერმინებში სერტიფიკატი ან წინასწარ გაზიარებული გასაღები იდენტიფიცირებს საიტს და მისი ტრაფიკის სელექტორები ამბობენ, რისი გადატანა შეუძლია. მხოლოდ ერთი ნახევრის შეცვლა არღვევს წყობას და ამიტომ მისამართის ცვლილება არასდროს უნდა განიხილებოდეს იდენტობის ცვლილებად.
გასაღების ან სერტიფიკატის მფლობელობა შეინახეთ საიტთან და არა კვანძის ოპერატორთან, რათა პროვაიდერის შეცვლა იდენტობის შეცვლად არ იქცეს.
პრეფიქსი ის ნაწილია, რომლის დაგეგმვასაც ადამიანები ივიწყებენ. კვანძმა სენსორის ქვექსელი სწორ წყვილს უნდა დაუკავშიროს და ოპერატორის კლიენტს ამისკენ მარშრუტი სჭირდება; მარშრუტი, რომელიც მხოლოდ კლიენტზე არსებობს, ტრაფიკს ჩუმად ჩამომყრელ გვირაბში აგზავნის. ჩაწერეთ პრეფიქსი საიტის ჩანაწერში გასაღების ანაბეჭდის გვერდით, რათა შემცვლელმა კარიბჭემ ვერ შეძლოს შეუმჩნევლად სხვა დაფარვით ამოსვლა.
სენსორის მისამართი აპლიკაციას ეკუთვნის
საიტის გეგმიდან კერძო მისამართი საკმარისია და მას სჭირდება სტაბილურობა და არა საჯარო ხელმისაწვდომობა: DHCP დაჯავშნა, სტატიკური მინიჭება ან სახელი საიტის საკუთარ ზონაში. თუ მოწყობილობის ხელახლა დანომრვა შეუძლებელია, საიტის კარიბჭეზე თარგმანი ლეგიტიმური პასუხია, სანამ თარგმანი დოკუმენტირებულია და დაბრუნების ტრაფიკი მას მიჰყვება.
კიდევ ერთი ჩვევა, რომლის შენარჩუნებაც ღირს: არასდროს ჩასვათ კვანძის საჯარო მისამართი სენსორის ჰოსტის შემდეგი ნახტომის ველში. VPN საკუთარ გზას ამონტაჟებს და საჯარო ბოლო წერტილის მიმართ ჩვეულებრივი Ethernet სიახლოვე ფიქციაა, რომელიც დამაჯერებლად გამომხედავ კონფიგურაციას ქმნის.
პასუხები ის ნახევარია, რომელიც გამოტოვებულია. მოწყობილობამ თავისი პასუხი უკან გვირაბისკენ უნდა გაგზავნოს, ან ოპერატორის კლიენტამდე მარშრუტით, ან იმავე კარიბჭის გავლით, რომელმაც მოთხოვნა თარგმნა. არასწორი ნაგულისხმევი კარიბჭის მქონე სენსორი იღებს მოთხოვნას და პასუხობს სიცარიელეში, ხოლო გადამისამართების შენიშვნები ხსნის, რატომ არის ჩამოსვლა და პასუხის მარშრუტიზაცია ორი მოთხოვნა და არა ერთი.
გადაწყვიტეთ და შემდეგ დაწერეთ საზღვარი
ჩამოწერეთ წვდომის საზღვარი, სანამ ვინმე დაუკავშირდება. შეზღუდეთ კარიბჭე IoT სეგმენტით და კონკრეტული სერვისებით, რომლებიც ოპერატორს სჭირდება, რადგან მომუშავე მარშრუტი უბედური შემთხვევით ზოგად წვდომად იქცევა. შეინახეთ მხოლოდ-კითხვის მონიტორინგი და კონფიგურაციის უფლება ცალკე როლებად ცალკე იდენტობებით და დაასახელეთ ადამიანი, რომელიც ხელშეკრულების დასრულებისას წვდომას ხსნის.
დამტკიცება ქსელის მფლობელს ეკუთვნის და DMZ-ში ყოფნა წვდომის პოლიტიკა არ არის.
განლაგების შემდეგ ტესტი მოსაწყენი და გადამწყვეტია: ერთი მოთხოვნა დაშვებული პრეფიქსის შიგნით, რომელიც წარმატებით სრულდება, კარიბჭეზე მზარდი მრიცხველი და ერთი განზრახ მცდელობა პრეფიქსის გარეთ, რომელიც მარცხდება.