Cloud SQL Auth Proxy ან პირდაპირი VPN მარშრუტი მონაცემთა ბაზისკენ
Auth Proxy და პირდაპირი VPN მარშრუტი ერთი და იმავე პრობლემის სხვადასხვა ნახევარს წყვეტს. ჯერ შეადარეთ connector-ის ავტორიზაცია, პორტები და მონაცემთა ბაზაში შესვლა.
VPN-ში მყოფი ლეპტოპიდან კერძო Cloud SQL ინსტანსამდე მისვლის ორი გონივრული გზა არსებობს. ერთი არის პირდაპირი კავშირი ინსტანსის კერძო მისამართზე იმ მარშრუტით, რომელიც უკვე გაქვთ. მეორე არის Cloud SQL Auth Proxy, რომელიც loopback-ზე უსმენს და თავად ხსნის კავშირს Cloud SQL-თან. ეს უფრო ნაკლებად კონკურენტი პროდუქტებია და უფრო მეტად ორი განსხვავებული პასუხი კითხვაზე, ვის უჭირავს სერტიფიკატი და ვის მარშრუტი. არასწორი არჩევანი ჩვეულებრივ ავტორიზაციის შეცდომად ვლინდება, რომელიც ქსელურ შეცდომად იკითხება.
აი ის შედარება, რომელსაც გუნდის წინ დავდებდი, და მის შემდეგ ის შემოწმებები, რომლებიც რეალურად წყვეტს საკითხს.
ორი გზა ერთსა და იმავე ინსტანსამდე
პირდაპირი გზა იყენებს private-services-access მარშრუტს თქვენი ქსელიდან პროექტის VPC-ში. თქვენი კლიენტი PostgreSQL-ით ესაუბრება ინსტანსის კერძო მისამართს და კავშირი ცოცხლობს ან კვდება მარშრუტიზაციაზე, firewall წესებსა და მონაცემთა ბაზის სერტიფიკატებზე.
proxy-ის გზა იმავე მარშრუტს იყენებს, მაგრამ ამატებს ლოკალურ პროცესს. proxy ავთენტიფიცირდება Google API-სთან თქვენი აპლიკაციის default credentials-ით, connector-ის მეშვეობით ხსნის კავშირს ინსტანსთან და აძლევს loopback პორტს, რომელსაც თქვენი კლიენტი PostgreSQL-ად მიიჩნევს. ორი ნახტომი სამი ხდება და შუა IAM ავტორიზაციას ატარებს. VPN მარშრუტი მაინც თქვენი მოსავლელია და proxy მას არასოდეს თვლის ამ შემოწმების შემცვლელად.
რას ავტორიზებს სინამდვილეში თითოეული გზა
ყველაზე მნიშვნელოვანი განსხვავება ის არის, რისი ავტორიზება შეუძლია თითოეულ ვარიანტს თქვენ ნაცვლად:
| Question | Direct private IP | Auth Proxy |
|---|---|---|
| Who proves identity to the network | Your client, through the VPN and a database login | The proxy, through IAM to Google's API |
| IAM role needed for the connector | None | Cloud SQL Client or equivalent |
| Database user authentication | Always required | Still required unless IAM database authentication is enabled |
| Shape of the local leg | Client to instance | Client to loopback, proxy to instance |
proxy-ის IAM შემოწმება და მონაცემთა ბაზაში შესვლა ორი ცალკე ჭიშკარია და ერთში გავლა მეორეს არ ხსნის. გუნდი, რომელიც proxy-ს ჩართავს და ჩათვლის, რომ აპლიკაციის ანგარიში აღარ არის საჭირო, ნახევარ დღეს გაატარებს პაროლის წარუმატებლობებზე, რომლებსაც ქსელთან არანაირი კავშირი არ აქვს.
პორტები და მარშრუტები, გვერდიგვერდ
proxy-ს სჭირდება გამავალი TCP 443 API-სთვის და TCP 3307 ინსტანსის კავშირისთვის, ორივე აღწერილია Google-ის Auth Proxy-ის მიმოხილვაში. თქვენი VPN მარშრუტი მეორეს ფარავს; პირველი ჩვეულებრივ ჩვეულებრივი გზით გადის.
პირდაპირი კავშირი მოითხოვს, რომ ინსტანსის PostgreSQL პორტი კერძო მარშრუტით ხელმისაწვდომი იყოს, რაც სულ სხვა firewall საუბარია. თუ თქვენი ქსელის გუნდი კლიენტის ქვექსელებიდან მხოლოდ 443-ის გასვლას უშვებს, proxy ეტევა წესის შეცვლის გარეშე, პირდაპირი გზა კი არა. სწორედ ეს ერთი ფაქტი წყვეტს არჩევანს უფრო ხშირად, ვიდრე ნებისმიერი არქიტექტურული უპირატესობა.
არც ერთი გზა არ მოითხოვს, რომ ინსტანსს საჯარო მისამართი ჰქონდეს და არც ერთი არ ამართლებს მის დამატებას.
სადაც proxy არ ეხმარება
proxy არ ასწორებს დაკარგულ მარშრუტს. თუ private-services-access მარშრუტი არ არსებობს, ან VPN მას არ გადააქვს, connector ვარდება, მაშინ როცა ლოკალური მსმენელი ჯერ კიდევ იქ ზის და უსმენს, და სწორედ ეს არის დამაბნეველი ნაწილი.
ის ასევე არ იცავს თქვენს აპლიკაციასა და proxy-ს შორის მონაკვეთს. ერთ ლეპტოპზე ეს მონაკვეთი loopback-ია და რიგზეა. თუ მსმენელს wildcard მისამართზე მიაბამთ, რომ კოლეგამ მას მიაღწიოს, თქვენ ააგეთ აუთენტიფიკაციო მონაცემთა ბაზის კარიბჭე და უწოდეთ მას მოხერხებულობა. დატოვეთ ის loopback-ზე და მიეცით კოლეგას საშუალება, საკუთარი სერტიფიკატი მოიპოვოს.
და ის Private Service Connect-სა და private services access-ს ურთიერთშემცვლელს არ ხდის. PSC ინსტანსს სჭირდება საკუთარი DNS მოწყობა და --psc გამოძახება --private-ip ფორმის ნაცვლად.
არჩევა და შემდეგ ყოველ შემთხვევაში შემოწმება
აირჩიეთ proxy, როცა გსურთ IAM გზაზე, მოკლევადიანი სერტიფიკატები და შემომავალ firewall-ში ცვლილების გარეშე.
აირჩიეთ პირდაპირი მარშრუტი, როცა მხარდაჭერილ კლიენტს უკვე აქვს ძლიერი მონაცემთა ბაზის სერტიფიკატები და ქსელის გუნდი მზადაა პორტი გახსნას. ყოველ შემთხვევაში შეამოწმეთ ნამდვილი მოთხოვნით და არა წარმატებული კავშირით: დაუკავშირდით, შეასრულეთ ერთი კითხვა ცნობილ ცხრილზე და ნახეთ, რას ხედავს სერვერი თქვენი სესიის შესახებ.
VPN-ის ხელახლა დაკავშირების შემდეგ ვადაგასული სერტიფიკატი, დაკარგული კერძო მარშრუტი და მონაცემთა ბაზაში შესვლის უარყოფა სამ სხვადასხვა წარუმატებლობად მიიჩნიეთ. მათგან მხოლოდ ერთია ქსელური პრობლემა და მხოლოდ ერთმა უნდა გამოიწვიოს ოდესმე firewall წესის შეცვლა.