RRAS DHCP: ახალი მისამართი თუ მხოლოდ კონფიგურაციის პარამეტრები?

DHCPACK-ის წაკითხვა ჩანაწერში, როგორც მტკიცებულება იმისა, რომ VPN კლიენტმა მისამართი DHCP-ისგან მიიღო, შეცდომაა. ჩვეულებრივ ის მხოლოდ იმას ამტკიცებს, რომ რომელიმე DHCP შეტყობინებას უპასუხეს. Windows RRAS-ს შეუძლია სესიის მისამართები საკუთარი სტატიკური აუზიდან გასცეს, მაშინ როცა DHCP კვლავ პარამეტრებს აწვდის დაკავშირებულ კლიენტს. მოთხოვნის ტიპი გეტყვით, ორი სამუშაოდან რომელი მიმდინარეობდა.

ორი სამუშაო, რომლებიც ერთ შეტყობინების ტიპს იზიარებენ

DHCP ორ განსხვავებულ რამეს აკეთებს და ისინი შეტყობინების ტიპებს იზიარებენ. ერთი მისამართისა და იჯარის გამოყოფაა. მეორე კონფიგურაციის მიწოდებაა იმ ჰოსტისთვის, რომელსაც უკვე აქვს მისამართი, რასაც RFC 2131 DHCPINFORM-ს უწოდებს. მეორე შემთხვევაში პასუხი პარამეტრებს ატარებს და არავითარ იჯარის დროს.

ანუ ACK პასუხის მტკიცებულებაა და არა გამოყოფის. რომელი კითხვა დაისვა, ამას მის წინა შეტყობინება წყვეტს. ჯერ მოთხოვნის სტრიქონი წაიკითხეთ და კვალის დარჩენილი ნაწილი ჩვეულებრივ თავისთავად იხსნება.

საიდან იღებს RRAS მისამართს

RRAS ფლობს VPN მისამართის გადაწყვეტილებას თავისი კონფიგურირებული IPv4 მინიჭების მეთოდით: ან DHCP სერვერით, ან სტატიკური მისამართების აუზით. როცა აუზი სტატიკურია, აუზია გამანაწილებელი და ცალკე DHCP სერვერზე არსებულ დაჯავშნას ამ სესიაში სათქმელი არ აქვს. ორი მექანიზმი ერთ ქსელში თანაარსებობას შეძლებს ისე, რომ ერთი მეორეს არ მართავდეს.

Get-Command -Module RemoteAccess *IPAddress*

სანამ მისამართს გაურკვევთ, იპოვეთ მოქმედი მინიჭების მეთოდი. თუ სტატიკური აუზია, DHCP სკოპი შეხედვის არასწორი ადგილია. ზემოთ მოცემული ბრძანება ჩამოთვლის იმ cmdlet-ებს, რომლებიც თქვენს მიერ გაშვებულ ვერსიაშია ხელმისაწვდომი და პარამეტრის საპოვნელად ეს საკმარისია.

რა შეუძლია და რა არ შეუძლია მომხმარებლის კლასს დაამტკიცოს

DHCP მომხმარებლის კლასი კლიენტის მიერ გაგზავნილი სტრიქონია და არა ავთენტიფიცირებული ჯგუფური წევრობა. მაშინაც კი, როცა კლიენტი ერთს აგზავნის და სერვერი მასზე პოლიტიკას ადარებს, იარლიყი მხოლოდ იმას ამტკიცებს, რომ სტრიქონი ჩამოვიდა. RFC 3004 პირდაპირ ამბობს, რომ პარამეტრი კლასზე უფლებას არ ავთენტიფიცირებს.

ნუ დაელოდებით, რომ VPN მომხმარებლის სახელი, უსაფრთხოების ჯგუფის იდენტიფიკატორი ან ლეპტოპის Ethernet მისამართი იმ მოთხოვნაში გამოსაყენებელი ფორმით გამოჩნდება. ეს ავთენტიფიკაციისა და კატალოგის ფაქტებია და DHCP მოთხოვნა არც ერთს ატარებს. თუ მოთხოვნა უფლებამოსილი ადამიანების გარჩევაა, განახორციელეთ ის VPN პოლიტიკაში, სადაც იდენტობა ნამდვილად არსებობს. სწორედ ეს გაყოფა ინახავს ორ სისტემას დამოუკიდებელად.

შეადარეთ მტკიცებულებები და არა ACK

ააგეთ მტკიცებულებათა ჯაჭვი ერთი პაკეტის წაკითხვის ნაცვლად. ჩაწერეთ სესიის მიერ მიღებული მისამართი, მოთხოვნის შეტყობინების ტიპი და ველები, სერვერის მიერ დაბრუნებული პარამეტრები და შემდეგ კლიენტის ფაქტობრივი კონფიგურაცია. ყოველი რგოლი სხვა კითხვას პასუხობს და დაკარგული რგოლი სწორედ ის ადგილია, სადაც ნამდვილი ხარვეზი ჩვეულებრივ ზის.

Get-DhcpServerv4OptionValue -ScopeId 10.90.0.0

თუ მისამართი RRAS-ის აუზიდან მოვიდა, DHCP დაჯავშნა არაფერს ხსნის. თუ პარამეტრები ჩამოვიდა, მაგრამ კლიენტმა უგულებელყო, სერვერმა თავისი საქმე გააკეთა და შემდეგი გაჩერება კლიენტის კონფიგურაციაა. ეს ორი შედეგი ცხადად შეადარეთ და ACK აღარ არის ორაზროვანი. ორი კვალი, თითო ყოველი მინიჭების მეთოდიდან, კამათს ნებისმიერ დოკუმენტზე სწრაფად წყვეტს.