Το VM του Azure δεν φτάνει το IMDS ή το WireServer αφού ξεκινήσει το VPN

Το VM είναι ενεργό, ο πελάτης VPN λέει ότι συνδέθηκε, και λίγα λεπτά αργότερα ο agent του Azure αρχίζει να αναφέρει ανθυγιεινή κατάσταση. Μερικές φορές η SSH επιβιώνει και το Run Command από την πύλη όχι, κάτι που στέλνει τους ανθρώπους στον agent αντί στον πίνακα δρομολόγησης. Οι δικές του αποφάσεις προώθησης του επισκέπτη άλλαξαν όταν ανέβηκε η σήραγγα, και δύο διευθύνσεις πλατφόρμας είναι συνήθως τα πρώτα θύματα. Το αντιμετωπίζω ως σύμπτωμα δρομολόγησης πριν το αντιμετωπίσω ως βλάβη του agent.

Το σύμπτωμα μοιάζει με χαλασμένο agent

Και οι δύο διευθύνσεις παρακάτω προτείνονται ως διόρθωση, και δεν είναι η ίδια υπηρεσία. Το αντίγραφο ενός /32 για τη μία επειδή δούλεψε για την άλλη είναι ακριβώς το πώς μια προσωρινή λύση γίνεται μόνιμη ρύθμιση που κανείς δεν τολμά να αφαιρέσει.

Η σειρά που δουλεύει είναι να επιβεβαιώσετε ποια διεύθυνση στοχεύει πραγματικά η αποτυχημένη κλήση, και μετά να διαβάσετε πώς την επιλύει ο επισκέπτης. Οτιδήποτε άλλο είναι εικασία με επιπλέον βήματα και μεγαλύτερο παράθυρο αλλαγής.

Το 168.63.129.16 δεν είναι δημόσιος προορισμός

Το 168.63.129.16 είναι η ειδική εικονική διεύθυνση πλατφόρμας του Azure, και ένας από τους ρόλους της είναι το WireServer, το οποίο ο agent του VM χρησιμοποιεί για να μιλά στο fabric. Η Microsoft τεκμηριώνει ότι η κίνηση του agent προς τις θύρες TCP 80 και 32526 πρέπει να παραμένει διαθέσιμη. Δεν είναι ένας συνηθισμένος διαδικτυακός κόμβος, και δεν είναι κάτι που ένα VPN πλήρους σήραγγας θα έπρεπε να μεταφέρει σε απομακρυσμένη έξοδο. Γι' αυτό μια σήραγγα που φαίνεται υγιής μπορεί ακόμα να λιμοκτονήσει τον agent.

Η τεκμηρίωση της διεύθυνσης πλατφόρμας λέει επίσης ότι αυτή η διεύθυνση δεν υπόκειται σε διαδρομές καθορισμένες από τον χρήστη, που είναι ιδιότητα του fabric του Azure και όχι υπόσχεση για τον επισκέπτη σας. Ένας τοπικός κανόνας τείχους προστασίας ή η δική του πολιτική δρομολόγησης του πελάτη VPN μπορεί ακόμα να σπάσει τη διαδρομή, και κανένα από τα δύο δεν ζει στον πίνακα δρομολόγησης του VNet.

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

Το 169.254.169.254 έχει τους δικούς του κανόνες

Το 169.254.169.254 είναι η link-local διεύθυνση για την υπηρεσία Azure Instance Metadata Service. Τα αιτήματα προς αυτήν έχουν τις δικές τους απαιτήσεις: την κύρια NIC και την κύρια IP, μια ρύθμιση DHCP που υποστηρίζει τη διεύθυνση, και παράκαμψη κάθε HTTP proxy. Η αποστολή τους μέσω απομακρυσμένης εξόδου VPN ή αυθαίρετης πύλης διαδικτύου δεν είναι το μοντέλο πρόσβασης που περιγράφει η Microsoft.

Αυτή η ρήτρα proxy πιάνει όσους διόρθωσαν τη διαδρομή και βλέπουν ακόμα αποτυχίες. Ένα HTTP proxy στον επισκέπτη μπορεί να σπάσει το IMDS ενώ το ip route get επιστρέφει ακριβώς τη διεπαφή που περιμένετε, οπότε ελέγξτε τις εξαιρέσεις proxy μαζί με τις διαδρομές.

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

Διαβάστε το policy routing του επισκέπτη, όχι μόνο τον κύριο πίνακα

Σε επισκέπτη Linux, τρεις εντολές μόνο για ανάγνωση χωρίζουν τα επίπεδα: ip -4 rule show για τους κανόνες πολιτικής, μετά ip -4 route get 168.63.129.16 και ip -4 route get 169.254.169.254 για τις αποφάσεις που παίρνει πραγματικά ο πυρήνας. Εκτελέστε τις πριν και αφού συνδεθεί το VPN. Η διαφορά μεταξύ αυτών των εξόδων είναι το σύνολο αλλαγών σας, και είναι πιο χρήσιμη από οποιαδήποτε εικασία για το τι έκανε ο πελάτης.

Ένας πελάτης VPN που εγκαθιστά κανόνες πολιτικής μπορεί να αφήσει τον κύριο πίνακα άθικτο και να ανακατευθύνει ακόμα αυτές τις αναζητήσεις. Γι' αυτό μια διόρθωση μόνο του κύριου πίνακα φαίνεται να δουλεύει σε έναν κόμβο και δεν κάνει τίποτα στον επόμενο. Επισκέπτες με πολλές NIC προσθέτουν το ίδιο πρόβλημα από την άλλη κατεύθυνση, γιατί η απάντηση εξαρτάται από το ποια NIC και ποια διεύθυνση πηγής επιλέγει ο κανόνας.

Αντισταθείτε στη συνταγή που προσθέτει και τις δύο διαδρομές /32 μέσω της παλιάς πύλης. Μια link-local διαδρομή πλατφόρμας και ένα γενικό επόμενο άλμα WAN είναι διαφορετικά αντικείμενα, και μια γενική εξαίρεση κρύβει την πραγματική σύγκρουση πολιτικών.

Κρατήστε τη διαχείριση και την ανάκτηση χωριστά

Η απάντηση SSH ή RDP μπορεί επίσης να συλληφθεί από ένα default πλήρους σήραγγας, αλλά στοχεύει τη διεύθυνση που παρατηρεί ο διαχειριστής και όχι κάποιο άκρο της πλατφόρμας. Διαγνώστε την από το δικό της ζεύγος αιτήματος-απάντησης, και κρατήστε ένα ανεξάρτητο κανάλι ανάκτησης όπως η σειριακή κονσόλα πριν αλλάξετε την πολιτική VPN. Αν μια ανάπτυξη επανεκκινήσει το VM και ο agent αναφέρει ανθυγιεινή κατάσταση, εξετάστε την καταγεγραμμένη ενέργεια και την υπεύθυνη υπηρεσία αντί να υποθέσετε ότι η αλλαγή διαδρομής προκάλεσε την επανεκκίνηση.

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

Γράψτε την εγκεκριμένη εξαίρεση στον ιδιοκτήτη του δικτύου του επισκέπτη και της ρύθμισης VPN, μαζί με το τι συμβαίνει στην επανασύνδεση και την επανεκκίνηση. Τα UDR του Azure δεν είναι ο πίνακας δρομολόγησης του επισκέπτη, και η επεξεργασία τους δεν θα διορθώσει έναν τοπικό κανόνα πολιτικής.