Και τα δύο VNet χρησιμοποιούν 10.40.1.0/24, οι σήραγγες ανεβαίνουν και τίποτα δεν λειτουργεί. Η προσθήκη δεύτερης πύλης VPN δεν το αλλάζει, ούτε μια χαμηλότερη μετρική διαδρομής, γιατί το πρόβλημα δεν είναι η επιλογή μονοπατιού. Δύο φόρτοι εργασίας που απαντούν στην ίδια ιδιωτική διεύθυνση αφήνουν κάθε πακέτο με αμφίσημο προορισμό και μη επαληθεύσιμη διαδρομή επιστροφής. Πριν σχεδιάσετε οποιαδήποτε μετάφραση, βρείτε ποιον τύπο σύνδεσης δημιουργήσατε πραγματικά, γιατί αυτή η μία επιλογή καθορίζει αν η δυνατότητα NAT του Azure είναι διαθέσιμη καθόλου.

Τι σας λέει στην πραγματικότητα το σύμπτωμα

Όταν ένας κεντρικός υπολογιστής στο VNet A στέλνει στη 10.40.1.10, ο πίνακας δρομολόγησης μπορεί μόνο να το κατευθύνει κάπου. Αν και το VNet B περιέχει τη 10.40.1.10, αυτή η διεύθυνση δεν είναι προορισμός που μπορεί να διακρίνει η διαδρομή· είναι μία διεύθυνση με δύο κατόχους.

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

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

Ο τύπος σύνδεσης καθορίζει αν το NAT είναι διαθέσιμο

Το Azure VPN Gateway έχει πράγματι δυνατότητα NAT, και είναι τεκμηριωμένη για συνδέσεις IPsec μεταξύ εγκαταστάσεων βασισμένες σε δρομολόγηση σε συγκεκριμένα SKU πύλης. Η ίδια τεκμηρίωση εξαιρεί τις συνδέσεις VNet-to-VNet και point-to-site, οπότε η δυνατότητα δεν είναι ένα πλαίσιο ελέγχου που εμφανίζεται σε κάθε σχέση πύλης.

Connection typeNAT supportOverlap workaround
Site-to-Site (route-based IPsec, documented SKUs)Supported with configured NAT rulesTranslate the range in the rules
VNet-to-VNet (Vnet2Vnet)Not supportedRenumber, or redesign as a site-to-site connection
Point-to-siteNot supportedChoose client address pools that do not collide

Το εγγενές VNet-to-VNet απαιτεί επίσης τα εύρη VNet και τοπικού δικτύου να μην επικαλύπτονται από την αρχή, κάτι που συνάδει με την εξαίρεση. Η ομότιμη σύνδεση VNet δεν είναι λύση επικάλυψης για τον ίδιο λόγο.

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

Αλλάξτε αρίθμηση ή μεταφράστε με κάτι που κατέχει το ψευδώνυμο

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

Όπου η αλλαγή αρίθμησης δεν είναι πρακτική, χρησιμοποιήστε μεταφρασμένο σχεδιασμό με πραγματικό κάτοχο του ψευδωνύμου. Οι καλούντες στο VNet A μπορεί να φτάνουν τη 10.40.1.10 του VNet B ως 10.140.1.10, αλλά αυτό το ψευδώνυμο χρειάζεται συσκευή που μεταφράζει, διαδρομή προς αυτήν και αντίστοιχη συμπεριφορά για την απάντηση. Μια διεύθυνση που προστέθηκε μόνο στο DNS δεν είναι μετάφραση.

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

Τι δεν θα λειτουργήσει

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

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

Αποδεχτείτε τον σχεδιασμό με κίνηση και στις δύο κατευθύνσεις

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

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

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

Σχετικά άρθρα