VPN τοποθεσίας σε τοποθεσία στο Azure με peer πίσω από NAT: λίστα ελέγχου

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

Βήμα 1: επιβεβαιώστε ότι ο peer είναι όντως πίσω από NAT

Συγκρίνετε τη διεύθυνση στη διεπαφή WAN της συσκευής με τη διεύθυνση που βλέπει το Azure γι’ αυτήν. Αν διαφέρουν, κάτι μεταφράζει, και αυτός ο μεταφραστής είναι πλέον μέρος του σχεδιασμού VPN σας. Ρωτήστε τον πάροχο αν η αντιστοίχιση είναι στατική ή κοινόχρηστη, γιατί μια κοινόχρηστη αντιστοίχιση αλλάζει το τι μπορείτε να περιμένετε. Συσκευή με ιδιωτική διεύθυνση WAN και χωρίς προώθηση είναι διαφορετική περίπτωση από μία πίσω από NAT επιπέδου παρόχου με σταθερή δημόσια αντιστοίχιση.

Αν οι δύο διευθύνσεις ταιριάζουν, σταματήστε εδώ: το NAT δεν είναι το πρόβλημά σας και το υπόλοιπο της λίστας δεν θα βοηθήσει.

Καταγράψτε και τις δύο διευθύνσεις και το μοντέλο του μεταφραστή στο δελτίο. Αυτή η μία γραμμή αποτρέπει τον επόμενο γύρο ερωτήσεων για το γιατί ο ρυθμισμένος peer δεν απαντά.

Βήμα 2: συμφωνήστε ποιος ξεκινά

Το Azure VPN Gateway FAQ αναφέρει υποστήριξη NAT-T και προσθέτει ότι η τοπική συσκευή πρέπει να ξεκινά το τούνελ IPsec όταν βρίσκεται πίσω από NAT. Αυτό ταιριάζει με το πώς λειτουργεί η μετάφραση με κατάσταση, αφού ο μεταφραστής κρατά αντιστοίχιση επειδή η εσωτερική συσκευή έστειλε το πρώτο πακέτο. Αν αναμένεται να ξεκινήσει το Azure και δεν φτάνει τίποτα για να δημιουργήσει αυτή την αντιστοίχιση, το τούνελ δεν ξεκινά ποτέ.

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

Παρακολουθήστε την ανταλλαγή IKE στη συσκευή κατά τη χειροκίνητη έναρξη· η σιωπή εκεί είναι απάντηση δρομολόγησης ή τείχους προστασίας, όχι απάντηση του Azure.

Βήμα 3: βάλτε σωστά τη διεύθυνση του peer

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

Αν αλλάξει η δημόσια διεύθυνση, πρέπει να αλλάξει μαζί της και αυτό το αντικείμενο. Ένα όνομα που αναλύεται σε παρωχημένη διεύθυνση είναι χειρότερο από μια στατική που πρέπει να ενημερώσετε με το χέρι.

Σημειώστε και τις τρεις τιμές: τοπική διεύθυνση συσκευής, μεταφρασμένη δημόσια διεύθυνση, ρυθμισμένη ταυτότητα peer.

Βήμα 4: ανοίξτε μόνο τις θύρες που χρειάζεται το NAT-T

Το NAT-T μεταφέρει ESP μέσα σε UDP, και το RFC 3948 περιγράφει αυτή την ενθυλάκωση με θύρα 4500 που χρησιμοποιείται μετά την αρχική διαπραγμάτευση στη θύρα 500. Το τείχος προστασίας σας και ο μεταφραστής πρέπει και τα δύο να επιτρέπουν την ανταλλαγή και την κίνηση επιστροφής της. Το να επιτρέπεται μια άσχετη θύρα TCP δεν αποδεικνύει τίποτα για αυτή τη διαδρομή, και ένας κανόνας που επιτρέπει την έξοδο αλλά όχι την απάντηση θα αποτύχει ακόμα.

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

Καταγράψτε μία φορά και στις δύο πλευρές του μεταφραστή· η διαφορά ενθυλάκωσης φαίνεται αμέσως.

Βήμα 5: ξεχωρίστε την εξωτερική μεταφορά από την εσωτερική δρομολόγηση

Ένα τούνελ που εγκαθίσταται και δεν μεταφέρει τίποτα είναι πρόβλημα δρομολόγησης, όχι NAT-T. Οι τοποθεσίες χρειάζονται ακόμα συμβατούς επιλογείς κίνησης, αντίστοιχους χώρους διευθύνσεων, κανόνες πρόσβασης και διαδρομή επιστροφής για τα δίκτυα εφαρμογών. Τίποτα από αυτά δεν τα παρέχει μια επιτυχημένη ανταλλαγή IKE.

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

Ταξινομήστε την αποτυχία ανά στάδιο πριν αλλάξετε οτιδήποτε, και κρατήστε αυτή την ταξινόμηση στο δελτίο ώστε ο επόμενος να ξεκινήσει από εκεί που σταματήσατε.