Cloud SQL-ის კერძო IP VPN-ის გავლით: მარშრუტი, რომელსაც არავინ აექსპორტებს

ბევრი გუნდი ფიქრობს, რომ Cloud SQL-ის კერძო IP მუშაობს მხოლოდ VPC-ის შიგნიდან და ეს რწმენა ძლებს, რადგან წარუმატებლობა მონაცემთა ბაზის პრობლემას ჰგავს. Google ადასტურებს წვდომას ქსელებიდან, რომლებიც დაკავშირებულია Cloud VPN-ით ან Cloud Interconnect-ით. ამ ქსელებს არ სჭირდება მონაცემთა ბაზის განსაკუთრებული ფუნქცია, არამედ ორი მარშრუტის გაცვლა, რომლებიც ადვილია ნახევრად კონფიგურირებულად დარჩეს. გვირაბი ადის, გამოთვლითი ინსტანსები პასუხობენ და მონაცემთა ბაზის კავშირი დროის ლიმიტს აჭარბებს — სწორედ ის კომბინაცია, რომელიც ხალხს არასწორ კონსოლში აგზავნის.

მითი: კერძო IP ნიშნავს VPC-ისთვის კერძოს

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

რადგან ეს peering-ია, მას peering-ის ქცევაც აქვს, მათ შორის ის ნაწილი, სადაც მორგებული მარშრუტები ავტომატურად არ გადადის.

მითი: მომუშავე გვირაბი მონაცემთა ბაზის მარშრუტს თან მიაქვს

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

Google-ის მხარეს ეს ნიშნავს Export custom routes-ის ჩართვას შესაბამის peering-კავშირებზე და გამოყოფილი სერვისის დიაპაზონის დამატებას გვირაბისთვის Cloud Router-ის გამოცხადებულ მარშრუტებში.

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

მითი: Cloud SQL Auth Proxy ქსელს აგვარებს

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

რასაც ის არ აკეთებს, არის გათიშული ლეპტოპის მხოლოდ კერძო ინსტანსამდე მიყვანა.

მითი: Private Service Connect იგივე წესებს მიჰყვება

Private Service Connect იყენებს endpoint-ს თქვენს ქვექსელში და DNS მოწყობას, რომელსაც თქვენ აკონტროლებთ, ამიტომ მასთან მიმავალი მარშრუტი ჩვეულებრივი მარშრუტია თქვენს საკუთრებაში არსებულ მისამართამდე. peering-ის ექსპორტის პარამეტრები ამ დიზაინზე არ ვრცელდება, და peering-ის ცვლილებების PSC განლაგებაში კოპირება რისკს უმატებს ხელმისაწვდომობის დამატების გარეშე.

ორივე გაძლევთ კერძო მისამართს; მსგავსება იქ მთავრდება.

გამოსცადეთ მარშრუტი სწორი თანმიმდევრობით

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

თუ თქვენი კლიენტის დიაპაზონები RFC 1918-ის გარეთაა, გადახედეთ მარშრუტის ექსპორტისა და ქსელის ავტორიზაციის დამატებით მოთხოვნებს, სანამ დაასკვნით, რომ დიზაინი მხარდაჭერილი არ არის.

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