Η επιστροφική κίνηση του Azure P2S VPN λειτουργεί μόνο προς μία κατεύθυνση

Το εικονίδιο της σήραγγας είναι πράσινο, το NSG φαίνεται επιτρεπτικό, οι ενεργές διαδρομές φαίνονται σωστές, και όμως η VM δεν μπορεί να ανοίξει σύνδεση πίσω προς τον συνδεδεμένο πελάτη. Η συνήθης υπόθεση είναι ότι μια λειτουργική σήραγγα point-to-site είναι συμμετρική: αν ο πελάτης φτάνει στη VM, η VM φτάνει στον πελάτη. Αυτή η υπόθεση είναι το σφάλμα στη συλλογιστική, όχι στη διαμόρφωση. Μια σήραγγα μπορεί να μεταφέρει τη μία κατεύθυνση μιας μη ζητημένης ροής και να απορρίπτει την άλλη, και η διόρθωση εξαρτάται από το ποιο επίπεδο την απορρίπτει.

Μύθος: μια συνδεδεμένη σήραγγα είναι αμφίδρομη

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

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

Ελέγξτε την κατεύθυνση πριν ελέγξετε την προσβασιμότητα

Επιλέξτε μία διεύθυνση πελάτη, μία διεύθυνση VM και ένα πρωτόκολλο. Συνδεθείτε από τον πελάτη και καταγράψτε το αποτέλεσμα· μετά ξεκινήστε την ίδια δοκιμή από τη VM και καταγράψτε και αυτή. Αν η πρώτη πετύχει και η δεύτερη αποτύχει, η δεξαμενή πελατών, η συσχέτιση της πύλης και η διαδρομή από τον πελάτη στο VNet λειτουργούν όλες.

Το επόμενο βήμα είναι αποδεικτικά στοιχεία, όχι περισσότεροι κανόνες. Ελέγξτε το NSG στο υποδίκτυο της VM και προς τις δύο κατευθύνσεις, διαβάστε τις ενεργές διαδρομές στην κάρτα δικτύου της VM και καταγράψτε πακέτα στη VM όσο ο πελάτης στέλνει κίνηση. Ένα αίτημα που φτάνει χωρίς απάντηση είναι πρόβλημα φίλτρου ή διαδρομής επιστροφής· ένα αίτημα που δεν φτάνει ποτέ είναι πρόβλημα διαδρομής. Μην θεωρείτε αποτυχημένο ping απόδειξη ότι η VM είναι μη προσβάσιμη, γιατί μια πολιτική ICMP μπορεί να απορρίπτει την απάντηση ενώ το TCP λειτουργεί.

Η διαδρομή επιστροφής IKEv2 point-to-site είναι ο συνήθης ύποπτος

Στην αναφορά Azure πίσω από αυτό το άρθρο, ένας πελάτης μπορούσε να φτάσει τις VM μέσω IKEv2, αλλά το εισερχόμενο ICMP από τη VM προς τον πελάτη αποτύγχανε μέχρι να αλλάξει ο τύπος σήραγγας της πύλης σε OpenVPN. Ο συντάκτης της αναφοράς δηλώνει ότι η Microsoft επιβεβαίωσε περιορισμό στη διαδρομή IKEv2 point-to-site, όπου η επιστροφική κίνηση από μια VM προς τον πελάτη δεν δρομολογείται συμμετρικά εκτός αν ο πελάτης ξεκίνησε τη συνεδρία. Το IKEv2 βασίζεται σε επιλογείς κίνησης και η πύλη δεν τίμησε την κατεύθυνση επιστροφής σε εκείνη την περίπτωση.

Αυτό δεν κάνει το OpenVPN γενικά τον καλύτερο τύπο σήραγγας. Κάνει τον τύπο σήραγγας μεταβλητή στον πίνακα δοκιμών για αυτό το φόρτο εργασίας.

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

Μύθος: η ανακάλυψη μέσω broadcast περνά τα όρια του VNet

Μια δεύτερη υπόθεση αποτυγχάνει για άσχετο λόγο. Ένα εικονικό δίκτυο Azure δεν μεταφέρει κίνηση broadcast, οπότε μια VM δεν μπορεί να λάβει πλαίσια broadcast από τοπικό δίκτυο μέσω σύνδεσης site-to-site ή point-to-site. Εφαρμογές που βρίσκουν ομοτίμους μέσω broadcast, όπως παλαιότερη περιήγηση αρχείων ή ορισμένα πρωτόκολλα ανακάλυψης συσκευών, δεν θα δουν ποτέ την απομακρυσμένη πλευρά, όσο σωστά κι αν είναι γραμμένες οι διαδρομές.

Αντικαταστήστε την ανακάλυψη μέσω broadcast με ονόματα DNS, υπηρεσία καταλόγου ή ρητή λίστα ομοτίμων. Αν η εφαρμογή δεν έχει εναλλακτική unicast, ο σχεδιασμός χρειάζεται διαφορετικό μηχανισμό ανακάλυψης, όχι ευρύτερη σήραγγα.

Τι να αλλάξετε και πώς να το αποδείξετε

Αν η δοκιμή κατεύθυνσης αποτυγχάνει μόνο στο IKEv2, καταγράψτε τον τύπο σήραγγας της πύλης, τη δεξαμενή διευθύνσεων πελατών και την ακριβή δοκιμή ICMP ή TCP, και μετά αξιολογήστε ένα εγκεκριμένο προφίλ OpenVPN για τους επηρεαζόμενους πελάτες. Αν αποτυγχάνει σε κάθε τύπο σήραγγας, δουλέψτε τη διαδρομή επιστροφής: η διεύθυνση του πελάτη πρέπει να είναι δρομολογήσιμη από το υποδίκτυο της VM, κάθε διαδρομή που ορίζει ο χρήστης πρέπει να δείχνει σε έγκυρο επόμενο άλμα, και το firewall του πελάτη πρέπει να δέχεται την εισερχόμενη ροή. Επισυνάψτε τα στοιχεία NSG και διαδρομών στο δελτίο.

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