RRAS-ის VPN კლიენტებს საკუთარი IPv4 პული და დაბრუნების გზა სჭირდებათ

VPN კლიენტი უკავშირდება და იღებს მისამართს, მაგრამ LAN ჰოსტი, რომელიც მას სჭირდება, მაინც ვერ პასუხობს. Windows Routing and Remote Access-ში VPN კლიენტების შიდა მისამართი მოდის პულიდან, რომელიც სერვერის LAN ადაპტერისგან ცალკე კონფიგურირდება, და LAN მხარეს სჭირდება დაბრუნების მარშრუტი ამ პულამდე. ორი ცვლილება, არა ერთი, და ისინი სხვადასხვაგვარად ფარუდდება. გაიარეთ ისინი თანმიმდევრობით, რათა მისამართების გეგმა და დაბრუნების გზა დადასტურდეს ძველი დიაპაზონების გაუქმებამდე.

დაჯავშნეთ დიაპაზონი კონსოლის გახსნამდე

აირჩიეთ პრეფიქსი, რომელიც არ ემთხვევა LAN-ს, სხვა VPN დიაპაზონებს ან საიტში მარშრუტირებულ ნებისმიერ რამეს. /24 მოსახერხებელი ზომაა ტესტისთვის, და პირველი გამოსადეგი ნაწილი შეიძლება კლიენტებს მიეცეს, დანარჩენი კი ზრდისთვის თავისუფალი დარჩეს. ჩაწერეთ ის მიზანთან და მფლობელთან ერთად, სანამ კონსოლში აკრიფებთ. დატოვეთ ადგილი ბლოკის ორივე ბოლოში, რათა მოგვიანებით დაყოფამ ხელახალი ნუმერაცია არ აიძულოს.

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

სერვერის LAN ადაპტერი არ განსაზღვრავს ამ პულს. საჯარო მსმენელის შეცვლა ან LAN-ზე ადაპტერის დამატება სულ სხვა რამეს აკეთებს. ამიტომ კლიენტებს შეუძლიათ დაკავშირება და მაინც მიიღონ მისამართი არასწორი ადგილიდან. პული ცხოვრობს სერვერის IPv4 თვისებებში, არა ადაპტერების სიაში.

მეთოდის შეცვლა დიაპაზონის დამატება არ არის

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

გადახედეთ ორივე ოპერაციას, სანამ რომელიმეს გაუშვებთ, და წაიკითხეთ, რომელი შეესაბამება სერვერის მიმდინარე მდგომარეობას:

Set-VpnIPAddressAssignment -IPAssignmentMethod StaticPool -IPAddressRange '10.250.50.10','10.250.50.100' -WhatIf
Add-VpnIPAddressRange -IPAddressRange '10.250.50.110','10.250.50.150' -WhatIf

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

Get-VpnIPAddressRange

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

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

LAN-ს დაბრუნების მარშრუტი სჭირდება

დავუშვათ, LAN არის 10.60.0.0/24, ხოლო RRAS სერვერი მასზე 10.60.0.10. ამ LAN-ის ჰოსტს, რომელიც პასუხობს 10.250.50.0/24-ის კლიენტს, სჭირდება გზა პულამდე RRAS სერვერის გავლით. ამ გზის გარეშე მოთხოვნა აღწევს და პასუხი კვდება.

თუ ჰოსტის ნაგულისხმევი კარიბჭე სხვა როუტერია, ამ როუტერს სჭირდება დაბრუნების მარშრუტი VPN პრეფიქსისთვის. სტატიკური მარშრუტი RRAS სერვერზე აქ არ ეხმარება; დაბრუნების გზა უნდა არსებობდეს იმ მოწყობილობაზე, რომელსაც LAN კარიბჭე ეკუთვნის, ამიტომ დაამატეთ ის მარშრუტიზაციის ცხრილში ან დინამიკური მარშრუტიზაციის პროცესში, იმის მიხედვით, რას იყენებს საიტი.

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

დაამტკიცეთ ახალი პული ერთ მოწყობილობაზე, სანამ ძველს გააუქმებთ

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

სახელების ამოხსნა იმსახურებს საკუთარ ტესტს: IP-ით წვდომა შეიძლება მუშაობდეს, სანამ კლიენტის DNS ჯერ კიდევ მიუთითებს რეზოლვერზე, რომელსაც ის ვერ აღწევს. LAN-ის DNS სერვერი ხელმისაწვდომია მხოლოდ მაშინ, თუ კლიენტს მისკენ მარშრუტი აქვს და სერვერი ახალი დიაპაზონიდან მოთხოვნებს იღებს. ორივე ხშირი გამოტოვებაა, როცა პული გადადის.

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

შეამოწმეთ შედეგი სამი დაკვირვებით

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

კლიენტის მხრიდან დაადასტურეთ მისამართი და გზა ერთ LAN ჰოსტამდე:

ipconfig | findstr /i "IPv4"
route print -4

LAN ჰოსტის მხრიდან დაადასტურეთ პასუხის გზა და პოლიტიკა ერთ გავლაში. თუ ping ფარუდდება, მაგრამ აპლიკაცია მუშაობს, ნაკლული ნაწილი სავარაუდოდ ICMP წესია და არა მარშრუტი. თუ ორივე ფარუდდება, წაიკითხეთ მარშრუტი ჰოსტზე VPN-ის რედაქტირებამდე. ჩაწერეთ სამი შედეგი ცვლილების ბილეთში, რათა შემდეგი ადამიანი მტკიცებულებებიდან დაიწყოს.