Χρειάζεστε δυναμικό DNS για οικιακό διακομιστή VPN;

Οι περισσότερες αστοχίες οικιακού VPN για τις οποίες με ρωτούν δεν είναι αστοχίες DNS, και παρ’ όλα αυτά αγοράζουν πρώτα συνδρομή δυναμικού DNS. Πριν ρυθμίσετε οτιδήποτε, αποφασίστε αν το όνομα κεντρικού υπολογιστή είναι το κομμάτι που είναι όντως χαλασμένο. Ένας ενημερωτής ξαναγράφει μια εγγραφή όταν μετακινείται η διεύθυνση που σας έδωσε ο πάροχος· δεν μπορεί να ανοίξει θύρα, να διαπεράσει το NAT του φορέα ή να κάνει μια ζωντανή συνεδρία WireGuard να αντιληφθεί ότι άλλαξε το τελικό της σημείο. Τρεις συνθήκες κρίνουν αν το δυναμικό DNS είναι όλη η λύση ή μόνο μία γραμμή της.

Συνθήκη πρώτη: η διεύθυνσή σας μετακινείται πράγματι

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

Μετρήστε το αντί να μαντέψετε. Διαβάστε τη διεύθυνση WAN στη σελίδα κατάστασης του δρομολογητή και συγκρίνετε τη με αυτό που βλέπει ο έξω κόσμος. Εκτελέστε το από μηχάνημα στο LAN:

curl -fsS https://api.ipify.org; echo

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

Συνθήκη δεύτερη: οι πελάτες κοιτούν ξανά το όνομα

Το σύντομο TTL είναι το κομμάτι που παραλείπουν. Οι αναδρομικοί επιλυτές σέβονται το TTL της εγγραφής, αλλά οι στοίβες πελατών κάνουν προσωρινή αποθήκευση χωριστά, και μια σήραγγα που έχει ήδη σηκωθεί δεν επιλύει τίποτα ξανά. Ρυθμίστε την εγγραφή στα 60-300 δευτερόλεπτα όσο αποσφαλματώνετε· αυτό συντομεύει το παράθυρο όπου σερβίρεται παλιά απάντηση και δεν μεταναστεύει μια συνδεδεμένη συνεδρία.

OpenVPN επιλύει ξανά τη γραμμή remote vpn.example.net 1194 σε κάθε επανασύνδεση, και το resolv-retry infinite το κρατά να ξαναπροσπαθεί αντί να τερματίζει όταν η αναζήτηση αποτυγχάνει. Στον διακομιστή, το float επιτρέπει σε μια εδραιωμένη συνεδρία να ακολουθεί ομότιμο του οποίου άλλαξε η διεύθυνση προέλευσης. Το WireGuard είναι πιο άμεσο: το wg-quick up επιλύει το Endpoint όταν εφαρμόζεται η διαμόρφωση, και ο πελάτης το επιλύει ξανά όταν ξαναχτίζει τη σήραγγα, οπότε μια χειραψία που ακόμη πετυχαίνει στην παλιά διεύθυνση συνεχίζει να πετυχαίνει ώσπου να σταματήσει.

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

Συνθήκη τρίτη: η διαδρομή προς τα μέσα είναι ακόμη ανοιχτή

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

Δοκιμάστε από έξω. Ένα τηλέφωνο σε δεδομένα κινητής με το Wi-Fi κλειστό είναι η φθηνότερη έντιμη δοκιμή· ένα φορητό στον ίδιο LAN δεν είναι. Όταν το όνομα επιλύεται στη δημόσια διεύθυνσή σας και ο δρομολογητής δεν έχει βρόχο NAT, μια εσωτερική δοκιμή αποτυγχάνει ενώ η εγγραφή είναι απόλυτα σωστή, και αυτό στέλνει τους περισσότερους να διορθώσουν μια εγγραφή που δεν ήταν ποτέ λάθος.

Τι να εκτελέσετε όταν ισχύουν και οι τρεις

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

protocol=dyndns2
use=web, web=https://api.ipify.org
server=updates.your-dns-provider.net
login=vpn-home
password=update-token
vpn.example.net

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

Επαληθεύστε πριν δεσμευτείτε

Μία αναζήτηση σας λέει τι βλέπει ο υπόλοιπος κόσμος και εκτυπώνει το TTL που πρέπει να περιμένετε μετά από αλλαγή:

dig +noall +answer vpn.example.net @1.1.1.1

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

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

Όταν η απάντηση είναι όχι

Αν αποτύχει η πρώτη ή η τρίτη συνθήκη, αλλάζει η απόφαση και όχι η διαμόρφωση. Πίσω από NAT φορέα οι πρακτικές επιλογές σας είναι να ζητήσετε δημόσια διεύθυνση από τον πάροχο, να μετακινήσετε το σημείο εισόδου σε μικρό VPS με σταθερή διεύθυνση, ή να χρησιμοποιήσετε επικάλυψη που κρατά τη δική της συνάντηση. Αν η διεύθυνση είναι στατική, παραλείψτε τον ενημερωτή: μία εγγραφή A, μία εγγραφή AAAA αν τρέχετε IPv6, η ίδια προώθηση θύρας.

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

Πριν προχωρήσετε, επιβεβαιώστε τέσσερα πράγματα με σειρά:

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

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