დეველოპერის დისტანციური წვდომა Google Cloud VPC-ზე: აირჩიეთ გზა

დეველოპერს სჭირდება ერთი SSH სესია, მონაცემთა ბაზის პორტი ან ფართო წვდომა ათეულ კერძო სერვისზე, და ამ მოთხოვნათაგან თითოეული ერთი და იმავე კითხვას ჰგავს. ასე არ არის. დანიშნულებები, პროტოკოლები და ჩართული იდენტობები განსაზღვრავს, რომელი Google Cloud წვდომის გზაა შესაფერისი, ხოლო ნაგულისხმევად ყველაზე ფართოს არჩევა ქმნის საქმეს, რომლის მფლობელიც არ უნდა ყოფილიყავით.

ჩამოწერეთ დანიშნულებები და პროტოკოლები

ჩამოთვალეთ კერძო მისამართები, პორტები და პროტოკოლები, რომლებიც სამუშაოს ნამდვილად სჭირდება, შემდეგ მონიშნეთ, რომელი იდენტობები უნდა დადასტურდეს ცალკე. მონაცემთა ბაზის პორტი და კერძო DNS ზონა სხვადასხვა მოთხოვნაა, ხოლო UDP სერვისი ქვემოთ მოცემული ვარიანტებიდან ერთს მთლიანად გამორიცხავს. წერილობითი სია ასევე აჩვენებს, რასაც არ ანიჭებთ. სწორედ ამ ნაწილზე კითხულობენ რეცენზენტები.

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

IAP რამდენიმე TCP სერვისისთვის

Identity-Aware Proxy-ში TCP გადაგზავნა აძლევს ავთენტიფიცირებულ გვირაბს შესაბამის VM რესურსებამდე სერვისის ინტერნეტში გაუმჟღავნებლად. ყოველდღიური ფორმაა gcloud compute ssh instance-1 --tunnel-through-iap --zone=us-central1-a, და ერთი პორტი ლოკალურად შეიძლება გადაიგზავნოს gcloud compute start-iap-tunnel instance-1 5432 --local-host-port=localhost:15432 --zone=us-central1-a-ით.

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

IAP-ის TCP გადაგზავნა მესამე დონის VPN არ არის. ის TCP-ს გადააქვს არჩეულ დანიშნულებაზე, არა თვითნებურ IP ტრაფიკს ან UDP-ს, და ცუდად შეეფერება, როცა აპლიკაციას სჭირდება კერძო DNS მრავალ სერვისში.

დისტანციური წვდომის VPN უფრო ფართო ხელმისაწვდომობისთვის

როცა საჭიროა რამდენიმე დანიშნულება, პროტოკოლი ან კერძო DNS ზონა, უკეთესი ფორმაა VM-ზე ან მხარდაჭერილ მოწყობილობაზე ცალსახად მართული დისტანციური წვდომის VPN. ეს განლაგება განცალკევებულია Google-ის მართული Cloud VPN-ისგან: თქვენ ფლობთ კლიენტის იდენტობის რეგისტრაციას, პროგრამული განახლებებს, კლიენტის მარშრუტებს და VPC-ის დაბრუნების მარშრუტებს.

დაგეგმეთ მთელი სია, არა მხოლოდ საჯარო მსმენელი. ჩართეთ გვირაბების აუზი, VPC-ის მარშრუტი უკან მისკენ, გადაგზავნის კონტროლი, DNS ამოხსნა და თითო სერვისის წვდომის პოლიტიკა. VPN, რომელიც უკავშირდება, მაგრამ ვერ ხსნის შიდა სახელებს, დეველოპერის სამუშაო პროცესს ისე სრულად ამარცხებს, როგორც ის, რომელიც არასოდეს უკავშირდება.

Cloud VPN არის საიტის კარიბჭე, არა ლეპტოპის პროფილი

Google Cloud VPN აკავშირებს პარტნიორ კარიბჭეებს IPsec-ის მეშვეობით, და მისი ხშირად დასმული კითხვები გამოყოფს ამ საიტ-საიტ როლს კლიენტ-კარიბჭის წვდომისგან. გვირაბის შექმნა არ ქმნის პროფილს, რომელსაც თანამშრომელი ლეპტოპზე შემოიტანს. განსხვავებას მნიშვნელობა აქვს, როცა ვინმე Cloud VPN-ის პროფილს ითხოვს. პასუხი სხვა პროდუქტია.

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

გადაამოწმეთ და ჩაიწერეთ

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

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