Όνομα τελικού σημείου VPN έναντι ονόματος ιδιωτικής υπηρεσίας: δύο ιδιοκτήτες

Δύο ονόματα μπορούν να περιγράφουν το ίδιο υποκατάστημα και να απαντούν σε εντελώς διαφορετικά ερωτήματα. Το vpn.branch.example λέει σε έναν απομακρυσμένο ομότιμο πού να βρει το τελικό σημείο VPN, και πρέπει να επιλυθεί πριν υπάρξει οποιοδήποτε τούνελ. Το inventory.branch.example λέει σε έναν εξουσιοδοτημένο χρήστη πού ζει μια ιδιωτική εφαρμογή, και έχει σημασία μόνο όταν το τούνελ είναι ενεργό. Η συντήρηση του ενός δεν κάνει τίποτα για το άλλο.

Ονομάστε τις δύο εγγραφές πριν αποσφαλματώσετε οποιαδήποτε από τις δύο

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

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

Όταν προτείνεται μια αλλαγή, ρωτήστε ποια από τις δύο εγγραφές αγγίζει. Αν κανείς δεν μπορεί να απαντήσει, η αλλαγή δεν είναι έτοιμη για προγραμματισμό.

Το τελικό σημείο πρέπει να επιλυθεί πριν υπάρξει οποιοδήποτε τούνελ

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

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

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

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

Το όνομα της υπηρεσίας περιγράφει πού ζει η εφαρμογή

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

Εδώ συγχέονται δύο μηχανισμοί ενημέρωσης. Το RFC 2136 ορίζει ένα πρωτόκολλο για την προσθήκη και διαγραφή εγγραφών DNS σε μια ζώνη, ενώ ένας εμπορικός πάροχος δυναμικού DNS μπορεί να εκθέτει ένα εντελώς διαφορετικό HTTP API για άλλο σκοπό. Η χρήση του ενός δεν συνεπάγεται ότι το άλλο υπάρχει στο περιβάλλον σας. Ελέγξτε ποιον μηχανισμό δέχεται πραγματικά η ζώνη σας πριν γράψετε ενημερωτή εναντίον του.

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

Δοκιμάστε τις δύο διαδρομές χωριστά

Ελέγξτε το τελικό σημείο από έξω από το τούνελ και την υπηρεσία από μέσα, και κρατήστε τα αποτελέσματα ως δύο ανεξάρτητα γεγονότα:

$ dig +short vpn.branch.example @1.1.1.1
$ dig +short inventory.branch.example @172.26.0.53
$ ip route get 172.26.14.35

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

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