SMB გაზიარება მხოლოდ VPN-ით არ მუშაობს: ხელმოწერა თუ ქვექსელის კონფლიქტი?
გაზიარება, რომელიც LAN-ში მუშაობს, შეიძლება მხოლოდ გვირაბის გავლით ჩავარდეს. გამოყავით ხელმოწერის უარი, გადაფარული ქვექსელი და მოძველებული SMB სესია.
მიბმული დისკი, რომელიც ოფისში მუშაობს და სახლში დროის ამოწურვით სრულდება, თავისთავად თითქმის არანაირ სასარგებლო ინფორმაციას არ გაძლევთ. გვირაბი აშკარად გადასცემს პაკეტებს, თორემ სერვერამდე ვერაფერი მივიდოდა. ჩავარდა სამი შრიდან ერთი: სახელი არასწორ მისამართზე გადაწყდა, კლიენტმა სესიის ხელმოწერაზე უარი თქვა, ან ძველი სესია გადაურჩა იმ კავშირს, რომელიც ატარებდა. თითოეულს განსხვავებული შეკეთება აქვს და სამიდან ორი კლიენტის მხარესაა.
სამი ხარვეზი ერთსა და იმავე შეცდომას ატარებს
დისკის ასო არ გეუბნებათ, რომელი შრე გატყდა, და შეცდომის ტექსტი ჩვეულებრივ საკმარისად ზოგადია სამივესთვის. გამოყავით ისინი ორი სწრაფი კითხვით: პასუხობს სერვერი თავის IP მისამართზე და იღებს 445 პორტი კავშირს?
ეს პასუხები იძლევა გადაწყვეტილების ცხრილს ვარაუდის ნაცვლად. თუ IP მუშაობს და სახელი არა, ეს სახელების გადაწყვეტაზე მიუთითებს. თუ ორივე მუშაობს და შესვლა უარყოფილია, ეს ხელმოწერაზე მიუთითებს. თუ ორივე მუშაობს და ფაილის წაკითხვა გვირაბის შეწყვეტის შემდეგ იკიდება, ეს მოძველებულ სესიაზე მიუთითებს.
| Symptom | Layer to inspect |
|---|---|
| IP works, hostname times out | DNS or subnet overlap |
| TCP 445 opens, logon refused | SMB signing policy |
| Hangs after reconnect | Session state and timers |
გაიარეთ ისინი ამ თანმიმდევრობით, რადგან არასწორ ჰოსტზე გადაწყვეტილი სახელი ყოველ მომდევნო ტესტს უაზროს ხდის.
გადაწყვიტეთ სახელი, სანამ გაზიარებას შეეხებით
თუ სერვერი პასუხობს თავის მისამართზე, ხოლო გაზიარების სახელი დროის ამოწურვით სრულდება, გვირაბი თავის საქმეს აკეთებს და კლიენტი არასწორ ადგილს ეძებს. დისტანციური წვდომისას ამის უმეტეს ნაწილს ორი მიზეზი ხსნის.
პირველი მისამართების გადაფარვაა. როცა ოფისი იყენებს 192.168.70.0/24-ს და სახლის როუტერი იმავე დიაპაზონს ანაწილებს, ჰოსტის სახელი, რომელიც 192.168.70.20-ზე გადაწყდება, შეიძლება გვირაბის უკან მდგარი სერვერის ნაცვლად ლოკალურ მოწყობილობაზე მიუთითებდეს. Windows-მა მაშინ შეიძლება მოთხოვნა ლოკალურად გაგზავნოს, მარშრუტი უარყოს ან იმ პრინტერზე გადაწყვიტოს, რომელსაც შემთხვევით ეს მისამართი აქვს. შეკეთება ერთი მხარის გადანომრვაა და არა კიდევ ერთი მარშრუტის დამატება.
მეორე DNS-ის არეა. VPN ადაპტერი შიდა DNS სერვერის გარეშე, ან ისეთით, რომელიც გვირაბის გავლით მიუწვდომელია, მოკლე სახელებს საჯარო resolver-ზე ტოვებს. წაიკითხეთ ადაპტერის DNS ჩანაწერები და უშუალოდ ჰკითხეთ შიდა სახელს, სანამ გაზიარებას შეეხებით:
> 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თუ ეს მოთხოვნა მოსალოდნელ მისამართს დააბრუნებს, სახელების გადაწყვეტა გარკვეულია და პრობლემა სტეკში უფრო მაღლაა.
წაიკითხეთ ხელმოწერის მოთხოვნა ორივე მხარეს
ხელმისაწვდომი სერვერი, რომელიც ყველა შესვლას უარობს, პოლიტიკის შეუთანხმებლობის ნიშანია და არა ქსელური ხარვეზის. Windows-ს შეუძლია კლიენტზე SMB ხელმოწერა მოითხოვოს, ხოლო სერვერი ან NAS, რომელიც არ ხელს აწერს, ვერ დაასრულებს სესიას, რაც არ უნდა ჯანსაღი იყოს გვირაბი.
კლიენტის პარამეტრს პოლიტიკის რედაქტორში ძებნის გარეშე წაიკითხავთ:
> Get-SmbClientConfiguration | Select-Object RequireSecuritySignature
RequireSecuritySignature
-------------------------
True
> Get-SmbConnectionსერვერის მხარეს შესაბამისი მნიშვნელობა სერვერის SMB კონფიგურაციაშია და ორივე უნდა ემთხვეოდეს. ერთ მოხსენებულ შემთხვევაში კლიენტზე მოთხოვნა ლოკალური პოლიტიკით იყო ჩართული, მაშინ როცა სერვერი საერთოდ არ ხელს აწერდა; გამორთვამ და gpupdate /force-ის გაშვებამ გაზიარება მაშინვე აღადგინა. ეს დიაგნოსტიკური ნაბიჯია მიზეზის დასადასტურებლად და არა მუდმივი გამოსწორება.
უპირატესობა მიეცით ხელმოწერის ჩართვას ორივე მხარეს, სადაც სერვერი ამას მხარს უჭერს. უსაფრთხოების პარამეტრის შეცვლა გაზიარების მუშაობისთვის უნდა ჩაიწეროს წინა მნიშვნელობითა და მიზეზით, რომ არავის მოუწიოს მისი ხელახლა აღმოჩენა შემდეგ აუდიტზე.
გაასუფთავეთ მოძველებული სესია, სანამ ტაიმერებს დაარეგულირებთ
გაზიარება, რომელიც მხოლოდ VPN-ის ჩავარდნისა და ხელახალი დაკავშირების შემდეგ იკიდება, ჩვეულებრივ ინახავს სესიას, რომელიც სერვერმა უკვე გადააგდო. სერვერი უმოქმედო SMB სესიებს ხურავს Autodisconnect ტაიმერით LanmanServer\Parameters-ში, რომელიც ნაგულისხმევად 15 წუთია, მაშინ როცა კლიენტს თავისი SessTimeout აქვს LanmanWorkstation\Parameters-ში. ამ მნიშვნელობებზე ხანგრძლივი შეწყვეტა ორივე მხარეს სესიის შესახებ განსხვავებულ წარმოდგენას უტოვებს.
გაამეორეთ ის ფიქსირებული თანმიმდევრობით, რომ შედეგმა რამე ნიშნავდეს: შეაერთეთ გვირაბი, გახსენით გაზიარება, ორი წუთით შეწყვიტეთ გვირაბი, აღადგინეთ ის და შემდეგ სცადეთ ფაილის წაკითხვა. თუ მიმაგრება თავისით აღდგება, ტაიმერებს ნუ შეეხებით. თუ იკიდება ხელახალ მიმაგრებამდე, ხელახლა შეაერთეთ გაზიარება მას შემდეგ, რაც გვირაბი დადგა იმის ნაცვლად, რომ ის არსებობამდე მიამაგროთ, და შეამოწმეთ, ხომ არ ცდილობს მიმაგრების დამხმარე ხელახლა.
დროის ამოწურვების გაზრდა გონივრული ბოლო ნაბიჯია არასტაბილური კავშირისთვის, მაგრამ სიმპტომს მკურნალობს. კლიენტი, რომელიც უფრო დიდხანს ელოდება სესიას, რომელიც სერვერმა დაივიწყა, მაინც ელოდება.
დაასრულეთ მიმაგრების გავლით ერთი ფაილის წაკითხვით და შემდეგ კიდევ ერთხელ გვირაბის შეწყვეტა-აღდგენით. ეს მიღების ტესტი ერთდროულად ფარავს სამივე შრეს და ერთადერთი ტესტია, რომელიც ემთხვევა იმას, რასაც მომხმარებელი რეალურად აკეთებს.