App Engine-ს შეუძლია თქვენს VPN მონაცემთა ბაზამდე მისვლა: რა უნდა დაემთხვეს

მტკიცება, რომ App Engine Standard ვერ აღწევს კერძო მონაცემთა ბაზამდე Cloud VPN-ის გავლით, პლატფორმის წინა თაობის ნაშთია. Standard ინსტანსები არ იღებენ VPC-ის მშობლიურ მისამართს, როგორც ზოგიერთი სხვა გაშვების გარემო, მაგრამ მათ შეუძლიათ egress-ის გაგზავნა თქვენს ქსელში არსებული Serverless VPC Access კონექტორის გავლით. როცა ეს გზა არსებობს, Cloud VPN და დისტანციური firewall კონექტორის ტრაფიკს ხედავენ როგორც ნებისმიერ სხვა წყაროს. რაც ვერ ხერხდება, იშვიათად თავად შესაძლებლობაა. ეს სამი პარამეტრიდან ერთია, რომლებიც არასდროს გასწორდა.

საიდან მოვიდა ძველი პასუხი

სანამ კონექტორები არსებობდნენ, პრაქტიკული პასუხი მართლაც ის იყო, რომ Standard-ს მხოლოდ საჯარო ბოლო წერტილებთან საუბარი შეეძლო, და გუნდები გადადიოდნენ proxy VM-ზე ან სხვა გაშვების გარემოზე, რომ ეს აევლოთ. პლატფორმა შეიცვალა, ფოლკლორი არა. ბევრი ონლაინ რჩევა დღემდე იმ ეპოქას ასახავს, როცა egress-ის არჩევანი საერთოდ არ არსებობდა.

შესწორება უფრო ვიწროა, ვიდრე ჟღერს. Standard-ს შეუძლია კერძო ქსელამდე მისვლა, მაგრამ მხოლოდ მხარდაჭერილი egress ინტეგრაციის გავლით და მხოლოდ იმ დანიშნულებებამდე, რომლებსაც ეს ინტეგრაცია ნამდვილად იჭერს.

ჯერ აირჩიეთ egress-ის გზა

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

vpc_access_connector:
  name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME
  egress_setting: private-ranges-only

private-ranges-only კერძო დანიშნულებებს VPC-ში აგზავნის და დანარჩენს ჩვეულებრივ ინტერნეტ გზაზე ტოვებს, რაც ჩვეულებრივ სჭირდება მონაცემთა ბაზის კავშირს. all-traffic გამავალ ტრაფიკს ფართოდ უტარებს VPC-ის გავლით, ამიტომ ჩვეულებრივი ინტერნეტ გამოძახებებიც მემკვიდრეობით იღებენ VPC-ის NAT-ს და firewall-ის პოზიციას.

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

წყაროს მისამართი კონექტორია, და არა თქვენი ლეპტოპი

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

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

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

DNS სხვა გზით მოძრაობს

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

თუ სახელი VPC-ის შიგნიდან საჯარო მისამართზე გადაწყდა, არასწორ firewall-ს აპირებთ გამართოთ.

URL Fetch კონექტორს არ იყენებს

egress-ის პარამეტრი ფარავს გაშვების გარემოს ჩვეულებრივ გამავალ სოკეტებს, და მემკვიდრეობითი URL Fetch სერვისი ამ გზის ნაწილი არ არის. urlfetch-ით გამოშვებული მოთხოვნა უგულებელყოფს კონექტორს, რაც არ უნდა თქვას კონფიგურაციამ. როცა წარუმატებელი გამოძახება ძველ ბიბლიოთეკაშია, რომელიც ჯერ კიდევ URL Fetch-ს იყენებს, გამოსავალია ამ გამოძახების სტანდარტულ HTTP კლიენტზე გადატანა.

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

შეამოწმეთ ერთი ვიწრო მოთხოვნით

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

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