NetBIOS VPN-ზე: სახელი, დატაგრამა და სესია ცალკე სერვისებია
მარშრუტიზატორებზე ნათქვამი სლოგანი ძალიან ფართოა. შეამოწმეთ, თქვენი აპლიკაცია სამი სერვისიდან რომელს იყენებს და სახელებს ბროდკასტით ხსნის თუ სერვერით.
«NetBIOS მარშრუტიზატორებს არ კვეთს» ისე მეორდება, თითქოს ამან დიზაინი გადაწყვიტა. არ გადაუწყვეტია. ბროდკასტით სახელის ძებნა ჩვეულებრივ საკუთარი ბროდკასტული დომენის შიგნით რჩება, მაგრამ NetBIOS-ის სერვისებს შეუძლიათ მიმართული IP ტრაფიკის გამოყენებაც, რომელიც სრულიად კარგად მარშრუტიზდება. სასარგებლო კითხვა არ არის, კვეთს თუ არა NetBIOS მარშრუტიზატორებს; კითხვა არის, თქვენი აპლიკაცია მისი სამი სერვისიდან რომელს იყენებს.
პროგრამული ინტერფეისი და არა ერთი მავთულის პროტოკოლი
RFC 1001 NetBIOS-ს აღწერს როგორც ინტერფეისს, რომლის მიმართაც აპლიკაციები პროგრამირდება, და მის ქვეშ რამდენიმე ტრანსპორტია. მისი TCP/UDP მოდელი ერთმანეთისგან ყოფს სახელების სერვისს, დატაგრამების განაწილებას და სესიის სერვისს, და ის ცალსახად მხარს უჭერს მუშაობას IP ბროდკასტით ან მის გარეშე.
| Service | What it does | Transport dependence |
|---|---|---|
| Name | Registers and resolves names | Broadcast, point-to-point, or a name server |
| Datagram | Connectionless messages, including broadcast | Broadcast domain or directed delivery |
| Session | Connection-oriented exchange | TCP connection to a named endpoint |
სწორედ ეს ცხრილი ხსნის, რატომ ვარდება სლოგანი. სესიის სერვისი ორ დასახელებულ ჰოსტს შორის IP საუბარია; ბროდკასტული დატაგრამა არა. ერთ VPN დიზაინს შეუძლია პირველი დააკმაყოფილოს და მეორე არა, და ტესტი, რომელიც პირველს ამტკიცებს, მეორეზე არაფერს ამბობს.
კვანძის ტიპები წყვეტენ, რას ითხოვს კლიენტი
RFC 1001-ის ბროდკასტული, წერტილიდან წერტილამდე და შერეული კვანძის მოდელები აღწერენ, როგორ ხსნის ჰოსტი სახელებს: ადგილობრივ ქსელს ეკითხება, სახელების სერვერს პირდაპირ ეკითხება, ან ერთს ცდის და შემდეგ მეორეს. მოდელი გავლენას ახდენს იმაზე, რა ტრაფიკი უნდა დაიშვას და არა იმაზე, მუშაობს თუ არა აპლიკაცია საერთოდ.
მართული სახელების სერვერის მოწყობა კლიენტებს წერტილიდან წერტილამდე გზას აძლევს, მაგრამ მხოლოდ იმ კლიენტებს, რომლებიც მის გამოსაყენებლად არიან კონფიგურირებული. სერვერის სადღაც ქსელში განთავსება არ იწვევს იმას, რომ აპლიკაცია მას ჰკითხოს, და ბროდკასტულ რეჟიმში დატოვებული კლიენტი გააგრძელებს ადგილობრივი სეგმენტის კითხვას და დროის ამოწურვამდე მივა. სერვერის მისამართი კლიენტის კონფიგურაციამდე უნდა მივიდეს, იმ მართვის გზით, რომელსაც ეს კლიენტი პატივს სცემს.
ამიტომ დააფიქსირეთ სამი დაკვირვება მოცემული აპლიკაციისთვის: როგორ აქცევს სერვერის სახელს მისამართად, იყენებს თუ არა აღმოჩენა ან შეტყობინებები ბროდკასტს თუ მიმართულ ბოლო წერტილს, და რომელ მისამართსა და ტრანსპორტს იყენებს ფაქტობრივი სესია. ეს დამოუკიდებელი ფაქტებია და თითოეულს თავისი გამოსავალი აქვს. სახელის ერთი წარმატებული ამოხსნა მხოლოდ პირველზეა მტკიცება.
TCP/IP-ზე NetBIOS არ არის NetBEUI
ორივეს ურევენ, რადგან ორივეს მოძველებულს უწოდებენ. TCP/IP-ზე NetBIOS თავის სერვისებს IP პაკეტებში ატარებს, რომლებსაც მარშრუტიზებული გვირაბი უკვე გადააქვს. NetBEUI 2-ე დონის პროტოკოლია, რომლის მარშრუტიზაცია შეუძლებელია, და IP გვირაბი თვითნებურ Ethernet ჩარჩოებს არ გადააქვს მხოლოდ იმიტომ, რომ IP-ს გადააქვს.
IP მარშრუტის დამატება ვერ გადააქცევს არა-IP ჩარჩოს IP აპლიკაციად. თუ აპლიკაცია ნამდვილად 2-ე დონის ქცევაზეა დამოკიდებული, არჩევანია ცალსახად შემოფარგლული 2-ე დონის სერვისი ან აპლიკაციის შეცვლა; არც ერთ მათგანს არ ცვლის რაიმე მარშრუტიზაციის ცვლილება.
აირჩიეთ უმცირესი ცვლილება, რომელიც ამოცანას აკმაყოფილებს
დამტკიცებული DNS სახელითა და ცალსახა UNC ბილიკით მისაწვდომ არსებულ SMB გაზიარებას Ethernet გაფართოება არ სჭირდება. ფაილური სერვისის ამოცანა და დათვალიერების გამოცდილება სხვადასხვა მოთხოვნებია, და მხოლოდ მეორეა დამოკიდებული მეზობლების სიაზე. გაზიარებაზე სახელით მიღწევა ხსნის ამოცანას ბროდკასტული დომენის გვირაბზე გაწელვის გარეშე.
დათვალიერება ის ნაწილია, რომელიც ჩვეულებრივ ფარცხდება, და ის ჩუმად ფარცხდება. მანქანას შეუძლია გაზიარება ბილიკით გახსნას, სანამ ახლომდებარე კომპიუტერების სია ცარიელი რჩება, რადგან სია ბროდკასტული აღმოჩენით ივსება, ბილიკი კი DNS-ს იყენებს. იმის გადაწყვეტა, რომ სია გჭირდებათ, სხვა მოთხოვნაა, ვიდრე იმის გადაწყვეტა, რომ ფაილი გჭირდებათ. ჩაწერეთ, რომელი სთხოვა მომხმარებელს სინამდვილეში, სანამ რამეს დააპროექტებთ.
როცა ძველი აპლიკაცია ნამდვილად მოითხოვს ბროდკასტს ან არა-IP ჩარჩოებს, შეაფასეთ დასახელებული მფლობელის მქონე შემოფარგლული 2-ე დონის სერვისი, ან შეცვალეთ აპლიკაცია. ხიდი აფართოებს საერთო ჩავარდნის დომენსა და პოლიტიკის საზღვარს, და ეს არქიტექტურული გადაწყვეტილებაა და არა NetBIOS-წარწერიანი მოსანიშნი უჯრა. დააფიქსირეთ კონკრეტული ოპერაციები, რომლებიც გვირაბმა უნდა გადაიტანოს, და ადმინისტრატორს შეეძლება მოთხოვნის შეფასება «მთელი Windows ქსელის» გამოცნობის ნაცვლად.