Το kubectl δεν μπορεί να επιλύσει το API του ιδιωτικού συμπλέγματος μέσω OpenVPN

Το kubectl αποτυγχάνει στην αναζήτηση ονόματος ενώ η σήραγγα είναι ενεργή και η ιδιωτική διεύθυνση του API απαντά ακόμη σε ping. Η διαδρομή είναι εντάξει· ο πελάτης ρωτά έναν resolver που δεν έχει ακούσει ποτέ για τη ιδιωτική ζώνη του συμπλέγματος. Δύο διορθώσεις χρησιμοποιούνται περισσότερο: η ώθηση του resolver του εικονικού δικτύου σε κάθε πελάτη VPN, ή η καρφίτσωση του ονόματος τοπικά με εγγραφή hosts ή υπό όρους forwarder. Λύνουν το ίδιο σύμπτωμα με διαφορετική ευθύνη, και η σύγχυσή τους είναι ο λόγος που οι ομάδες καταλήγουν να επεξεργάζονται αρχεία hosts κάθε φορά που ένα τελικό σημείο ξαναχτίζεται.

Η επίλυση και η προσβασιμότητα αποτυγχάνουν σε διαφορετικά επίπεδα

Εκτελέστε την αναζήτηση μόνοι σας πριν αλλάξετε οτιδήποτε. getent hosts σε Linux ή nslookup σε Windows σας λέει αν ο πελάτης παίρνει καθόλου απάντηση· ένα timeout ή NXDOMAIN δείχνει τον resolver, ενώ μια απάντηση με λάθος διεύθυνση δείχνει μια παλιά εγγραφή ή μια δημόσια δίοδο.

Έπειτα επιβεβαιώστε σε ποιον διακομιστή συνδέεται πραγματικά το kubectl. Ένα context kubeconfig αποθηκεύει ένα URL, και μια διαδρομή VPN δεν το ξαναγράφει: αν το context ονομάζει δημόσιο τελικό σημείο, το DNS μπορεί να είναι τέλειο και η εντολή να αποτυγχάνει ακόμη.

getent hosts api.internal.example
kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}'
kubectl -v=8 get nodes 2>&1 | head -40

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

Επιλογή A: ωθήστε τον resolver του εικονικού δικτύου στη σήραγγα

Όταν ο διακομιστής VPN εκτελείται μέσα στο εικονικό δίκτυο, οι πελάτες μπορούν να χρησιμοποιούν τον ίδιο resolver με τον κεντρικό υπολογιστή του διακομιστή. Στο OpenVPN Community ο διακομιστής ωθεί μια επιλογή DNS· το Access Server εκθέτει την ίδια ρύθμιση στη διεπαφή διαχείρισης, και οι πελάτες πρέπει να κατεβάσουν ξανά το προφίλ επειδή η οδηγία DNS ταξιδεύει μέσα σε αυτό.

# server.conf
push "dhcp-option DNS 10.0.0.4"
push "route 10.0.0.4 255.255.255.255"

Η γραμμή διαδρομής έχει σημασία στα προφίλ split tunnel. Η ώθηση μιας διεύθυνσης resolver δεν είναι το ίδιο με το να την κάνετε προσβάσιμη: αν μόνο το υποδίκτυο του συμπλέγματος περνά από τη σήραγγα, το ερώτημα προς 10.0.0.4 βγαίνει από το τοπικό LAN και πεθαίνει. Ωθήστε μια διαδρομή κεντρικού υπολογιστή για τον resolver, ή συμπεριλάβετε το υποδίκτυό του στη σήραγγα.

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

Στον πελάτη, επαληθεύστε τι εφαρμόστηκε: resolvectl status σε systemd-resolved Linux, scutil --dns σε macOS, ipconfig /all σε Windows. Ένας διακομιστής DNS που ωθήθηκε και δεν εμφανίζεται ποτέ σημαίνει ότι το προφίλ δεν φορτώθηκε ξανά.

Επιλογή B: εγγραφές hosts και υπό όρους προώθηση

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

Ένας υπό όρους forwarder κλιμακώνεται καλύτερα χωρίς να ωθεί DNS σε κάθε πελάτη. Το dnsmasq μπορεί να στείλει μία ζώνη στον resolver του VNet και να αφήσει όλα τα άλλα ήσυχα: server=/cluster.internal/10.0.0.4. Το DNS των Windows έχει υπό όρους forwarders, και οι πελάτες Windows μπορούν να χρησιμοποιήσουν έναν κανόνα NRPT για την ίδια διάσπαση. Ο forwarder χρειάζεται ακόμη μια διαδρομή προς τον resolver του VNet.

Η προώθηση κρατά την κανονική περιήγηση τοπική, κάτι που έχει σημασία στο split tunnel. Σας δίνει επίσης ένα σημείο για την καταγραφή ερωτημάτων της ιδιωτικής ζώνης, και ένα σημείο που σπάει όταν ο κεντρικός υπολογιστής του forwarder μετακινηθεί.

Επιλέξτε με βάση την ευθύνη, όχι την ευκολία

Ωθήστε τον resolver όταν ελέγχετε το προφίλ VPN και θέλετε κάθε ιδιωτικό όνομα να λειτουργεί, όχι μόνο το API. Επιλέξτε forwarder όταν οι πελάτες πρέπει να κρατήσουν το τοπικό DNS για όλα τα άλλα, ή όταν το VPN το διαχειρίζεται άλλη ομάδα από το σύμπλεγμα.

Οι εγγραφές hosts είναι διάγνωση, όχι ανάπτυξη. Χρησιμοποιήστε μία για να αποδείξετε ότι το API είναι προσβάσιμο, μετά αφαιρέστε την και διορθώστε τη διαδρομή του resolver· αν την αφήσετε στη θέση της, μια ερώτηση δρομολόγησης γίνεται αργότερα κυνήγι θησαυρού. Όποια επιλογή κι αν διαλέξετε, σημειώστε τη ζώνη, τη διεύθυνση του resolver και τη διαδρομή που μεταφέρει το ερώτημα.

Δοκιμάστε το τελικό σημείο του API, όχι μόνο το όνομα

Μόλις η αναζήτηση πετύχει, ανακτήστε το τελικό σημείο έκδοσης του API με το CA του συμπλέγματος. Το curl --cacert ca.crt https://api.internal.example:6443/version χωρίζει τις αποτυχίες TLS και εξουσιοδότησης από το DNS. Ένα 403 σημαίνει ότι το όνομα και η σύνδεση λειτουργούν και η ταυτότητα όχι.

Ελέγξτε επίσης αν το εύρος διευθύνσεων του πελάτη επιτρέπεται από τα εξουσιοδοτημένα δίκτυα ή το τείχος προστασίας του συμπλέγματος. Τα ιδιωτικά συμπλέγματα συχνά δέχονται κίνηση API μόνο από το VNet ή από peered εύρη, οπότε μια σήραγγα που εκχωρεί διευθύνσεις από άλλη δεξαμενή συνδέεται στο επίπεδο δικτύου και απορρίπτεται στο API.

Σημειώστε τέσσερα γεγονότα όταν κλιμακώνετε: τον resolver που χρησιμοποίησε ο πελάτης, τη διεύθυνση που επέστρεψε, το URL του διακομιστή στο επιλεγμένο context kubeconfig, και την πρώτη λειτουργία που απέτυχε. Αυτό το αρχείο λέει στον επόμενο μηχανικό αν πρέπει να αλλάξει DNS, δρομολόγηση ή πολιτική τείχους προστασίας, και σταματά την επόμενη επεξεργασία του αρχείου hosts.

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