OpenVPN DNS'i ittikten sonra yerel Samba paylaşımı kayboldu

Samba yerel paylaşımları tam o anda kaybeder: OpenVPN bağlandığında, ve tünel neredeyse hiçbir zaman nedeni değildir. Bağlama düzgün, NAS açık, ve tünelin kurduğu çözümleyici hiç görmediği bir ad hakkındaki soruları yanıtlıyor. Samba bu çözümleyiciye arama sırasının başında sorar, yanıta inanır ve hiçbir şeyin dinlemediği bir adrese bağlanır. Paylaşımı düzeltmek, bağlamayı değil yanıtı düzeltmek demektir.

Her adımda en çok olasılığı eleyen sırayla beş kontrol.

Kısa adı kim yanıtlıyor

Dosya yöneticisine değil, işletim sistemine sorun. resolvectl status her bağlantıya bağlı DNS sunucularını yazdırır ve hangi bağlantının varsayılan yol olduğunu işaretler, kısa ad sorgusu ise yanıt veren sunucuyu bildirir. NAS adı için bir kez, ofis alan adında olduğunu bildiğiniz bir ad için bir kez daha çalıştırın. İki yanıt farklı sunuculardan geliyorsa bölünmeyi bulmuşsunuz.

Yanıtın olumsuz bir yanıt mı yoksa adres mi olduğunu kontrol edin. Olumsuz yanıt, Samba'nın başka bir mekanizmaya geçmesi gerektiği anlamına gelir ve arıza başka yerdedir. Adres ise Samba'nın gerçek bir yere bağlandığı ve hiçbir şey alamadığı anlamına gelir.

Samba neden yanlış bir yanıta inanır

Samba adları name resolve order tarafından belirlenen sabit bir sırayla çözer. Çoğu dağıtımda varsayılan değer host içerir, yani DNS, ve yalnızca yerel ağa yönelik NetBIOS yayını gibi mekanizmalardan önce çalışır. Bu yüzden çözümleyiciyi iten bir tünel her paylaşım adı için ilk ret hakkını alır, binadan hiç çıkmaması gereken tek etiketli adlar dahil.

Genellikle bilinmeyen bir ad olumsuz yanıt döndürür ve sıradaki mekanizma sırayı alır. Bazı çözümleyiciler, özellikle tüketici ISS'lerinin ve genel olanlar, bilinmeyen adları bunun yerine bir arama sayfası veya reklam adresiyle yanıtlar. Bu yanıt çözümleyici kütüphanesi için başarı gibi görünür, bu yüzden Samba aramayı bırakır ve ağınızla hiçbir ilgisi olmayan bir adresi çevirir.

Sonuç, hata iletişim kutusu olmadan kaybolan bir paylaşımdır. Bu sırada hiçbir şey VPN yönlendirme arızası değildir, bu yüzden NAS'a ping hâlâ çalışırken ona göz atmak çalışmaz.

Farklı kapsamlara sahip iki onarım

Dar onarım itilen çözümleyiciyi korur ve Samba'nın ona neler sorabileceğini değiştirir. Daemonun gerçekten okuduğu Samba yapılandırmasına iki satır ekleyin, ardından hizmeti yeniden başlatın:

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

Bu listede host yoksa DNS paylaşım aramalarının yolundan çıkar ve tek etiketli adlar yerel segmentte kalır. Ofis adları diğer her program için normal biçimde çözülmeye devam eder, çünkü bu yalnızca Samba'yı değiştirir. Bedeli, Samba'nın artık DNS'i hiç kullanamamasıdır, bu yüzden tam nitelikli bir ofis adıyla adreslenen paylaşım sorun hâline gelir.

Geniş onarım nedeni ortadan kaldırır: sahibi olmadığı adlara yanıt veren bir çözümleyiciyi itmeyi bırakın veya yalnızca ofis son eklerinin ofis çözümleyicisine ulaşması için bölünmüş DNS ilkesi itin. Yönetilen bir ağda bu daha iyi uzun vadeli yanıttır çünkü tarayıcıyı ve paket yöneticisini de korur, ancak sunucu tarafında yönetici erişimi ve itilen ayarlara uyan bir istemci gerektirir.

Birini bilerek seçin. Çözümleyici değişikliği ad çözümlemesini tüm uygulamalar için bir anda değiştirir, bu bir değişiklik kaydıdır, destek çağrısı için yapılan bir düzenleme değildir.

Son ek her şeyi açıklayabilir

İstemci bir arama son eki de itiyorsa, kısa yerel ad sorgulanmadan önce ofis alan adına yeniden yazılır. O zaman çözümleyici hiç yalan söylemiyor: ona ofis adı hakkında adil bir soru soruldu ve doğru yanıt verdi. Bunu reklam adresi durumundan ayırmak için çözümleyici çıktısındaki sorgulanan adı okuyun, çünkü iki arıza dosya yöneticisinde aynı görünür.

Buradaki çözüm ya tam nitelikli yerel adı kullanmak ya da yerel son ekin sahibi olan bölünmüş DNS kuralı eklemektir. Hiçbiri Samba'ya dokunmayı gerektirmez.

Yeniden bağlandıktan sonra kanıtlayın

Tek oturumda üç adı test edin: kısa adla yerel paylaşım, adla bir ofis ana bilgisayarı ve sıradan bir web sitesi. Birincisi çalışıp ikincisi bozulursa, onarım arızayı ortadan kaldırmak yerine taşımıştır. Üçüncüsü bozulursa, çözümleyici değişikliği amaçlananın ötesine geçti ve artık her arama şüphelidir.

Sonra tüneli ayırıp yeniden bağlayın ve üçünü de yineleyin. İtilen seçenekler her bağlantıda yeniden uygulanır, bu yüzden yalnızca çalışma zamanında var olan bir onarım, yapılandırma dosyası değişmeden kaybolabilir. Her son ekin sahibi olan çözümleyiciyi ve yürürlükteki arama sırasını kaydedin ve tarihi not edin, çünkü bu geri döndüğünde bir sonraki istemci güncellemesi bariz şüphelidir.

Paylaşım beş kontrolün hepsinden sonra hâlâ başarısız olursa, başka bir şeyi değiştirmeden önce tam sorguyu ve tam yanıtı yakalayın. Bu satır çifti bir çözümleyici arızasını gerçekten var olmayan bir addan ayırır ve yazabileceğiniz en hızlı devir notudur.