Το App Engine μπορεί να φτάσει τη βάση δεδομένων σας μέσω VPN: τι πρέπει να ταιριάζει

Ο ισχυρισμός ότι το App Engine Standard δεν μπορεί να φτάσει μια ιδιωτική βάση δεδομένων μέσω Cloud VPN είναι κατάλοιπο από μια παλαιότερη γενιά της πλατφόρμας. Οι παρουσίες Standard δεν παίρνουν διεύθυνση εγγενή στο VPC όπως ορισμένα άλλα περιβάλλοντα εκτέλεσης, αλλά μπορούν να στέλνουν έξοδο μέσω ενός connector του Serverless VPC Access που ζει στο δίκτυό σας. Μόλις υπάρξει αυτή η διαδρομή, το Cloud VPN και το απομακρυσμένο firewall βλέπουν την κίνηση του connector όπως κάθε άλλη πηγή. Αυτό που αποτυγχάνει σπάνια είναι η ίδια η δυνατότητα. Είναι μία από τρεις ρυθμίσεις που δεν ευθυγραμμίστηκαν ποτέ.

Από πού προήλθε η παλιά απάντηση

Πριν υπάρξουν οι connectors, η πρακτική απάντηση ήταν όντως ότι το Standard μπορούσε να μιλά μόνο με δημόσια endpoints, και οι ομάδες μετακινούσαν σε proxy VM ή άλλο περιβάλλον εκτέλεσης για να το παρακάμψουν. Η πλατφόρμα άλλαξε, ο μύθος όχι. Πολλές συμβουλές στο διαδίκτυο εξακολουθούν να αντανακλούν την εποχή που δεν υπήρχε καθόλου επιλογή εξόδου.

Η διόρθωση είναι στενότερη απ' όσο ακούγεται. Το Standard μπορεί να φτάσει το ιδιωτικό δίκτυο, αλλά μόνο μέσω υποστηριζόμενης ενσωμάτωσης εξόδου και μόνο για προορισμούς που αυτή η ενσωμάτωση καταγράφει πραγματικά.

Επιλέξτε πρώτα τη διαδρομή εξόδου

Ένας connector συνδεδεμένος στην υπηρεσία είναι αυτό που βάζει την κίνησή της στο VPC. Η τεκμηρίωση του connector απαριθμεί την περιφερειακή προϋπόθεση και τις ρυθμίσεις εξόδου· ο connector πρέπει να υπάρχει στην περιοχή της υπηρεσίας και να είναι χρησιμοποιήσιμος από την ταυτότητα ανάπτυξης.

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

Το private-ranges-only στέλνει ιδιωτικούς προορισμούς στο VPC και αφήνει όλα τα άλλα στην κανονική διαδρομή του διαδικτύου, που συνήθως είναι ό,τι χρειάζεται μια σύνδεση βάσης δεδομένων. Το all-traffic σπρώχνει την εξερχόμενη κίνηση ευρέως μέσα από το VPC, οπότε οι συνηθισμένες κλήσεις στο διαδίκτυο κληρονομούν επίσης τη στάση NAT και firewall του VPC.

Η τοπική επεξεργασία του αρχείου δεν αλλάζει τίποτα μέχρι να κάνετε deploy. Μια έκδοση που εκτελείται διατηρεί τη διαμόρφωση με την οποία δημιουργήθηκε.

Η διεύθυνση προέλευσης είναι ο connector, όχι το laptop σας

Εδώ πηγαίνει ο περισσότερος χρόνος αποσφαλμάτωσης. Η απομακρυσμένη πύλη VPN και το firewall της βάσης δεδομένων πρέπει να δεχτούν το εκχωρημένο εύρος του connector μέσα στο VPC, όχι τη διεύθυνση του γραφείου σας και όχι τη δημόσια διεύθυνση εξόδου της υπηρεσίας. Αναζητήστε αυτό το εύρος στην κονσόλα πριν γράψετε έστω έναν κανόνα.

Δύο ακόμη σημεία πρέπει να συμφωνήσουν. Ο πίνακας δρομολόγησης του VPC χρειάζεται διαδρομή προς το απομακρυσμένο δίκτυο της βάσης δεδομένων και η απομακρυσμένη πλευρά χρειάζεται διαδρομή επιστροφής για το εύρος του connector. Αν η σήραγγα χρησιμοποιεί επιλογείς κίνησης, επιβεβαιώστε ότι το εύρος του connector βρίσκεται εντός του διαπραγματευμένου πεδίου. Μια διαδρομή που υπάρχει μόνο προς την κατεύθυνση από απομακρυσμένη σε τοπική είναι συχνό λάθος, και αφήνει τα pings να περνούν χωρίς ποτέ να ολοκληρώνει χειραψία TCP.

Μια σήραγγα που δέχεται μόνο ένα subnet VM θα απορρίπτει τα πακέτα του connector χωρίς χρήσιμο μήνυμα σφάλματος, γι' αυτό το timeout της βάσης δεδομένων μοιάζει με πρόβλημα διαπιστευτηρίων.

Το DNS ταξιδεύει σε άλλη διαδρομή

Ένα ιδιωτικό hostname βάσης δεδομένων πρέπει να επιλύεται μέσα στο δίκτυο που φτάνει ο connector, μέσω Cloud DNS peering ή ζώνης προώθησης που μπορεί να χρησιμοποιήσει το VPC. Η επίλυσή του στον σταθμό εργασίας σας δεν αποδεικνύει τίποτα για την αναπτυγμένη υπηρεσία, γιατί το laptop σας δεν χρησιμοποιεί αυτόν τον resolver.

Αν το όνομα επιλύεται σε δημόσια διεύθυνση από μέσα στο VPC, πρόκειται να αποσφαλματώσετε το λάθος firewall.

Το URL Fetch δεν χρησιμοποιεί τον connector

Η ρύθμιση εξόδου καλύπτει τις κανονικές εξερχόμενες υποδοχές του περιβάλλοντος εκτέλεσης, και η παλαιότερη υπηρεσία URL Fetch δεν είναι μέρος αυτής της διαδρομής. Ένα αίτημα που εκδίδεται μέσω urlfetch αγνοεί τον connector ό,τι κι αν λέει η διαμόρφωση. Όταν η αποτυχημένη κλήση βρίσκεται σε παλαιότερη βιβλιοθήκη που εξακολουθεί να χρησιμοποιεί URL Fetch, η διόρθωση είναι να μετακινήσετε αυτή την κλήση στον τυπικό HTTP client.

Για έναν driver βάσης δεδομένων αυτό σπάνια είναι το πρόβλημα, αλλά είναι ο κλασικός λόγος που ένα endpoint λειτουργεί και άλλο όχι από την ίδια υπηρεσία.

Επαληθεύστε με ένα στενό query

Κάντε deploy και μετά εκτελέστε μία επιτρεπόμενη λειτουργία βάσης δεδομένων από την αναπτυγμένη έκδοση παρακολουθώντας την απομακρυσμένη πλευρά. Η διεύθυνση προέλευσης που καταγράφει η βάση δεδομένων ή η πύλη VPN πρέπει να είναι του connector. Αν δεν είναι, το αίτημα δεν μπήκε ποτέ στο VPC και καμία ποσότητα διαμόρφωσης σήραγγας δεν θα το διορθώσει. Συγκρίνετε τη με το εύρος που αναζητήσατε στην κονσόλα· μια αναντιστοιχία συνήθως σημαίνει ότι ένας δεύτερος connector εξυπηρετεί την έκδοση.

Ένα επιτυχημένο query από VM μέσα στο VPC αποδεικνύει ότι η διαδρομή υπάρχει. Δεν αποδεικνύει ότι η υπηρεσία τη διάλεξε.