Το AWS Client VPN συνδέεται, αλλά το EC2 εξακολουθεί να μην αποκρίνεται

Ο φορητός μου έλεγε συνδεδεμένο. Ο πελάτης AWS Client VPN έδειχνε την πράσινη κατάστασή του, το endpoint κατέγραφε μια συνεδρία, και παρ’ όλα αυτά δεν μπορούσα να ανοίξω θύρα MongoDB σε μια παρουσία EC2 σε ιδιωτικό υποδίκτυο. Τίποτα δεν ήταν προφανώς χαλασμένο: το πιστοποιητικό ήταν έγκυρο, το προφίλ ερχόταν από την κονσόλα και το τούνελ μετέφερε κίνηση. Το λάθος ήταν δικό μου, γιατί διάβαζα το συνδεδεμένο ως εξουσιοδοτημένο.

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

Οι έλεγχοι παρακάτω είναι η σειρά που χρησιμοποιώ τώρα.

Τι αποδεικνύει πραγματικά μια συνδεδεμένη συνεδρία

Κατά τη χειραψία το endpoint επικυρώνει το πιστοποιητικό του πελάτη με το trust store του ή ανακατευθύνει το πρόγραμμα περιήγησης στον πάροχο ταυτότητας όταν είναι ρυθμισμένο το SAML. Αν αυτό περάσει, ο πελάτης λαμβάνει διεύθυνση από το CIDR πελάτη του endpoint και η κονσόλα δείχνει ενεργή σύνδεση. Σε κανένα σημείο αυτής της ανταλλαγής δεν ρωτά τίποτα αν μπορείτε να φτάσετε στη 10.0.4.17 στη θύρα 27017.

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

Συγκρίνετε τον κανόνα εξουσιοδότησης με τον πόρο, όχι με το VPC

Καταγράψτε τους κανόνες και βάλτε τους δίπλα στη διεύθυνση που έχει πραγματικά η παρουσία:

aws ec2 describe-client-vpn-authorization-rules \
  --client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8

Η έξοδος δείχνει ένα CIDR προορισμού και ένα αναγνωριστικό ομάδας ανά κανόνα. Δύο αστοχίες κρύβονται εκεί. Ο κανόνας μπορεί να εξουσιοδοτεί το 10.0.0.0/16 ενώ η παρουσία βρίσκεται σε ομότιμο VPC στο 10.1.0.0/16· η διαδρομή peering υπάρχει, αλλά κανείς δεν έγραψε κανόνα εξουσιοδότησης για το δεύτερο εύρος. Ή ο κανόνας δείχνει σε ομάδα καταλόγου στην οποία ο χρήστης ανήκει στον κατάλογο αλλά όχι στην ομάδα που αξιολογεί το endpoint.

Γράψτε τον στενότερο κανόνα που καλύπτει τον προορισμό, και προσθέστε δεύτερο μόνο όταν χρειάζεται πραγματικά δεύτερο CIDR. Ένας ευρύς κανόνας 0.0.0.0/0 από γρήγορη εκκίνηση δουλεύει, και γι’ αυτό επιβιώνει στην παραγωγή και κρύβει το μοντέλο.

Δύο πίνακες δρομολόγησης αποφασίζουν αν το πακέτο θα κινηθεί

Μια διαδρομή endpoint αντιστοιχίζει ένα CIDR προορισμού σε ένα από τα υποδίκτυα με τα οποία είναι συνδεδεμένο το endpoint. Αυτό είναι το μισό της διαδρομής. Ο δικός του πίνακας δρομολόγησης του υποδικτύου πρέπει ακόμη να ξέρει πώς να προωθήσει το πακέτο, και αυτό μετρά τη στιγμή που ο προορισμός βρίσκεται πίσω από σύνδεση peering, transit gateway ή τοπικό εύρος προσβάσιμο μέσω τούνελ site-to-site.

aws ec2 describe-client-vpn-routes \
  --client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8

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

Μια ρύθμιση στην πλευρά του πελάτη σπάει τη δρομολόγηση χωρίς να σπάσει το τούνελ: ένα προφίλ που περιέχει route-nopull. Η οδηγία λέει σε πελάτη βασισμένο σε OpenVPN να αγνοεί τις διαδρομές που σπρώχνει ο διακομιστής, έτσι η διεπαφή ανεβαίνει μόνο με τη διεύθυνση του endpoint και ο προορισμός απλώς δεν έχει διαδρομή. Ελέγξτε με ip route show σε Linux ή netstat -rn σε macOS αν υπάρχει διαδρομή μέσω της διεπαφής tun. Αν δεν υπάρχει, αφαιρέστε το route-nopull από το εξαγόμενο προφίλ και επανασυνδεθείτε ώστε να εφαρμοστούν οι διαδρομές που σπρώχνονται.

Οι ομάδες ασφαλείας δεν βλέπουν τη διεύθυνση του πελάτη σας

Αυτό είναι το κομμάτι που το είχα λάθος για ένα απόγευμα. Για endpoint IPv4 συνδεδεμένο με υποδίκτυο, η υπηρεσία μεταφράζει τη διεύθυνση προέλευσης του πελάτη στη διεύθυνση της δικτυακής διεπαφής του endpoint σε αυτό το υποδίκτυο. Το πακέτο που φτάνει στην παρουσία δεν φέρει τη διεύθυνση που έδειχνε ο πελάτης σας, οπότε ένας κανόνας ομάδας ασφαλείας που επιτρέπει το pool πελατών, ας πούμε 172.16.0.0/22, δεν ταιριάζει με τίποτα.

Επιτρέψτε τη θύρα από την ομάδα ασφαλείας του endpoint, που είναι προσαρτημένη στη διεπαφή της συσχέτισης, και όχι από το CIDR πελάτη. Η αναφορά στην ομάδα είναι πιο ανθεκτική από τη σκληρή κωδικοποίηση διεύθυνσης, γιατί τη διεύθυνση της διεπαφής δεν την ελέγχετε εσείς. Τα ACL δικτύου είναι άνευ κατάστασης, οπότε όπου υπάρχουν προσαρμοσμένες εγγραφές, και η εισερχόμενη και η εξερχόμενη κατεύθυνση πρέπει να επιτρέπουν τη ροή.

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

Μια σειρά απομόνωσης που σταματά στην πρώτη αποτυχία

Δουλέψτε τα με τη σειρά και σταματήστε όπου αποτύχει ένα. Κάθε βήμα αποκλείει ένα επίπεδο αντί για όλα.

1. Επιβεβαιώστε ποια ταυτότητα χρησιμοποίησε η συνεδρία και ποια ομάδα αξιολογεί το endpoint. Ένα πιστοποιητικό από ένα trust store δεν είναι το ίδιο υποκείμενο με έναν ισχυρισμό SAML από τον κατάλογο.
2. Επιβεβαιώστε ότι ένας κανόνας εξουσιοδότησης καλύπτει το CIDR του πόρου για αυτή την ομάδα.
3. Επιβεβαιώστε ότι υπάρχει διαδρομή endpoint και στοχεύει συνδεδεμένο υποδίκτυο, και μετά ότι ο πίνακας δρομολόγησης του υποδικτύου μπορεί να προωθήσει παραπέρα.
4. Επιβεβαιώστε ότι η ομάδα ασφαλείας επιτρέπει τη θύρα από τη διεπαφή του endpoint και όχι από το pool πελατών.
5. Δοκιμάστε από μέσα στο VPC, με συνεδρία SSM σε άλλη παρουσία στο ίδιο υποδίκτυο, για να ξεχωρίσετε πρόβλημα εφαρμογής από πρόβλημα διαδρομής πελάτη.

Όταν τα βήματα δεν είναι αποφασιστικά, σε αυτόν τον πίνακα καταφεύγω:

Δύο λεπτομέρειες λογαριασμού παράγουν συμπτώματα που μοιάζουν με αποτυχίες αδειών. Κάθε χρήστης χρειάζεται ξεχωριστό πιστοποιητικό πελάτη· το μοίρασμα ενός σε δύο μηχανήματα κάνει τις συνεδρίες να εκτοπίζουν η μία την άλλη, και το αποτέλεσμα είναι βρόχος επανασύνδεσης αντί για άρνηση. Όταν δημιουργείται νέο endpoint, η κονσόλα δείχνει ένα όνομα DNS που μερικές εκδόσεις πελάτη δέχονται μόνο με το τυχαίο πρόθεμα που εμφανίζεται στη σελίδα του endpoint, οπότε αντιγράψτε το πλήρες όνομα αντί να το ανακατασκευάσετε.

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