Loka Samba-kunhavaĵo malaperis post kiam OpenVPN puŝis DNS

Samba perdas lokajn kunhavaĵojn en la momento, kiam OpenVPN konektiĝas, kaj la tunelo preskaŭ neniam estas la kaŭzo. La muntado estas en ordo, la NAS funkcias, kaj la solvilo, kiun la tunelo instalis, respondas demandojn pri nomo, kiun ĝi neniam vidis. Samba demandas tiun solvilon frue en sia serĉordo, kredas la respondon kaj konektiĝas al adreso, kie nenio aŭskultas. Ripari la kunhavaĵon signifas ripari la respondon, ne la muntadon.

Kvin kontroloj, en la ordo, kiu forigas la plej multajn eblojn po paŝo.

Kiu respondecas pri la mallonga nomo

Demandu la operaciumon, ne la dosieradministrilon. resolvectl status montras la DNS-servilojn ligitajn al ĉiu ligo kaj markas, kiu ligo estas la defaŭlta vojo, kaj peto pri la mallonga nomo raportas la servilon, kiu respondis. Rulu ĝin unufoje por la NAS-nomo kaj unufoje por nomo, pri kiu vi scias, ke ĝi ekzistas en la oficeja domajno. Se la du respondoj venas de malsamaj serviloj, vi trovis la dividon.

Kontrolu, ĉu la respondo estis nea respondo aŭ adreso. Nea respondo signifas, ke Samba devintus transiri al alia mekanismo, kaj la paneo estas aliloke. Adreso signifas, ke Samba konektiĝis al io reala kaj ricevis nenion.

Kial Samba kredas malĝustan respondon

Samba solvas nomojn per fiksa sinsekvo difinita de name resolve order. En la plej multaj distribuaĵoj la defaŭlto inkluzivas host, kio signifas DNS, kaj ĝi ruliĝas antaŭ la mekanismoj nur por loka reto kiel la dissendo NetBIOS. Do tunelo, kiu puŝas solvilon, ricevas la unuan rifuzon pri ĉiu kunhava nomo, inkluzive de unuetikedaj nomoj, kiuj neniam devintus forlasi la konstruaĵon.

Normale nekonata nomo redonas nean respondon kaj la sekva mekanismo ricevas sian vicon. Iuj solviloj, precipe tiuj de konsumantaj ISP-oj kaj la publikaj, respondas nekonatajn nomojn per serĉpaĝo aŭ reklama adreso anstataŭe. Tiu respondo aspektas kiel sukceso al la solvila biblioteko, do Samba ĉesas serĉi kaj vokas adreson, kiu havas nenion komunan kun via reto.

La rezulto estas kunhavaĵo, kiu malaperas sen eraldialogo. Nenio en tiu sinsekvo estas VPN-enkursiga paneo, kaj tial pingi la NAS ankoraŭ funkcias, dum foliumi al ĝi ne funkcias.

Du riparoj kun malsamaj ampleksoj

La mallarĝa ripeto konservas la puŝitan solvilon kaj ŝanĝas, pri kio Samba rajtas demandi ĝin. Aldonu du liniojn al la Samba-agordo, kiun la demono efektive legas, poste restarigu la servon:

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

Sen host en tiu listo, DNS eliras el la vojo por kunhavaj serĉoj, kaj unuetikedaj nomoj restas sur la loka segmento. Oficejaj nomoj ankoraŭ solviĝas normale por ĉiu alia programo, ĉar tio ŝanĝas nur Samba. La kosto estas, ke Samba tute ne plu povas uzi DNS, do kunhavaĵo adresita per plene kvalifikita oficeja nomo fariĝas problemo.

La larĝa ripeto forigas la kaŭzon: ĉesu puŝi solvilon, kiu respondas nomojn, kiujn ĝi ne posedas, aŭ puŝu disigitan DNS-politikon tiel, ke nur oficejaj sufiksoj atingas la oficejan solvilon. Tio estas la pli bona longtempa respondo en administrata reto, ĉar ĝi protektas ankaŭ la retumilon kaj la pakaĵadministrilon, sed ĝi postulas administran aliron ĉe la servila flanko kaj klienton, kiu obeas la puŝitajn agordojn.

Elektu unu konscie. Ŝanĝo de solvilo ŝanĝas nomosolvadon por ĉiu aplikaĵo samtempe, kio estas ŝanĝregistro, ne redakto por subtena alvoko.

La sufiso povas klarigi ĉion

Se la kliento ankaŭ puŝas serĉan sufikson, mallonga loka nomo estas reverkata en la oficejan domajnon antaŭ ol ĝi estas demandita. Tiam la solvilo tute ne mensogas: ĝi estis demandita justan demandon pri oficeja nomo kaj donis ĝustan respondon. Legu la demanditan nomon en la eligo de la solvilo por distingi tion de la kazo de reklama adreso, ĉar la du paneoj aspektas identaj en la dosieradministrilo.

La solvo ĉi tie estas aŭ uzi la plene kvalifikitan lokan nomon aŭ aldoni regulon de disigita DNS, kiu posedas la lokan sufikson. Neniun el la du necesas tuŝi Samba.

Pruvu tion post rekonekto

Testu tri nomojn en unu sesio: la lokan kunhavaĵon per mallonga nomo, oficejan gastiganton per nomo, kaj ordinaran retejon. Se la unua funkcias kaj la dua rompiĝas, la ripeto movis la paneon anstataŭ forigi ĝin. Se la tria rompiĝas, la ŝanĝo de solvilo iris pli malproksimen ol intencite, kaj ĉiu serĉo nun estas suspektinda.

Poste malkonektu kaj rekonektu la tunelon kaj ripetu ĉiujn tri. Puŝitaj opcioj reaplikiĝas ĉe ĉiu konekto, do ripeto, kiu ekzistis nur dum rulado, povas malaperi sen ŝanĝo de agorda dosiero. Notu la solvilon, kiu posedas ĉiun sufikson, kaj la serĉordon en viglo, kaj notu la daton, ĉar la sekva klienta ĝisdatigo estas la evidenta suspektulo, kiam ĉi tio revenos.

Se la kunhavaĵo ankoraŭ malsukcesas post ĉiuj kvin kontroloj, kaptu la precizan peton kaj la precizan respondon antaŭ ol ŝanĝi ion alian. Tiu paro da linioj distingas solvilan paneon de nomo, kiu vere ne ekzistas, kaj ĝi estas la plej rapida transdona noto, kiun vi povas skribi.