IP του πελάτη VPN μέσα στο Kubernetes: να το διατηρήσουμε ή να κάνουμε SNAT;
Επιλέξτε ανάμεσα στη διατήρηση της πραγματικής διεύθυνσης του πελάτη VPN και στο source NAT μέσα στο Kubernetes με τρεις συνθήκες, και μετά επαληθεύστε τη διαδρομή επιστροφής και την εναλλαγή των pods.
Κάπου ανάμεσα στο tunnel και στο backend, η διεύθυνση ενός πελάτη είτε επιβιώνει είτε αντικαθίσταται, και τα δύο αποτελέσματα είναι υπερασπίσιμα. Η επιλογή ανήκει σε όποιον κατέχει την υπηρεσία υποδοχής, όχι σε όποιον εγκατέστησε το CNI. Όταν η εξουσιοδότηση ανά πελάτη, τα όρια ή τα αρχεία ελέγχου έχουν σημασία, η διεύθυνση πρέπει να επιβιώνει σε κάθε άλμα. Όταν η κοινή απόδοση είναι αποδεκτή, το source NAT αφαιρεί ένα πρόβλημα δρομολόγησης που διαφορετικά θα συντηρούσατε για πάντα.
Πού εξαφανίζεται πραγματικά η διεύθυνση του πελάτη
Το πακέτο ενός απομακρυσμένου πελάτη φτάνει στο pod VPN με εσωτερική πηγή εντός της περιοχής του tunnel, ας πούμε 10.90.0.42. Όταν το pod προωθεί αυτό το πακέτο προς ένα ClusterIP ή μια IP pod, τρεις διαφορετικοί μηχανισμοί μπορούν να ξαναγράψουν την πηγή. Ο κανόνας masquerade του CNI στον κόμβο καλύπτει την κίνηση που στέλνει το pod εκτός του CIDR του cluster. Η καταχώριση conntrack του kube-proxy στον κόμβο προορισμού καλύπτει το ίδιο το άλμα προς το Service. Ένα proxy που τερματίζει τη σύνδεση δεν προωθεί καθόλου το πακέτο, οπότε η πηγή που τελικά βλέπετε ανήκει στο proxy.
Κάθε ένα ζει σε διαφορετικό επίπεδο, γι' αυτό ένα μόνο πεδίο Service σχεδόν ποτέ δεν διορθώνει ολόκληρη τη διαδρομή.
Το externalTrafficPolicy στο δημόσιο Service του VPN αποφασίζει μόνο τι συμβαίνει με την εξωτερική σύνδεση: το Local διατηρεί την απομακρυσμένη διεύθυνση στον κόμβο που την έλαβε, ενώ το Cluster αφήνει το kube-proxy να δώσει το πακέτο σε άλλο κόμβο και να το κάνει masquerade εκεί. Αυτή η ρύθμιση κυβερνά τον listener στον οποίο συνδέονται οι πελάτες σας. Δεν λέει τίποτα για το αποκρυπτογραφημένο πακέτο που το VPN-process σας δρομολογεί μετά στο cluster.
Τρεις συνθήκες που κλείνουν τη διαφωνία
Κάνω τις ίδιες τρεις ερωτήσεις με την ίδια σειρά κάθε φορά που προκύπτει αυτό, γιατί η πρώτη συνήθως κλείνει τη συζήτηση. Απαντήστε τις για τον συγκεκριμένο φόρτο εργασίας και όχι για το cluster στο σύνολό του. Δύο clusters σε μία εταιρεία μπορούν να καταλήξουν σε διαφορετικές απαντήσεις και οι δύο να είναι σωστές.
| Question | Preserve | SNAT |
|---|---|---|
| Does the backend enforce policy per client? | Yes, the address is the identity | Only if a trusted proxy supplies identity |
| Can the cluster route 10.90.0.0/24 back to a stable gateway? | Required | Not needed |
| Is the workload a forwarder or a proxy? | Forwarder | Proxy is fine |
Αν το backend απαντήσει ναι στην πρώτη ερώτηση και όχι στη δεύτερη, έχετε δικτυακή δουλειά να κάνετε αντί για ένα manifest να επεξεργαστείτε. Αν η τρίτη σειρά λέει proxy, η διεύθυνση δεν επρόκειτο ποτέ να επιβιώσει, και το να προσποιείστε το αντίθετο κοστίζει μια εβδομάδα καταγραφής πακέτων.
Τι απαιτεί η λειτουργία preserve από το δίκτυο
Η διατήρηση της πηγής σημαίνει ότι ο κόμβος προορισμού πρέπει να επιστρέφει την κίνηση στη 10.90.0.42 μέσω ενεργού VPN gateway. Η δεξαμενή VPN δεν είναι CIDR του cluster, οπότε κανένα CNI δεν τη δρομολογεί για εσάς εξ ορισμού. Προσθέτετε τη διαδρομή μόνοι σας και μετά φροντίζετε το τελικό σημείο του gateway στο οποίο δείχνει να επιβιώνει από έναν επαναπρογραμματισμό.
ip route add 10.90.0.0/24 via 10.244.3.17 dev eth0
sysctl -w net.ipv4.conf.eth0.rp_filter=2
Το επόμενο άλμα είναι μια διεύθυνση pod, και οι διευθύνσεις pod μετακινούνται. Στρέψτε τη διαδρομή σε ένα VIP του Service ή σε μια διεύθυνση κόμβου που μένει στη θέση της, ή δεχτείτε ότι θα κυνηγάτε το gateway μετά από κάθε έξωση. Το φιλτράρισμα αντίστροφης διαδρομής είναι η άλλη παγίδα: η αυστηρή λειτουργία απορρίπτει πακέτα των οποίων η διαδρομή επιστροφής δεν ταιριάζει με τη διεπαφή από την οποία έφτασαν, που είναι ακριβώς η μορφή μιας διατηρημένης ροής VPN.
Η χαλαρή επικύρωση είναι συχνά η διαφορά ανάμεσα σε μια λειτουργική διαδρομή επιστροφής και απαντήσεις που εξαφανίζονται αφού φύγουν από το backend. Οι κανόνες masquerade στον κόμβο VPN πρέπει επίσης να εξαιρούν την περιοχή του tunnel, αλλιώς το προωθημένο πακέτο φεύγει με τη διεύθυνση του pod, ανεξάρτητα από τη διαδρομή που χτίσατε. Προτιμήστε να εκφράσετε αυτή την εξαίρεση στη διαμόρφωση του ίδιου του CNI αντί να επεξεργάζεστε το iptables με το χέρι, γιατί ο agent ξαναγράφει τις αλυσίδες του στην επανεκκίνηση και ο χειρόγραφος κανόνας σας επιβιώνει ακριβώς μέχρι την επόμενη αναβάθμιση.
Το NetworkPolicy είναι έλεγχος πρόσβασης, όχι δρομολόγηση. Το να αυστηροποιήσετε μια πολιτική δεν θα επαναφέρει ποτέ μια διεύθυνση που το masquerade έχει ήδη αντικαταστήσει.
Τι κοστίζει το SNAT, και πώς να το καταγράψετε
Το source NAT προς το cluster είναι ο φθηνότερος σχεδιασμός, και δεν είναι λάθος. Το backend βλέπει τη διεύθυνση του pod ή του κόμβου VPN, τα αρχεία καταγραφής συμφωνούν μεταξύ τους και δεν χρειάζεται να υπάρχει καμία διαδρομή επιστροφής. Αυτό που χάνετε είναι η δυνατότητα να ξεχωρίζετε δύο πελάτες στο επίπεδο δικτύου, οπότε τα όρια, οι αποκλεισμοί και τα ίχνη ελέγχου πρέπει να έρχονται από αλλού.
Συνήθως αυτό το αλλού είναι η εφαρμογή: ένα token συνεδρίας, μια υπογεγραμμένη κεφαλίδα ή μια γραμμή του πρωτοκόλλου PROXY γραμμένη από ένα proxy που ελέγχετε. Αυτά δίνουν στον παραλήπτη μια ταυτότητα που μπορεί να εμπιστευτεί μόνο όταν το proxy βρίσκεται στη διαδρομή και η κεφαλίδα δεν μπορεί να οριστεί από την πλευρά του πελάτη. Να είστε σαφείς στο runbook για το ποιο ισχύει, γιατί ο επόμενος μηχανικός θα υποθέσει ότι η διεύθυνση στο αρχείο είναι ο πελάτης. Δεν είναι, και ένα περιστατικό αρκεί για να κάνει αυτή την υπόθεση ακριβή.
Η ανταλλαγή παραμένει έντιμη όσο είναι γραμμένη.
Έλεγχοι που ξεχωρίζουν μια λειτουργική διαδρομή από μια τυχερή
Δοκιμάστε με νέα σύνδεση αντί για μια από την προσωρινή μνήμη, και δοκιμάστε και προς τις δύο κατευθύνσεις. Αρκετές αστοχίες φαίνονται διακοπτόμενες μόνο επειδή οι νέες ροές ακολουθούν την ξαναγραμμένη διαδρομή.
Καταγράψτε το tuple σε τρία σημεία κατά τη διάρκεια ενός εξουσιοδοτημένου αιτήματος: αμέσως μετά την αποκρυπτογράφηση, στη διεπαφή εξόδου του pod VPN και στο backend. Αν η πηγή αλλάξει ανάμεσα στη δεύτερη και την τρίτη καταγραφή, η αιτία βρίσκεται κατάντη του pod. Αν αλλάξει πριν από τη δεύτερη, το ίδιο το pod μεταφράζει.
Στη συνέχεια διαγράψτε το pod VPN και επαναλάβετε τη δοκιμή όσο αυτό επαναπρογραμματίζεται. Μια διατηρημένη διαδρομή που σπάει στην έξωση είναι ημιτελής, και το ίδιο ισχύει για έναν κανόνα NAT καρφιτσωμένο σε μια διεύθυνση που δεν υπάρχει πια. Τέλος, στείλτε ένα αίτημα από μια πηγή που περιμένετε να απορριφθεί και επιβεβαιώστε ότι η άρνηση προέρχεται από πολιτική και όχι από μια διαδρομή που λείπει.