OpenVPN στο GCE: προσθέστε μια IP alias πριν κάνετε push routes

Ένα pushed route δεν κάνει το VM next hop. Προσθέστε το εύρος IP alias, ταιριάξτε το με το pool του διακομιστή και δημιουργήστε την επιστροφική διαδρομή στο VPC πριν δοκιμάσετε πελάτες.

Ένας πελάτης καλεί τον διακομιστή OpenVPN σε ένα VM του Compute Engine, το παράθυρο κατάστασης λέει συνδεδεμένο, και ένα ping σε host μέσα στο VPC εξακολουθεί να μη φτάνει πουθενά. Το ένστικτο είναι να προστεθεί άλλη μια γραμμή push, και αυτό δεν το διορθώνει ποτέ. Το Compute Engine αποφασίζει πού πάνε τα πακέτα από τον δικό του πίνακα δρομολόγησης και από τις διευθύνσεις που έχει πραγματικά μια διεπαφή VM, άρα ένα pool σήραγγας που το VM δεν κατέχει είναι ένα pool στο οποίο κανείς δεν παραδίδει.

Ακολουθήστε το πακέτο που αποτυγχάνει αντί για το αρχείο ρυθμίσεων, και τα κομμάτια που λείπουν εμφανίζονται με τη σειρά.

Ξεκινήστε από το πακέτο που πεθαίνει

Το SYN φεύγει από τον πελάτη, μπαίνει στη σήραγγα και φτάνει στο VM ως ενθυλακωμένο πακέτο για έναν προορισμό μέσα στο VPC. Το OpenVPN το αποενθυλακώνει και προσπαθεί να το προωθήσει μέσω eth0, όπου το fabric θέτει μία ερώτηση πριν από οτιδήποτε άλλο: κατέχει αυτό το instance τη διεύθυνση προορισμού. Ένα pool σήραγγας κομμένο από το subnet κάποιου άλλου αποτυγχάνει σε αυτή την ερώτηση, και το πακέτο απορρίπτεται πριν ελεγχθεί οποιοδήποτε route ή κανόνας firewall.

Άρα η κατεύθυνση από τον πελάτη προς το VPC έχει δύο ξεχωριστές απαιτήσεις, και καμία από αυτές δεν είναι οδηγία push. Το VM χρειάζεται ένα εύρος alias που καλύπτει το pool της σήραγγας, και αυτό ακριβώς το κάνει νόμιμο κάτοχο αυτών των διευθύνσεων. Το VPC χρειάζεται ένα route που ονομάζει το VM ως next hop για κάθε προστατευμένο πρόθεμα. Αν λείπει ένα, το πακέτο πεθαίνει αλλού, ενώ ο πελάτης βλέπει την ίδια σιωπή.

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

Κατέχει το instance το pool της σήραγγας

Δώστε στο VM ένα δευτερεύον εύρος μέσα στο δικό του subnet και μετά κάντε το OpenVPN να μοιράζει διευθύνσεις ακριβώς από αυτό το εύρος. Σε ένα instance του οποίου η κύρια διεύθυνση είναι 10.156.0.10/20, ένα alias /28 κρατά το pool χωριστά από τις διευθύνσεις που έχουν ήδη άλλα instances:

gcloud compute instances network-interfaces update openvpn-vm \
  --zone=europe-west1-b \
  --aliases=eth0:10.156.1.0/28

Η οδηγία server πρέπει τότε να περιγράφει το ίδιο μπλοκ. Η πρώτη της διεύθυνση γίνεται η πύλη της σήραγγας, και οι υπόλοιπες διευθύνσεις μοιράζονται στους πελάτες. Εδώ δύο αριθμοί περιγράφουν ένα μπλοκ, ένα δίκτυο και ένα netmask, και αυτή είναι η σύνταξη pool που το OpenVPN εξακολουθεί να περιμένει.

server 10.156.1.0 255.255.255.240

Επιβεβαιώστε ότι η διεύθυνση έφτασε πραγματικά στη διεπαφή και όχι μόνο στη ρύθμιση του OpenVPN. Το fabric προωθεί ό,τι αναφέρει η NIC, όχι ό,τι πιστεύει ο daemon. Μία εντολή το ξεκαθαρίζει:

ip -4 addr show dev eth0

Μια δευτερεύουσα διεύθυνση που δεν φτάνει ποτέ στο eth0, ή ένα pool που επικαλύπτεται με άλλο subnet, εμφανίζεται αργότερα ως διακοπτόμενες απώλειες και όχι ως σφάλμα εκκίνησης. Ο daemon ξεκινά, οι πελάτες συνδέονται, και μόνο ορισμένοι προορισμοί συμπεριφέρονται λάθος. Κρατήστε το εύρος alias μικρό ώστε το pool να αναγνωρίζεται εύκολα σε έναν πίνακα δρομολόγησης. Μην το κόψετε ποτέ από subnet που χρησιμοποιεί ήδη άλλο instance.

Δώστε στο επιστροφικό traffic ένα next hop

Μια απάντηση από host του VPC απευθύνεται σε μια διεύθυνση πελάτη στο pool της σήραγγας, η οποία δεν ανήκει σε κανένα subnet που γνωρίζει το VPC. Χωρίς route για αυτό το pool, η απάντηση σταματά στο πρώτο hop χωρίς αντιστοίχιση, και το αίτημα μπορεί κάλλιστα να πέτυχε στο άλλο άκρο.

gcloud compute routes create openvpn-return \
  --network=prod-vpc \
  --destination-range=192.168.127.0/24 \
  --next-hop-instance=openvpn-vm \
  --next-hop-instance-zone=europe-west1-b \
  --priority=800

Το ίδιο route χρειάζεται για κάθε πρόθεμα που βρίσκεται πίσω από έναν πελάτη και όχι μέσα στο VPC. Αυτά τα προθέματα χρειάζονται επίσης μια εγγραφή iroute στο αρχείο ccd αυτού του πελάτη. Αυτή η εγγραφή είναι λογιστική στην πλευρά του διακομιστή: λέει στον διακομιστή ποιος πελάτης κατέχει το πρόθεμα, και δεν εγκαθιστά τίποτα στον ίδιο τον πελάτη.

Κρατήστε τη λίστα push για την πλευρά του πελάτη της συνομιλίας, γιατί προσθέτει routes μόνο στο μηχάνημα που συνδέεται. Μια γραμμή push για subnet του VPC και ένα route του VPC πίσω στο pool είναι δύο μισά της ίδιας διαδρομής, και κάθε μισό μόνο του παράγει μια σήραγγα που μεταφέρει αιτήματα αλλά όχι απαντήσεις.

Firewalls, προώθηση και τα hops ανάμεσα

Το firewall του VPC αξιολογεί το αποενθυλακωμένο πακέτο, άρα ένας κανόνας ingress πρέπει να επιτρέπει το pool της σήραγγας και κάθε πρόθεμα ιστοτόπου που φτάνει στο VM με αυτόν τον τρόπο. Μια στάση default-deny αποτυγχάνει σιωπηλά εδώ: το πακέτο απορρίπτεται μετά την αποενθυλάκωση, και το log του OpenVPN δείχνει υγιή συνεδρία.

Σε κάθε host Linux που προωθεί αντί να τερματίζει, ελέγξτε ότι το net.ipv4.ip_forward είναι ενεργό. Ο κανόνας ιδιοκτησίας ισχύει και εκεί: ένα μηχάνημα που προωθεί για subnet που δεν κατέχει απορρίπτει το πακέτο όπως ακριβώς θα έκανε το VM. Διαβάστε την τιμή πριν κατηγορήσετε τη σήραγγα.

Όταν αποτυγχάνει ακριβώς ένα πρόθεμα

Η μερική αστοχία είναι η πιο εύκολη περίπτωση για ανάγνωση, γιατί όλα τα υπόλοιπα στη διαδρομή έχουν ήδη αποδειχθεί. Ξεκινήστε από τη λίστα routes και διαβάστε το εύρος προορισμού και το next hop της εγγραφής που θα έπρεπε να καλύπτει το πρόθεμα, μετά διαβάστε την περιγραφή του instance και συγκρίνετε το εύρος alias του με το pool που μοιράζει ο διακομιστής.

gcloud compute routes list --filter=destination-range~10.164.0.0
 gcloud compute instances describe openvpn-vm --format=get(networkInterfaces[0].aliasIpRanges)

Ένα route που λείπει εμφανίζεται ως απουσία next hop για το πρόθεμα, ενώ ένα alias που λείπει εμφανίζεται ως πακέτο που απορρίπτεται στη διεπαφή; από την πλευρά του πελάτη τα δύο μοιάζουν και σε αυτές τις δύο εξόδους είναι εντελώς διαφορετικά. Αν υπάρχουν και τα δύο, ο εναπομείνας ύποπτος είναι το ccd iroute του πελάτη που διεκδικεί το πρόθεμα.

Γράψτε τις τέσσερις τιμές δίπλα στη σήραγγα: εύρος alias, pool διακομιστή, pushed προθέματα, routes VPC. Ένα ξεπερασμένο alias σπάει κάθε διεύθυνση του pool, ένα ξεπερασμένο route σπάει μία κατεύθυνση, ένα push που λείπει κρύβει το πρόθεμα από τον πελάτη, και ένα λάθος iroute στέλνει το πρόθεμα στον λάθος peer. Ο επόμενος άνθρωπος που θα προσθέσει subnet χρειάζεται και τα τέσσερα σε ένα σημείο, και η σημείωση είναι φθηνότερη από το βράδυ.

Σχετικά άρθρα