Η προσάρτηση CIFS αποτυγχάνει μέσω VPN λόγω της σειράς στο nsswitch

Η σήραγγα είναι ενεργή. Ο διακομιστής αρχείων απαντά σε ping με διεύθυνση. Έπειτα το mount.cifs με το όνομα κεντρικού υπολογιστή κάθεται εκεί για λίγο και αναφέρει ότι ο κόμβος δεν είναι προσβάσιμος, κι εσείς αρχίζετε να ξαναχτίζετε ένα προφίλ VPN που ποτέ δεν ήταν το πρόβλημα. Στο Linux το όνομα το επιλύει η glibc πριν υπάρξει οποιοδήποτε πακέτο SMB, και η σειρά σε αυτόν τον resolver μπορεί να τερματίσει την αναζήτηση πριν ερωτηθεί ποτέ το DNS. Αυτή είναι η διαδρομή που ακολουθώ, ξεκινώντας από την εντολή που απέτυχε και όχι από τον πελάτη.

Διαβάστε την αποτυχία στο σωστό σημείο

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

getent hosts fileserver.corp.example
host fileserver.corp.example 10.61.0.1
getent -s dns hosts fileserver.corp.example

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

Η γραμμή hosts είναι μια ακολουθία που σταματά νωρίς

Ο resolver της glibc διαβάζει το /etc/nsswitch.conf και διατρέχει την καταχώριση hosts: από αριστερά προς τα δεξιά. Πολλές διανομές παραδίδουν μια γραμμή όπου η αναζήτηση multicast έρχεται πρώτη με μια ενέργεια πρώιμης επιστροφής συνδεδεμένη. Η ενέργεια δεν είναι διακόσμηση: όταν το mDNS απαντήσει “not found”, το [NOTFOUND=return] τερματίζει ολόκληρη την αναζήτηση, οπότε το εταιρικό όνομα δεν αποστέλλεται ποτέ στον resolver που επέβαλε το VPN. Τίποτα δεν το καταγράφει, γιατί δεν στάλθηκε ποτέ ερώτημα για να απορρίψει ο resolver. Γι’ αυτό η προσάρτηση μοιάζει να κολλάει και μετά αναφέρει μη προσβάσιμο κόμβο.

cat /etc/nsswitch.conf | grep '^hosts:'
# illustrative repair: dns before the early-return action
hosts: files myhostname mdns4_minimal dns [NOTFOUND=return] wins mdns4

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

Ένας resolver δεν είναι τομέας αναζήτησης

Η επίλυση χρειάζεται επίσης να δοκιμαστεί το όνομα. Ένα μη πλήρες όνομα όπως το fileserver γίνεται fileserver.corp.example μόνο όταν ένας τομέας αναζήτησης είναι συνδεδεμένος με τη διεπαφή που μεταφέρει το ερώτημα. Ένα VPN που επιβάλλει διακομιστή DNS χωρίς λίστα αναζήτησης παράγει έναν πολύ συγκεκριμένο διαχωρισμό: το πλήρες όνομα επιλύεται και κάθε σύντομο όνομα αποτυγχάνει.

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

resolvectl status
resolvectl query fileserver.corp.example
resolvectl dns
resolvectl domain

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

Τα container κουβαλούν το δικό τους αντίγραφο της απάντησης

Ένα container χτισμένο από γενική εικόνα συνήθως φέρνει ένα σταθερό resolv.conf. Οι αλλαγές resolver στον κόμβο δεν φτάνουν σε αυτό, ούτε ο τομέας αναζήτησης, οπότε μια εργασία build που προσαρτά κοινόχρηστο μέσω της σήραγγας αποτυγχάνει ενώ η ίδια εντολή έξω από το container δουλεύει. Δώστε στο container δικές του ρυθμίσεις DNS και αναζήτησης στο αρχείο compose ή στα ορίσματα εκτέλεσης, όχι μόνο στο προφίλ του κόμβου.

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

Μόνο τότε κοιτάξτε το κοινόχρηστο και το φίλτρο

Όταν το όνομα επιλυθεί, οι υπόλοιπες αποτυχίες είναι συνηθισμένες δικτυακές. Το SMB χρειάζεται TCP 445 προς τον διακομιστή, και η περιήγηση σε λίστα ομάδας εργασίας εξαρτάται από υπηρεσίες ονομάτων που η σήραγγα μάλλον δεν προωθεί. Κάντε σύνδεση με όνομα κόμβου αντί να περιμένετε να γεμίσει μια λίστα, και αφήστε τον πελάτη να σας πει σε ποιο στάδιο έφτασε. Μια απορριφθείσα σύνδεση και ένα σιωπηλό timeout αξίζει επίσης να ξεχωρίζονται, γιατί το πρώτο συνήθως σημαίνει ότι κάτι απάντησε και το δεύτερο ότι δεν απάντησε τίποτα.

getent hosts fileserver.corp.example
nc -vz fileserver.corp.example 445
mount -t cifs //fileserver.corp.example/share /mnt/share \
  -o vers=3.1.1,username=svc_mount,uid=1000

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

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