Χρησιμοποιεί το VM σας το VPN του κεντρικού υπολογιστή; Δοκιμάστε το μέσα από τον φιλοξενούμενο

Ελέγχετε τη δημόσια IP του κεντρικού υπολογιστή, εμφανίζει το VPN και συμπεραίνετε ότι το VM καλύπτεται. Αυτό το συμπέρασμα δεν το στηρίζει η δοκιμή. Ο φιλοξενούμενος έχει τον δικό του πίνακα δρομολόγησης, τον δικό του resolver και τις δικές του διεπαφές, και η διεύθυνση εξόδου του κεντρικού υπολογιστή δεν λέει τίποτα γι' αυτές.

Η δοκιμή πρέπει να εκτελεστεί μέσα στον φιλοξενούμενο και πρέπει να ονομάσει τι μέτρησε.

Ξεκινήστε μέσα στον φιλοξενούμενο, όχι στο πρόγραμμα περιήγησης του κεντρικού υπολογιστή

Καταγράψτε πρώτα τη λειτουργία δικτύου του hypervisor: NAT, bridged, host-only ή macvtap. Στη λειτουργία NAT ο κεντρικός υπολογιστής δρομολογεί την κίνηση του φιλοξενούμενου, οπότε η σήραγγα του κεντρικού υπολογιστή μπορεί να ισχύει ή όχι ανάλογα με το πώς ο πελάτης εγκαθιστά διαδρομές. Στη λειτουργία bridged ο φιλοξενούμενος είναι ισότιμος στο φυσικό LAN και η σήραγγα του κεντρικού υπολογιστή είναι άσχετη. Αυτές οι δύο λειτουργίες δίνουν αντίθετες απαντήσεις από την ίδια διαμόρφωση του κεντρικού υπολογιστή.

Γράψτε τη λειτουργία πριν αλλάξετε οτιδήποτε, γιατί αυτή καθορίζει τι μπορεί να σημαίνει το αποτέλεσμα.

Κάντε ένα αίτημα του οποίου γνωρίζετε τον προορισμό

Χρησιμοποιήστε ένα ακίνδυνο αίτημα προς μια υπηρεσία που αναφέρει τη διεύθυνση προέλευσης που είδε. Στη συνέχεια ελέγξτε την απόφαση δρομολόγησης του ίδιου του φιλοξενούμενου για αυτόν τον προορισμό: ip route get 203.0.113.5 εκτυπώνει τη διεπαφή και την πύλη που θα χρησιμοποιήσει ο φιλοξενούμενος.

Αν η διεπαφή είναι η κανονική κάρτα δικτύου του φιλοξενούμενου, η κίνηση δεν περνά από σήραγγα μέσα στον φιλοξενούμενο.

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

Ελέγξτε τον resolver ξεχωριστά

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

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

Σε κεντρικό υπολογιστή με systemd, resolvectl query ονομάζει τη διεπαφή και τον διακομιστή DNS πίσω από την απάντηση. Παλαιότερες εγκαταστάσεις εμφανίζουν τον διακομιστή στην έξοδο του dig — σε κάθε περίπτωση το ζητούμενο είναι να δείτε ποιος διακομιστής απάντησε, όχι μόνο αν ήρθε απάντηση.

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

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

Ένας φιλοξενούμενος που επιστρέφει στη φυσική κάρτα δικτύου όταν πέσει η σήραγγα κάνει ακριβώς αυτό που επιτρέπει η λειτουργία NAT.

Καταγράψτε τη λειτουργία και το εύρος

Γράψτε τη λειτουργία του hypervisor, τη διεπαφή και τη διαδρομή του φιλοξενούμενου, τον resolver και την εφαρμογή που δοκιμάσατε. Προσθέστε την ημερομηνία, γιατί η επαναφορά ενός snapshot ή μια ενημέρωση του hypervisor μπορεί να αλλάξουν και τα τέσσερα.

Αν το IPv4 ακολούθησε τη σήραγγα, πείτε το. Μην επεκτείνετε τον ισχυρισμό στο IPv6, σε άλλο χώρο ονομάτων ή σε άλλο VM σε άλλο δίκτυο.