Lokal Samba-deling forsvandt, efter at OpenVPN skubbede DNS

Samba mister lokale delinger i det øjeblik, OpenVPN der oprettes forbindelse, og tunnelen er næsten aldrig årsagen. Mountet er i orden, NAS'et kører, og den resolver, som tunnelen har installeret, svarer på spørgsmål om et navn, den aldrig har set. Samba spørger den resolver tidligt i sin opslagsrækkefølge, tror på svaret og opretter forbindelse til en adresse, hvor der ikke lyttes. At rette delingen betyder at rette svaret, ikke mountet.

Fem kontroller i den rækkefølge, der udelukker flest muligheder pr. skridt.

Hvem svarer på det korte navn

Spørg operativsystemet, ikke filhåndteringen. resolvectl status viser de DNS-servere, der er knyttet til hver forbindelse, og markerer hvilken forbindelse der er standardruten, og en forespørgsel på det korte navn rapporterer den server, der svarede. Kør den én gang for NAS-navnet og én gang for et navn, du ved findes i kontordomænet. Hvis de to svar kommer fra forskellige servere, har du fundet opdelingen.

Kontroller, om svaret var et negativt svar eller en adresse. Et negativt svar betyder, at Samba skulle være gået videre til en anden mekanisme, og fejlen er et andet sted. En adresse betyder, at Samba oprettede forbindelse til et rigtigt sted og ikke fik noget igen.

Hvorfor Samba tror på et forkert svar

Samba opløser navne gennem en fast sekvens, der sættes af name resolve order. På de fleste distributioner indeholder standarden host, hvilket betyder DNS, og den kører før mekanismerne kun for LAN som NetBIOS-broadcast. En tunnel, der skubber en resolver, får derfor første afvisning på hvert delingsnavn, også ét-etikette-navne, der aldrig var ment at forlade bygningen.

Normalt returnerer et ukendt navn et negativt svar, og den næste mekanisme får sin tur. Nogle resolvere, især forbruger-ISP'er og offentlige, svarer på ukendte navne med en søgeside eller en reklameadresse i stedet. Det svar ser ud som succes for resolverbiblioteket, så Samba holder op med at lede og ringer til en adresse, der intet har med dit netværk at gøre.

Resultatet er en deling, der forsvinder uden en fejldialog. Intet i den sekvens er en VPN-routingfejl, og derfor virker det stadig at ping'e NAS'et, mens det ikke virker at browse til det.

To reparationer med forskellig rækkevidde

Den snævre reparation beholder den skubbede resolver og ændrer, hvad Samba må spørge den om. Tilføj to linjer til den Samba-konfiguration, som dæmonen faktisk læser, og genstart derefter tjenesten:

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

Uden host på den liste er DNS ude af vejen for delingsopslag, og ét-etikette-navne bliver på det lokale segment. Kontornavne opløses stadig normalt for alle andre programmer, fordi dette kun ændrer Samba. Prisen er, at Samba slet ikke kan bruge DNS mere, så en deling, der adresseres med et fuldt kvalificeret kontornavn, bliver et problem.

Den brede reparation fjerner årsagen: hold op med at skubbe en resolver, der svarer på navne, den ikke ejer, eller skub en split-DNS-politik, så kun kontorsuffikser når kontorets resolver. Det er det bedre langsigtede svar på et administreret netværk, fordi det også beskytter browseren og pakkehåndteringen, men det kræver administrativ adgang på serversiden og en klient, der adlyder de skubbede indstillinger.

Vælg én med vilje. En resolverændring ændrer navneopløsningen for hver applikation på én gang, hvilket er en ændringsrecord, ikke en redigering til et supportopkald.

Suffikset kan forklare alt

Hvis klienten også skubber et søgesuffiks, omskrives et kort lokalt navn til kontordomænet, før det slås op. Så lyver resolveren slet ikke: den blev stillet et rimeligt spørgsmål om et kontornavn og gav et korrekt svar. Læs det forespurgte navn i resolverens output for at skelne dette fra reklameadresse-tilfældet, fordi de to fejl ser identiske ud i filhåndteringen.

Rettelsen her er enten at bruge det fuldt kvalificerede lokale navn eller at tilføje en split-DNS-regel, der ejer det lokale suffiks. Ingen af dem kræver at røre Samba.

Bevis det efter en genopkobling

Test tre navne i én session: den lokale deling ved kort navn, en kontorvært ved navn og et almindeligt websted. Hvis det første virker, og det andet knækker, har reparationen flyttet fejlen i stedet for at fjerne den. Hvis det tredje knækker, er resolverændringen gået længere end tilsigtet, og hvert opslag er nu mistænkeligt.

Afbryd og genopkobl derefter tunnelen, og gentag alle tre. Skubbede indstillinger anvendes igen ved hver forbindelse, så en rettelse, der kun fandtes i køretiden, kan forsvinde, uden at en konfigurationsfil ændres. Notér den resolver, der ejer hvert suffiks, og den opslagsrækkefølge, der gælder, og skriv datoen, fordi den næste klientopdatering er den oplagte mistænkte, når dette vender tilbage.

Hvis delingen stadig fejler efter alle fem kontroller, skal du fange den præcise forespørgsel og det præcise svar, før du ændrer noget andet. Det par linjer skelner en resolverfejl fra et navn, der virkelig ikke findes, og det er den hurtigste overdragelsesnote, du kan skrive.