Το DNS του OpenVPN μένει πίσω μετά από SIGKILL: ελέγξτε πρώτα τον ιδιοκτήτη

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

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

Αποφασίστε τι είδους έξοδος συνέβη

Στην έκδοση Community του OpenVPN, τόσο το SIGINT όσο και το SIGTERM είναι αιτήματα ομαλής εξόδου. Το SIGKILL δεν μπορεί να συλληφθεί: δεν μπορεί ούτε να μπλοκαριστεί ούτε να χειριστεί, άρα καμία ρουτίνα τερματισμού δεν παίρνει την ευκαιρία να εκτελεστεί. Ένα κανονικό Ctrl+C σε τερματικό πρώτου πλάνου παράγει SIGINT, ενώ ένας επόπτης που σταματά να περιμένει συνήθως κλιμακώνει σε SIGKILL. Η διαφορά μετράει γιατί μόνο η δεύτερη περίπτωση εγγυάται ότι τα άγκιστρα παραλείφθηκαν.

Η εκτέλεση μέσα σε screen ή tmux δεν αλλάζει ποιο σήμα στέλνει το Ctrl+C. Ελέγξτε τι έλαβε πραγματικά η διεργασία, όχι τι κάνει συνήθως το τερματικό.

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

Αποφασίστε ποιος κατέχει τον resolver

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

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

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

Τι μπορεί και τι δεν μπορεί το άγκιστρο down

Το σενάριο down εκτελείται μία φορά αφού κλείσει η συσκευή TUN/TAP. Η προσθήκη του down-pre αντιστρέφει αυτή τη σειρά και εκτελεί το σενάριο όσο η συσκευή υπάρχει ακόμη, κάτι που απαιτούν βοηθοί που χρειάζονται τον ζωντανό σύνδεσμο.

Καμία από τις δύο οδηγίες δεν κάνει ένα άγκιστρο να εκτελεστεί μετά το SIGKILL. Τα προνόμια επίσης δεν αποκαθίστανται από το down-pre: αν ο δαίμονας πέσει σε user ή group ή μπει σε chroot, το άγκιστρο εκτελείται με όποια πρόσβαση του αφήσει αυτό. Ένα άγκιστρο που κλήθηκε μπορεί παρόλα αυτά να αποτύχει να ενημερώσει τον resolver. Η αναφορά του OpenVPN καλύπτει τα σήματα και τον κύκλο ζωής της επανάκλησης.

Ελέγξτε το σφάλμα του ίδιου του άγκιστρου δίπλα στην κατάσταση εξόδου της διεργασίας. Ο απόντας καθαρισμός και ο αποτυχημένος καθαρισμός φαίνονται ίδιοι στον resolver και διαφορετικοί στα αρχεία καταγραφής.

Ελέγξτε την κατάσταση που πραγματικά μένει

Σε σύστημα που χρησιμοποιεί systemd-resolved, το resolvectl status δείχνει ποιος σύνδεσμος εξακολουθεί να μεταφέρει τους διακομιστές DNS του VPN ή τα domains δρομολόγησης. Αυτός ο σύνδεσμος μπορεί να ανήκει σε σύνδεση που έφυγε, ή σε άλλη σήραγγα που είναι ακόμη ενεργή.

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

Ανακτήστε χωρίς να κλέψετε άλλον σύνδεσμο

Όταν οι ρυθμίσεις ανά ζεύξη είναι δικές σας να τις διαχειρίζεστε, το resolvectl revert παίρνει το όνομα του συνδέσμου και καθαρίζει τη διαμόρφωση DNS χρόνου εκτέλεσης για εκείνη τη διεπαφή. Είναι ενέργεια χρόνου εκτέλεσης και όχι επεξεργασία προφίλ, άρα η μόνιμη διαμόρφωση σύνδεσης μένει ανέγγιχτη. Ονομάστε λάθος σύνδεσμο και καθαρίζετε το DNS μιας σήραγγας που δουλεύει, γι' αυτό το όνομα προέρχεται από την έξοδο κατάστασης.

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