Κοινή χρήση δικτύου container VPN: τι συμβαίνει με το DNS

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

Βήμα 1: Δοκιμάστε από την εφαρμογή, όχι από τον host

Εκτελέστε την αναζήτηση μέσα στο container που έχει το πρόβλημα, όχι στον host και όχι σε πρόγραμμα περιήγησης. docker exec app-container getent hosts db.internal απαντά στο μόνο ερώτημα που έχει σημασία: τι επιστρέφει ο resolver αυτής της διεργασίας.

Αν ο host επιλύει το όνομα και το container όχι, βρήκατε τη βλάβη. Ό,τι ακολουθεί είναι η επιλογή ενός υποστηριζόμενου τρόπου διόρθωσής της.

Βήμα 2: Διαβάστε το υποστηριζόμενο μοντέλο του runtime

Η τεκμηρίωση δικτύου του Docker καταγράφει περιορισμούς στις σημαίες DNS για container που μοιράζονται τη λειτουργία δικτύου άλλου container. Στο Compose network_mode: service:vpn συνδέει την εφαρμογή με τον χώρο ονομάτων του container VPN, και ανά υπηρεσία dns οι ρυθμίσεις δεν συμπεριφέρονται όπως σε μια συνηθισμένη υπηρεσία. Η επίλυση που παίρνετε είναι αυτή που έχει ο κοινόχρηστος χώρος ονομάτων.

Τα δίκτυα γέφυρας που ορίζονται από τον χρήστη χρησιμοποιούν επίσης το ενσωματωμένο DNS του Docker διαφορετικά από την προεπιλεγμένη γέφυρα. Γι’ αυτό μια dns ρήτρα αντιγραμμένη από ένα παράδειγμα γέφυρας που λειτουργεί μπορεί να μην κάνει απολύτως τίποτα σε ένα κοινόχρηστο stack. Ελέγξτε τη διάταξη πριν αντιγράψετε τη ρήτρα.

Μια διεύθυνση loopback αναφέρεται πάντα στο σχετικό δίκτυο. Μέσα σε έναν κοινόχρηστο χώρο ονομάτων, 127.0.0.1 δεν είναι ο resolver του host.

Βήμα 3: Ακολουθήστε το ερώτημα έως τον παραλήπτη του

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

Μια σελίδα ελέγχου IP στο πρόγραμμα περιήγησης δεν μπορεί να σας πει πού πήγαν τα ερωτήματα ονομάτων. Σας λέει πού πήγε μία σύνδεση HTTP.

Βήμα 4: Διορθώστε τις δύο κατηγορίες αστοχίας διαφορετικά

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

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

Βήμα 5: Επαναδοκιμάστε μετά την αναδημιουργία

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

Καταγράψτε τον ιδιοκτήτη του resolver και τον αναμενόμενο χώρο ονομάτων δίπλα στον ορισμό του κοινόχρηστου δικτύου. Το επόμενο άτομο θα χρειαστεί και τα δύο.