VPN επισκέπτη σε ESXi: δρομολόγηση ή γεφύρωση — αποφασίστε πριν από την ομάδα θυρών
Ένα δρομολογημένο TUN χρειάζεται διαδρομές επιστροφής· ένα γεφυρωμένο TAP χρειάζεται προσβασιμότητα layer 2 και ευρύτερη πολιτική ομάδας θυρών. Καθορίστε τον ρόλο πριν διευρύνετε τη λειτουργία promiscuous.
Δρομολογήστε τα πακέτα ή επεκτείνετε το πεδίο Ethernet: η αλλαγή της ομάδας θυρών έπεται αυτής της επιλογής. Από μια εφαρμογή που κρατά ιδιωτική διεύθυνση τα αποτελέσματα μπορεί να φαίνονται ίδια, ενώ οι απαιτήσεις του hypervisor δεν μοιάζουν καθόλου. Γι' αυτό η ομάδα θυρών διευρύνεται πρώτη και η ερώτηση σχεδιασμού απαντάται δεύτερη, συνήθως μετά από μια καταιγίδα broadcast. Περάστε αυτούς τους ελέγχους με σειρά και σταματήστε όσο η απαίτηση είναι ακόμη ασαφής, γιατί καμία ρύθμιση ομάδας θυρών δεν διορθώνει έναν σχεδιασμό που δεν επιλέχθηκε ποτέ.
Η απόφαση ανήκει στον ιδιοκτήτη της υπηρεσίας· η διαμόρφωση του hypervisor πρέπει να την υλοποιεί, όχι να την καθορίζει τυχαία.
Ελέγξτε τι χρειάζεται πραγματικά το απομακρυσμένο άκρο
Καταγράψτε τις υπηρεσίες που πρέπει να φτάνουν οι απομακρυσμένοι πελάτες και τα πρωτόκολλα που χρησιμοποιούν. Αν η λίστα είναι λίγες υπηρεσίες TCP σε γνωστά προθέματα, η δρομολόγηση αρκεί. Αν κάτι χρειάζεται πραγματικά γειτνίαση layer 2 — ανακάλυψη που εξαρτάται από broadcast, πρωτόκολλα μη IP, συσκευή που δεν δέχεται πύλη — η δρομολόγηση δεν μπορεί να το μιμηθεί και πρέπει να το πείτε νωρίς. Να είστε ειλικρινείς για τις μη IP εγγραφές αυτής της λίστας, γιατί εκεί ένας δρομολογημένος σχεδιασμός αποτυγχάνει σιωπηλά μια εβδομάδα αργότερα.
Έπειτα ελέγξτε τη δεξαμενή πελατών. Ένας δρομολογημένος σχεδιασμός χρειάζεται εύρος διευθύνσεων και ρητή διαδρομή επιστροφής στο απομακρυσμένο άκρο· ένας γεφυρωμένος σχεδιασμός χρειάζεται το εκτεταμένο πεδίο Ethernet να κατέχει την κατανομή διευθύνσεων και την απομόνωση. Όποιο κι αν επιλέξετε, κάποιος έξω από αυτό το VM πρέπει να συμφωνήσει.
Τι ζητά κάθε σχεδιασμός από το εικονικό δίκτυο
Οι δύο σχεδιασμοί διαφέρουν ως προς το τι πρέπει να ανεχθεί το εικονικό δίκτυο, και ο πίνακας είναι ο συντομότερος τρόπος να το δείτε:
| Σχεδιασμός | Ρόλος στην πλευρά του επισκέπτη | Τι πρέπει να χωρέσει το εικονικό δίκτυο | Τρόπος αποτυχίας με λάθος επιλογή |
|---|---|---|---|
| Δρομολογημένο TUN | Δρομολογητής μεταξύ χωριστών προθεμάτων | Δρομολογημένη δεξαμενή πελατών και διαδρομές επιστροφής στο απομακρυσμένο άκρο | Οι πελάτες φτάνουν στην πύλη και ποτέ στην υπηρεσία πίσω της |
| Γεφυρωμένο TAP | Γέφυρα layer 2 για τους πελάτες που συνδέονται | Πρόσθετες ταυτότητες Ethernet, κίνηση broadcast και κανόνες VLAN | Το vSwitch απορρίπτει πλαίσια, ή ο σχεδιασμός απαιτεί λειτουργία promiscuous που κανείς δεν ενέκρινε |
Η δρομολόγηση αφήνει το πεδίο broadcast εκεί που είναι και σας δίνει φυσικό σημείο να περιορίσετε ποιες υπηρεσίες περνούν την πύλη. Η γεφύρωση μετακινεί το όριο: οι πελάτες γίνονται συμμετέχοντες στο εκτεταμένο πεδίο Ethernet, και η κατανομή διευθύνσεων, η απομόνωση και κάθε πολιτική layer 2 ισχύουν πλέον γι' αυτούς. Γράψτε την επιλεγμένη γραμμή στο αρχείο αλλαγών. Μια φράση όπως «δρομολογημένο TUN, δεξαμενή πελατών 10.90.0.0/24, διαδρομή επιστροφής στον πυρήνα» εμποδίζει τον επόμενο μηχανικό να ξανασυζητήσει τον σχεδιασμό από τις ρυθμίσεις της ομάδας θυρών.
Ποιος πρέπει να βλέπει τα πλαίσια ποιου
Ρωτήστε τον ιδιοκτήτη της πλατφόρμας ένα πράγμα πριν αγγίξετε την ομάδα θυρών: απαιτεί ο σχεδιασμός αυτό το VM να λαμβάνει πλαίσια που απευθύνονται σε άλλους συμμετέχοντες; Αν η απάντηση είναι όχι, τίποτα σε αυτή την ενότητα δεν ισχύει, γιατί ένα δρομολογημένο TUN δεν χρειάζεται ποτέ αυτή την ορατότητα. Αν η απάντηση είναι ναι, ο οδηγός της Broadcom για τη λειτουργία promiscuous είναι το ανάγνωσμα που μετρά: εξηγεί πόσο περισσότερο από το vSwitch βλέπει το VM και συνιστά να περιοριστεί αυτή η πολιτική σε μία ομάδα θυρών.
Αντιμετωπίστε το ως έλεγχο απαίτησης, όχι ως άδεια. Ενεργοποιήστε τη ρύθμιση για μία αποκλειστική σύνδεση όταν η ανάγκη γεφύρωσης είναι καταγεγραμμένη, και αφήστε την ανενεργή παντού αλλού. Ένα ευρύ VLAN trunk αντιγραμμένο από άλλο παράδειγμα γέφυρας είναι το κομμάτι που κανείς δεν θυμάται να αφαιρέσει, και ένας σχεδιασμός ενός VLAN πρέπει να μείνει ενός VLAN.
Καταγράψτε ποια ομάδα θυρών άλλαξε και γιατί, στο ίδιο σημείο όπου γράψατε τη γραμμή σχεδιασμού. Αυτό το ζεύγος κάνει δυνατό τον επόμενο έλεγχο.
Κρατήστε τα αντικείμενα του επισκέπτη ρητά
Μέσα στο Linux, η συμμετοχή στη γέφυρα και η κυριότητα διεύθυνσης είναι ξεχωριστά αντικείμενα, και η σύγχυσή τους προκαλεί την μπερδεμένη μισολειτουργική κατάσταση. Αναθέστε διευθύνσεις στη διεπαφή γέφυρας ή στο δρομολογημένο τούνελ, όχι και στις δύο πλευρές της ίδιας διαδρομής, και κρατήστε τις θύρες μέλη χωρίς διαμόρφωση IP.
Αποφύγετε να βάλετε ένα υποδίκτυο ανεξάρτητα σε δρομολογημένο TUN και σε άσχετη διεπαφή Ethernet. Αυτή η διαμόρφωση παράγει δύο διαδρομές προς το ίδιο πρόθεμα, ασύμμετρες απαντήσεις και ένα νήμα υποστήριξης για flapping που δεν αναφέρει καμία από τις διαδρομές. Αν ο επισκέπτης φιλοξενεί επίσης containers ή τοπικό hypervisor, ελέγξτε ότι δεν γεφυρώνουν ήδη στο ίδιο uplink. Δύο γέφυρες σε μία NIC είναι σχεδιασμός, όχι ατύχημα που θέλετε να ανακαλύψετε σε παράθυρο αλλαγής.
Επιβεβαιώστε με διαδρομή πακέτου, όχι με ping
Επαληθεύστε την πραγματική διαδρομή, όχι μόνο την προσβασιμότητα. Από έναν πελάτη, επιβεβαιώστε ποια διεύθυνση προέλευσης φτάνει στην απομακρυσμένη υπηρεσία, και μετά ότι η απάντηση επιστρέφει από τον ίδιο δρόμο. Στον επισκέπτη, ελέγξτε τους μετρητές προώθησης για τη συγκεκριμένη ροή, και στην ομάδα θυρών επιβεβαιώστε ότι δεν ενεργοποιήθηκε πρόσθετη ορατότητα πέρα από ό,τι χρειάζεται ο επιλεγμένος σχεδιασμός.
Τέλος, δοκιμάστε την κατεύθυνση αποτυχίας. Σταματήστε το τούνελ ή αποσυνδέστε τον πελάτη και ελέγξτε ότι η κίνηση δεν πέφτει σιωπηλά σε δρομολογημένη διαδρομή που θεωρούσατε ανενεργή, γιατί αυτή η πτώση είναι πώς ένας γεφυρωμένος σχεδιασμός γίνεται σιωπηλά ακούσιος δρομολογητής.