Γιατί το VM σας στο GCP δεν μπορεί να απαντήσει στη δεξαμενή IPv6 του OpenVPN

Ο IPv6 VPN πελάτης σας φτάνει στον φόρτο εργασίας, ο φόρτος απαντά μέσα στη σήραγγα και η απάντηση δεν φτάνει ποτέ. Το ένστικτο είναι να κατηγορήσετε το τείχος προστασίας ή τη σήραγγα και συνήθως κανένα από τα δύο δεν φταίει. Μια διεύθυνση που δίνει το OpenVPN είναι ένα εσωτερικό δίκτυο που υπάρχει μόνο μέσα στη σήραγγα· το Google Cloud δεν έχει ιδέα ότι το fd42:90::/64 υποτίθεται πως βρίσκεται πίσω από ένα συγκεκριμένο VM μέχρι να του το πείτε.

Δύο ξεχωριστά συστήματα πρέπει να μάθουν αυτό το γεγονός και μόνο ένα από αυτά είναι το OpenVPN. Το VPC χρειάζεται μια διαδρομή πριν μπορέσει να στείλει οτιδήποτε πίσω και το VM πρέπει να έχει άδεια να προωθεί ό,τι φτάνει. Αν κάνετε λάθος σε οποιοδήποτε από τα δύο μισά, το σύμπτωμα φαίνεται ίδιο.

Η δεξαμενή είναι εσωτερικό δίκτυο, όχι υποδίκτυο

Το OpenVPN μπορεί να δίνει διευθύνσεις IPv6 από ένα εύρος που επιλέγετε και αυτό το εύρος είναι μια σύμβαση των δύο άκρων της σήραγγας. Δεν είναι υποδίκτυο του Google Cloud, δεν εμφανίζεται στη λίστα υποδικτύων του VPC και η διασύνδεση δικτύου του VM δεν αποκτά αυτές τις διευθύνσεις. Γι’ αυτό ένας φόρτος εργασίας που απαντά σε πελάτη στέλνει πακέτο σε διεύθυνση που το δίκτυο θεωρεί μη δρομολογήσιμη.

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

Η μοναδική τοπική διευθυνσιοδότηση όπως το fd42:90::/64 είναι λογική επιλογή για αυτό το εσωτερικό δίκτυο. Το πρόθεμα θυμίζει επίσης ότι ο σχεδιασμός είναι ιδιωτικός εκ κατασκευής. Τίποτα σε μια δεξαμενή ULA δεν την κάνει νόμιμη πηγή στο δημόσιο διαδίκτυο.

Δώστε στο VPC προορισμό και επόμενο άλμα

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

Μια διεύθυνση επόμενου άλματος πρέπει να είναι εκείνη που έχει πράγματι εκχωρηθεί στη διασύνδεση δικτύου της εικονικής μηχανής. Η εσωτερική διεύθυνση σήραγγας του VM δεν είναι αυτή η διεύθυνση. Αν τη χρησιμοποιήσετε παρ’ όλα αυτά, παράγεται διαδρομή που εγκαθίσταται καθαρά και δεν ταιριάζει ποτέ με πακέτο. Διαβάστε τη λίστα διασυνδέσεων πριν γράψετε τη διαδρομή.

Η προτεραιότητα διαδρομής έχει την ίδια σημασία με την ίδια την καταχώριση. Οι διαδρομές υποδικτύου είναι πιο συγκεκριμένες από τις προσαρμοσμένες διαδρομές που προσθέτετε, οπότε μια δεξαμενή κομμένη από υπάρχον εύρος υποδικτύου θα χάσει από τη διαδρομή υποδικτύου, όποια μορφή κι αν έχει η προσαρμοσμένη διαδρομή. Επιλέξτε ξεχωριστή δεξαμενή και μετά επιβεβαιώστε ότι η διαδρομή δείχνει το VM ως επόμενο άλμα και το σωστό πρόθεμα προορισμού:

gcloud compute routes create vpn6-return \
  --network=vpn-vpc \
  --destination-range=fd42:90::/64 \
  --next-hop-instance=openvpn-vm \
  --next-hop-instance-zone=europe-west1-b

Η προώθηση πρέπει να ενεργοποιηθεί δύο φορές

Μια διαδρομή παραδίδει το πακέτο στο VM. Δεν κάνει το VM πρόθυμο να προωθήσει κάτι που δεν απευθύνεται σε αυτό και αυτή η άδεια υπάρχει σε δύο επίπεδα.

Η πλευρά του νέφους χρειάζεται ενεργοποιημένη την ικανότητα προώθησης της εικονικής μηχανής, δηλαδή τη ρύθμιση που επιτρέπει σε ένα VM να δέχεται κίνηση για διευθύνσεις που δεν κατέχει και να τη διαβιβάζει. Η φιλοξενούμενη πλευρά χρειάζεται τη δική της προώθηση IPv6, γιατί ο πυρήνας παίρνει ξεχωριστή απόφαση αφού φτάσει το πακέτο. Και τα δύο πρέπει να είναι ενεργά πριν μία και μόνη απάντηση διασχίσει τη σήραγγα.

sysctl -w net.ipv6.conf.all.forwarding=1

Έπειτα οι κανόνες του τείχους προστασίας πρέπει να επιτρέπουν το εσωτερικό εύρος προέλευσης και προς τις δύο κατευθύνσεις. Το Google Cloud αξιολογεί το αποκαψυλιωμένο πακέτο, οπότε ένας κανόνας που καλύπτει μόνο το υποδίκτυο του VPC απορρίπτει την κίνηση της δεξαμενής αφού η σήραγγα έχει ήδη πετύχει. Προσθέστε τη δεξαμενή ως εύρος προέλευσης στον κανόνα εισόδου και ελέγξτε ότι καμία προσαρμοσμένη πολιτική εξόδου δεν μπλοκάρει την απάντηση. Ο σιωπηρός κανόνας επιτρεπόμενης καλύπτει την προεπιλεγμένη περίπτωση, ένας χειρόγραφος κανόνας εξόδου όχι.

Πείτε στο OpenVPN ποιος κατέχει τι

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

Η σύγχυση των δύο παράγει σήραγγα όπου τα ping προς τον διακομιστή δουλεύουν και τίποτα πίσω του δεν δουλεύει. Αποφασίστε ποια περίπτωση χτίζετε και μετά γράψτε την αντίστοιχη καταχώριση αντί να προσθέσετε δεύτερη γραμμή push και να ελπίζετε.

Κρατήστε την έξοδο προς το διαδίκτυο έξω από αυτόν τον σχεδιασμό

Η ιδιωτική πρόσβαση και η πρόσβαση στο διαδίκτυο είναι ξεχωριστά σχέδια. Μια δεξαμενή ULA μπορεί να φτάσει φόρτους εργασίας του VPC μέσω της σήραγγας μόλις συμφωνήσουν δρομολόγηση και προώθηση και η ίδια δεξαμενή δεν έχει διαδρομή προς το δημόσιο διαδίκτυο μέσω του VPC, γιατί η πύλη του νέφους δεν θα δεχτεί μια αυθαίρετη πηγή σήραγγας ως δική της.

Αν οι πελάτες χρειάζονται και έξοδο προς το διαδίκτυο, σχεδιάστε υποστηριζόμενη διευθυνσιοδότηση και δρομολόγηση γι’ αυτό, κρατήστε την ανεξάρτητη από την ιδιωτική δεξαμενή και δοκιμάστε τις δύο διαδρομές χωριστά. Μια διαδρομή που δουλεύει δεν λέει τίποτα για την άλλη και ένας σχεδιασμός που τις συγχωνεύει αποτυγχάνει με τρόπο που μοιάζει με σπασμένη σήραγγα.