S2S VPN στο Azure συνδεδεμένο αλλά χωρίς κίνηση: διαβάστε το αρχείο IKE

Η πύλη λέει Connected, η σήραγγα έχει μετρητή χρόνου λειτουργίας, και ένα trace από την εικονική σας μηχανή πεθαίνει στο δεύτερο hop. Η κατάσταση σύνδεσης περιγράφει τη διαπραγμάτευση IKE και IPsec, όχι αν ένα πακέτο επιβιώνει από το επίπεδο πολιτικών σε οποιαδήποτε πλευρά. Δύο σφάλματα εξηγούν τα περισσότερα από αυτά τα δελτία, και κανένα από τα δύο δεν διορθώνεται αλλάζοντας μια διαδρομή στο Azure. Και τα δύο είναι ήδη γραμμένα στο αρχείο που παρήγαγε η πύλη, γι’ αυτό ξεκινώ εκεί και όχι στον πίνακα διαδρομών.

Τι πιστοποιεί στην πραγματικότητα το Connected

Μια συνδεδεμένη σύνδεση site-to-site σημαίνει ότι η φάση 1 και η φάση 2 ολοκληρώθηκαν και οι συσχετίσεις ασφαλείας είναι ενεργές. Αυτή είναι μια δήλωση για τη διαπραγμάτευση: και τα δύο μέρη συμφώνησαν σε μια πρόταση, αντάλλαξαν κλειδιά και εγκατέστησαν το ζεύγος SA. Δεν λέει τίποτα για το αν οι επιλογείς κίνησης ταιριάζουν με τα υποδίκτυα που θεωρείτε προστατευμένα, ούτε για το αν η απομακρυσμένη πλευρά θα δρομολογήσει το πακέτο κάπου αφού το αποκρυπτογραφήσει. Μια σήραγγα μπορεί να μένει ενεργή για εβδομάδες ενώ απορρίπτει κάθε ενδιαφέρουσα ροή, και αυτό είναι ακριβώς το μοτίβο που κάνει τους ανθρώπους να ξαναχτίζουν μια υγιή πύλη.

Τα δύο σφάλματα που αξίζει να ελέγξετε πρώτα είναι ένα peer που προτείνει AH αντί για ESP, και ένα εικονικό δίκτυο αριθμημένο σε χώρο που η πύλη δεν θα αντιμετωπίσει ως εσωτερικό.

Ανοίξτε το εξαγόμενο αρχείο πριν αγγίξετε διαδρομές

Στην πύλη, ανοίξτε την πύλη εικονικού δικτύου και εκτελέστε τη λειτουργία VPN troubleshoot στη σύνδεση, και μετά κατεβάστε το πακέτο που παράγει και αποσυμπιέστε το. Μέσα υπάρχει ένα αρχείο IKE με τις ανταλλαγές φάσης 1 και φάσης 2, με χρονικές σφραγίδες και αναγνώσιμο ως απλό κείμενο. Αναζητήστε σε αυτό τη γραμμή transform αντί να διαβάζετε από πάνω προς τα κάτω, γιατί η ενδιαφέρουσα καταχώριση βρίσκεται συνήθως μερικές εκατοντάδες γραμμές πιο μέσα. Αν δεν έχετε πρόσβαση στην πύλη, τα ίδια διαγνωστικά εμφανίζονται στον προορισμό αρχείων της πύλης όταν είναι ενεργοποιημένες οι ρυθμίσεις διαγνωστικών.

Δύο καταχωρίσεις φέρουν το μεγαλύτερο μέρος της αξίας. Η πρώτη λέει περίπου expected ESP with combined authentication and cipher, received AH. Η δεύτερη είναι σφάλμα μη έγκυρου payload κατά την ανταλλαγή IKE, που συνήθως σημαίνει πεδίο πρότασης με λάθος μορφή ή μη υποστηριζόμενο.

Και οι δύο περιγράφουν τι πρόσφερε η τοπική συσκευή, άρα και οι δύο είναι ρυθμίσεις στην πλευρά του peer. Η αναδημιουργία της πλευράς Azure της σύνδεσης δεν αλλάζει την πρόταση που στέλνει το firewall σας, και το να το κάνετε παρ’ όλα αυτά είναι η πιο συχνά χαμένη ώρα σε αυτή τη ροή εργασίας. Στο peer, θέστε τη φάση 2 σε ESP με συνδυασμένη πιστοποίηση και κρυπτογράφηση και αφήστε το να διαπραγματευτεί τον αλγόριθμο, μετά ελέγξτε αν ένα πλαίσιο ελέγχου του κατασκευαστή με όνομα σαν combined mode επιλέγει σιωπηλά μια πρόταση AH από κάτω.

Επιβεβαιώστε τον χώρο διευθύνσεων του εικονικού δικτύου

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

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

Επαληθεύστε τα προθέματα και προς τις δύο κατευθύνσεις

Ο πόρος της πύλης τοπικού δικτύου κρατά τα τοπικά προθέματα, και πρέπει να ταιριάζουν με τα υποδίκτυα που η απομακρυσμένη συσκευή προστατεύει πραγματικά. Μια σύνοψη που περιλαμβάνει διευθύνσεις που η συσκευή απορρίπτει θα περάσει μερικές ροές και θα αποτύχει σε άλλες, κάτι που διαβάζεται ως διακοπτόμενη αστοχία δρομολόγησης και όχι ως αναντιστοιχία διαμόρφωσης. Ελέγξτε και την απομακρυσμένη πλευρά: το ένα άκρο να εμφανίζει /16 ενώ το άλλο τρία /24 μέσα σε αυτό είναι η κλασική μερική αστοχία. Καμία λίστα δεν είναι αξιόπιστη μόνη της, γι’ αυτό συγκρίνετε τις δίπλα δίπλα αντί να εμπιστεύεστε αυτή που βλέπετε.

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

Δοκιμάστε μια διαδρομή, όχι ένα ping

Το trace που ξεχωρίζει μια σήραγγα που δουλεύει από μια διαδρομή που δουλεύει μοιάζει έτσι: πρώτο hop είναι η τοπική πύλη, μετά μερικά hop χωρίς απόκριση, μετά απαντά ο απομακρυσμένος host. Αν το trace δεν φτάσει ποτέ στον host, δοκιμάστε τη θύρα TCP που χρησιμοποιεί πραγματικά η εφαρμογή, γιατί το ICMP φιλτράρεται αρκετά συχνά ώστε ένα αποτυχημένο ping να αποδεικνύει ελάχιστα. Εκτελέστε το ίδιο trace από έναν απομακρυσμένο host προς μια εικονική μηχανή στο Azure. Η ασυμμετρία μεταξύ των δύο αποτελεσμάτων είναι ο ταχύτερος τρόπος να βρείτε μια διαδρομή επιστροφής που λείπει ή έναν κανόνα που επιτρέπει μόνο μία κατεύθυνση.

Γράψτε την πρόταση του peer, τους δύο χώρους διευθύνσεων και τον χρόνο δημιουργίας της σύνδεσης στο δελτίο, ώστε ο επόμενος μηχανικός να ξέρει ποιες τιμές ξαναχτίστηκαν και ποιες δεν αγγίχτηκαν ποτέ.

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