El recurs compartit local de Samba va desaparèixer després que OpenVPN impulsés DNS

Samba perd els recursos compartits locals en el moment que OpenVPN es connecta, i el túnel gairebé mai no n’és la causa. El muntatge és correcte, el NAS està actiu, i el resolutor que el túnel ha instal·lat respon preguntes sobre un nom que no ha vist mai. Samba pregunta a aquest resolutor aviat en el seu ordre de cerca, creu la resposta i es connecta a una adreça on no hi ha res escoltant. Arreglar el recurs vol dir arreglar la resposta, no el muntatge.

Cinc comprovacions, en l’ordre que elimina més possibilitats per pas.

Qui respon pel nom curt

Pregunteu al sistema operatiu, no al gestor de fitxers. resolvectl status mostra els servidors DNS enllaçats a cada enllaç i marca quin és la ruta per defecte, i una consulta del nom curt informa del servidor que ha respost. Executeu-lo una vegada per al nom del NAS i una altra per a un nom que sapigueu que existeix al domini de l’oficina. Si les dues respostes venen de servidors diferents, heu trobat la divisió.

Comproveu si la resposta ha estat una resposta negativa o una adreça. Una resposta negativa vol dir que Samba hauria d’haver passat a un altre mecanisme, i la fallada és en un altre lloc. Una adreça vol dir que Samba s’ha connectat a un lloc real i no ha obtingut res.

Per què Samba creu una resposta incorrecta

Samba resol noms mitjançant una seqüència fixa establerta per name resolve order. A la majoria de distribucions el valor per defecte inclou host, que vol dir DNS, i s’executa abans dels mecanismes només de xarxa local com la difusió NetBIOS. Per tant, un túnel que impulsa un resolutor obté el primer rebuig sobre cada nom de recurs, incloent-hi noms d’una sola etiqueta que mai no havien de sortir de l’edifici.

Normalment un nom desconegut retorna una resposta negativa i el mecanisme següent rep el seu torn. Alguns resolutors, sobretot els d’ISP de consum i els públics, responen noms desconeguts amb una pàgina de cerca o una adreça publicitària. Aquesta resposta sembla un èxit per a la biblioteca del resolutor, així que Samba deixa de buscar i marca una adreça que no té res a veure amb la vostra xarxa.

El resultat és un recurs que desapareix sense cap diàleg d’error. Res d’aquesta seqüència no és una fallada d’encaminament VPN, i per això fer ping al NAS encara funciona mentre que navegar-hi no.

Dues reparacions amb abast diferent

La reparació estreta manté el resolutor impulsat i canvia què se li permet preguntar a Samba. Afegiu dues línies a la configuració de Samba que el dimoni llegeix realment i reinicieu el servei:

[global]
   name resolve order = wins lmhosts bcast
   dns proxy = no

Sense host en aquesta llista, DNS queda fora del camí per a les cerques de recursos, i els noms d’una sola etiqueta es queden al segment local. Els noms de l’oficina encara es resolen normalment per a qualsevol altre programa, perquè això només canvia Samba. El cost és que Samba ja no pot usar DNS de cap manera, així que un recurs adreçat amb un nom d’oficina completament qualificat es converteix en un problema.

La reparació àmplia elimina la causa: deixeu d’impulsar un resolutor que respon noms que no posseeix, o impulseu una política de DNS dividit perquè només els sufixos de l’oficina arribin al resolutor de l’oficina. Aquesta és la millor resposta a llarg termini en una xarxa gestionada perquè també protegeix el navegador i el gestor de paquets, però necessita accés administratiu al costat del servidor i un client que obeeixi la configuració impulsada.

Trieu-ne una deliberadament. Un canvi de resolutor altera la resolució de noms per a totes les aplicacions alhora, cosa que és un registre de canvi, no una edició per a una trucada de suport.

El sufix pot explicar-ho tot

Si el client també impulsa un sufix de cerca, un nom local curt es reescriu al domini de l’oficina abans de ser consultat. Llavors el resolutor no menteix gens: se li va fer una pregunta justa sobre un nom d’oficina i va donar una resposta correcta. Llegiu el nom consultat a la sortida del resolutor per distingir-ho del cas de l’adreça publicitària, perquè les dues fallades es veuen idèntiques al gestor de fitxers.

La solució aquí és usar el nom local completament qualificat o afegir una regla de DNS dividit que posseeixi el sufix local. Cap de les dues no requereix tocar Samba.

Demostreu-ho després d’una reconnexió

Proveu tres noms en una sessió: el recurs local pel nom curt, un amfitrió de l’oficina pel nom i un lloc web qualsevol. Si el primer funciona i el segon falla, la reparació ha mogut la fallada en lloc d’eliminar-la. Si falla el tercer, el canvi de resolutor ha anat més enllà del previst i ara tota cerca és sospitosa.

Desconnecteu i torneu a connectar el túnel i repetiu els tres. Les opcions impulsades s’apliquen de nou a cada connexió, així que una reparació que només existia en temps d’execució pot desaparèixer sense que cap fitxer de configuració canviï. Anoteu el resolutor que posseeix cada sufix i l’ordre de cerca vigent, i apunteu la data, perquè la propera actualització del client és el sospitós obvi quan això torni.

Si el recurs encara falla després de les cinc comprovacions, captureu la consulta exacta i la resposta exacta abans de canviar res més. Aquest parell de línies distingeix una fallada del resolutor d’un nom que realment no existeix, i és la nota de traspàs més ràpida que podeu escriure.