SMB paylaşımı yalnızca VPN üzerinden başarısız oluyor: imzalama mı, alt ağ çakışması mı?

LAN'da çalışan bir paylaşım yalnızca tünel üzerinden başarısız olabilir. Bir imzalama reddini, çakışan bir alt ağı ve eski bir SMB oturumunu ayırın.

Ofiste çalışan ve evde zaman aşımına uğrayan eşlenmiş bir sürücü tek başına neredeyse hiçbir yararlı bilgi vermez. Tünel açıkça paket taşıyor, yoksa sunucuya hiçbir şey ulaşmazdı. Başarısız olan üç katmandan biri: ad yanlış adrese çözümlendi, istemci oturumu imzalamayı reddetti veya eski bir oturum onu taşıyan bağlantıdan daha uzun yaşadı. Her birinin farklı bir onarımı var ve üçünden ikisi istemci tarafında.

Üç arıza aynı hatayı taşır

Sürücü harfi hangi katmanın kırıldığını söylemez ve hata metni genellikle üçüne de uyacak kadar geneldir. Onları iki hızlı soruyla ayırın: sunucu IP adresinden yanıt veriyor mu ve 445 numaralı bağlantı noktası bir bağlantı kabul ediyor mu?

Bu yanıtlar tahmin yerine bir karar tablosu üretir. IP çalışıyor ve ad çalışmıyorsa bu ad çözümlemesine işaret eder. İkisi de çalışıyor ve oturum açma reddediliyorsa bu imzalamaya işaret eder. İkisi de çalışıyor ve bir dosya okuma tünel kesintisinden sonra takılıyorsa bu eski bir oturuma işaret eder.

SymptomLayer to inspect
IP works, hostname times outDNS or subnet overlap
TCP 445 opens, logon refusedSMB signing policy
Hangs after reconnectSession state and timers

Onları bu sırayla ele alın, çünkü yanlış ana makineye çözümlenen bir ad sonraki her testi anlamsız kılar.

Paylaşıma dokunmadan önce adı çözümleyin

Sunucu kendi adresinden yanıt veriyor ve paylaşım adı zaman aşımına uğruyorsa tünel işini yapıyor ve istemci yanlış yere bakıyor. Uzak erişimde bunun çoğunu iki neden açıklar.

Birincisi adres çakışması. Ofis 192.168.70.0/24 kullanırken ev yönlendiricisi aynı aralığı dağıtıyorsa 192.168.70.20'ye çözümlenen bir ana makine adı tünelin arkasındaki sunucu yerine yerel bir cihazı gösterebilir. Windows isteği o zaman yerel olarak gönderebilir, rotayı reddedebilir veya o adrese sahip olan bir yazıcıya çözümleyebilir. Onarım, bir tarafı yeniden numaralandırmaktır, başka bir rota eklemek değil.

İkincisi DNS kapsamı. İç DNS sunucusu olmayan veya tünel üzerinden erişilemeyen bir DNS sunucusu kullanan bir VPN bağdaştırıcısı, kısa adları genel bir çözümleyiciye bırakır. Bağdaştırıcının DNS girdilerini okuyun ve paylaşıma dokunmadan önce iç adı doğrudan sorgulayın:

> ipconfig /all | findstr /i "DNS Servers"
> nslookup files.corp.internal
Server: 10.90.0.2
Address: 10.90.0.2
Name: files.corp.internal
Address: 10.90.0.15

Bu sorgu beklenen adresi döndürürse ad çözümlemesi netleşmiştir ve sorun yığında daha yukarıdadır.

İmzalama gereksinimini iki uçta da okuyun

Her oturum açmayı reddeden erişilebilir bir sunucu, ağ arızası değil ilke uyuşmazlığı işaretidir. Windows istemcide SMB imzalamayı zorunlu kılabilir ve imzalamayan bir sunucu veya NAS, tünel ne kadar sağlıklı olursa olsun oturumu tamamlayamaz.

İstemci ayarını ilke düzenleyicisinde aramadan okuyabilirsiniz:

> Get-SmbClientConfiguration | Select-Object RequireSecuritySignature
RequireSecuritySignature
-------------------------
True
> Get-SmbConnection

Sunucu tarafındaki karşılık gelen değer sunucunun SMB yapılandırmasındadır ve ikisi uyuşmalıdır. Bildirilen bir olayda istemcide gereksinim yerel ilkeyle açıktı, sunucu ise hiç imzalamıyordu; kapatmak ve gpupdate /force çalıştırmak paylaşımı hemen geri getirdi. Bu, nedeni doğrulamak için bir tanılama adımıdır, kalıcı bir düzeltme değil.

Sunucunun desteklediği yerlerde imzalamayı iki uçta da açmayı tercih edin. Bir paylaşımı çalıştırmak için güvenlik ayarını değiştirmek, önceki değeri ve gerekçesiyle kaydedilmelidir; böylece kimse bir sonraki denetimde yeniden keşfetmek zorunda kalmaz.

Zamanlayıcıları ayarlamadan önce eski oturumu temizleyin

Yalnızca VPN düştükten ve yeniden bağlandıktan sonra takılan bir paylaşım, genellikle sunucunun çoktan attığı bir oturumu tutuyor demektir. Sunucu boşta SMB oturumlarını LanmanServer\Parameters altındaki Autodisconnect zamanlayıcısıyla kapatır, bu varsayılan olarak 15 dakikadır, istemcinin ise LanmanWorkstation\Parameters altında kendi SessTimeout değeri vardır. Bu değerlerden daha uzun bir kesinti her iki ucu oturum hakkında farklı bir fikirle bırakır.

Sonuç bir anlam taşısın diye sabit bir sırayla yeniden üretin: tüneli bağlayın, paylaşımı açın, tüneli iki dakika kesin, geri getirin ve ardından bir dosya okumayı deneyin. Bağlama kendi kendine düzelirse zamanlayıcılara dokunmayın. Yeniden bağlamadan takılıyorsa, tünel ayaktayken paylaşımı yeniden bağlayın, oluşmadan önce bağlamak yerine, ve bağlama yardımcısının yeniden deneyip denemediğini kontrol edin.

Zaman aşımlarını yükseltmek kararsız bir bağlantı için makul bir son adımdır, ama semptomu tedavi eder. Sunucunun unuttuğu bir oturumu daha uzun bekleyen istemci yine bekler.

Bağlama üzerinden bir dosya okuyup tüneli bir kez daha kesip geri getirerek bitirin. Bu kabul testi üç katmanı birden kapsar ve kullanıcının gerçekte yaptığıyla eşleşen tek testtir.

İlgili makaleler