RRAS იწყება OpenVPN-ის გვირაბის მზადყოფნამდე ჩატვირთვისას
დამოკიდებულება აწესრიგებს სერვისის გაშვების რიგს; ის გვირაბს გამოსაყენებელს არ ხდის. დაასახელეთ რესურსი, რომელიც RRAS-ს სჭირდება, და გადატვირთვა სწორედ მასზე დააფუძნეთ, ლოდინის ნაცვლად.
სერვერი გადაიტვირთება, OpenVPN იწყება და RRAS ადის, სანამ ადაპტერი ან მარშრუტი, რომელზეც ის დამოკიდებულია, ჯერ არ არსებობს. RRAS-ის ხელით გადატვირთვა ერთი წუთის შემდეგ ასწორებს ამას, რაც პრობლემას მოგვარებულად აჩვენებს და ნამდვილს მალავს. აქ ორი განსხვავებული პირობა ერევა: წინაპირობა-სერვისი მუშაობს, და ქსელური რესურსი, რომელიც RRAS-ს ნამდვილად სჭირდება, გამოსაყენებელი გახდა. Windows-ის სერვისის დამოკიდებულებას შეუძლია გამოხატოს პირველი პირობა და არასდროს მეორე, ამიტომ რესურსის განსაზღვრის გარეშე დამოკიდებულების დამატება გაძლევთ უფრო მოწესრიგებულ ჩატვირთვას და იმავე ხარვეზს.
როგორ გამოიყურება სიმპტომი ცივ ჩატვირთვაზე
ნიშანია განსხვავება ცივ დაწყებასა და გადატვირთვას შორის. ცივ დაწყებაზე RRAS იტყობინება, რომ მუშაობს, მაშინ როცა გვირაბის ადაპტერი არ არსებობს, მარშრუტი დაკარგულია, ან პარტნიორის მისამართი ჯერ არ იხსნება. ხელით გადატვირთვა შემდეგ წარმატებულია, რადგან იმ დროისთვის რესურსი არსებობს და სერვისი უბრალოდ ხელახლა კითხულობს სამყაროს, რომელსაც წუთით ადრე ვერ ხედავდა. სერვისის ჟურნალი ორივე შემთხვევაში სუფთა დაწყებას აჩვენებს, ამიტომ მოვლენების მნახველი მარტო იშვიათად ხსნის ამას.
დააფიქსირეთ ორივე მდგომარეობა სანამ რამეს შეცვლით: რას იტყობინება RRAS ჩატვირთვისას, და რა არსებობს იმ მომენტში, როცა ხელით გადატვირთვა წარმატებულია. თუ ეს ორი დაკვირვება იდენტურია, გაშვების რიგი თქვენი ახსნა არ არის და დამოკიდებულება არ დაგეხმარებათ. შედარება ათ წუთს ღირს და ერთი კვირის გამოცნობას ზოგავს.
„გადატვირთვის შემდეგ მუშაობს“ საფუძველზე დამატებული დამოკიდებულება მხოლოდ იმდენ ხანს აყოვნებს იმავე ხარვეზს, რამდენიც წინაპირობა-სერვისს სჭირდება RUNNING-ის შესატყობინებლად. ის ჩატვირთვას უფრო ძნელად გასაგებსაც ხდის, რადგან რიგის შეზღუდვა ახლა ახსნას ჰგავს. იკითხეთ, რომელ ობიექტს იცავს დამოკიდებულება და არის თუ არა ის ობიექტი, რომელსაც RRAS ვერ ხედავდა.
დაასახელეთ რესურსი, და არა მხოლოდ სერვისი
ჩაწერეთ კონკრეტული რამ, რაც აკლია. ეს შეიძლება იყოს მისამართის მქონე გვირაბის ადაპტერი, მარშრუტი პარტნიორის ქვექსელისკენ, DNS-ის პასუხი, ან ჯერ გაცემის პროცესში მყოფი სერტიფიკატი. „VPN სერვისი მუშაობს“ რესურსის აღწერა არ არის, და კლიენტში მწვანე ხატულა არც. სანამ ვერ დაასახელებთ ობიექტს და ბრძანებას, რომელიც მას აჩვენებს, თქვენ არ განსაზღვრეთ ის პირობა, რომლის ლოდინიც გსურთ.
დაადგინეთ ასევე, როგორ ირთვება OpenVPN-ის ეს ინსტანცია. GUI-ით მართული გვირაბი და სერვისით მართული გვირაბი სხვადასხვა ჩატვირთვის სასიცოცხლო ციკლს აქვს, და სერვისის სახელი უნდა მოვიდეს თქვენს წინ მდგარი მანქანიდან, და არა სხვა ინსტალატორისთვის დაწერილი მაგალითიდან. ჩამოთვალეთ კანდიდატები დამახსოვრებული სახელის ნდობის ნაცვლად.
Get-Service | Where-Object Name -match 'vpn|openvpn' | Select-Object Name, Status, StartType
წაიკითხეთ დამოკიდებულებათა ჯაჭვი სანამ რამეს დაამატებთ
სერვისების მართვის მენეჯერი იტყობინება მდგომარეობებს, როგორიცაა START_PENDING და RUNNING, და SERVICE_STATUS reference ზუსტად განსაზღვრავს, რას ნიშნავს თითოეული ველი. არც ერთი ამ მდგომარეობიდან არ გპირდებათ, რომ პარტნიორი, DNS სახელი ან ქვედა დონის აპლიკაცია ხელმისაწვდომია. სწორედ ეს უფსკრულია მთელი მიზეზი, თუ რატომ გადაურჩება ეს ხარვეზი სწორად კონფიგურირებულ დამოკიდებულებას.
Get-Service -Name RemoteAccess | Select-Object Status, StartType sc.exe qc RemoteAccess Get-Service -Name RemoteAccess | Select-Object -ExpandProperty DependentServices
sc.exe qc-დან მიღებული DEPENDENCIES ხაზი არის ის სია, რომელიც უნდა შეინარჩუნოთ, რადგან sc.exe config RemoteAccess depend= ცვლის მთელ სიას და არა ამატებს მას. VPN სერვისის დამატებისას დაუკავშირებელი წინაპირობის გამოტოვება ქმნის მეორე ხარვეზს, რომელიც სხვა ჩატვირთვაზე ჩნდება, და მისი დიაგნოსტიკა გაცილებით რთულია, ვიდრე საწყისის. დააკოპირეთ არსებული სია თქვენს ცვლილებათა ჩანაწერში, სანამ მას შეეხებით.
დამოკიდებულებები ცვლის გამორთვის ქცევასაც, რადგან წინაპირობის გაჩერება აჩერებს მასზე დამოკიდებულ სერვისებს. შეამოწმეთ, რა ხდება ტექნიკური მომსახურების დროს, სანამ RRAS-ს დააკავშირებთ რაიმესთან, რაც ხშირად გადაიტვირთება.
გადატვირთვა პირობაზე დააფუძნეთ, და არა ტაიმერზე
ფიქსირებული ლოდინი ვარაუდობს, რომ გვირაბი ყოველთვის მზად იქნება ამ ფანჯარაში, და სწორედ ეს ვარაუდი ვარდება იმ ჩატვირთვაზე, როცა სერტიფიკატი ნელია ან კავშირი გაწყვეტილია. შეამოწმეთ თავად რესურსი ვადით და მისცეთ შემოწმებას გადაწყვეტილება, საერთოდ საჭიროა თუ არა გადატვირთვა.
Get-NetAdapter | Where-Object Status -eq 'Up' Get-NetRoute -DestinationPrefix 0.0.0.0/0 Get-WinEvent -LogName System -MaxEvents 40 | Where-Object ProviderName -eq 'Service Control Manager'
ჩატვირთვისას გაშვებული დაგეგმილი ამოცანა, რომელიც ამ შემოწმებებს ასრულებს და RRAS-ს მხოლოდ მაშინ გადატვირთავს, როცა ადაპტერი ან მარშრუტი ჯერ არ არსებობს, შეზღუდული, აუდიტირებადი და ადვილად მოსაშორებელია. ალტერნატივა — RRAS-ის გადატვირთვა ყოველ ხელახალ დაკავშირებაზე — წყვეტს ჯანსაღ სესიებს და არასტაბილურ კავშირს გადატვირთვების ციკლად აქცევს. ეს ციკლი უარესია საწყის ხარვეზზე, რადგან ახლა ეხება მომხმარებლებს, რომლებსაც ყველაფერი კარგად ჰქონდათ.
მიეცით შემოწმებას მაქსიმალური ლოდინი, რომელიც შეესაბამება იმ დროს, რაც გვირაბს თქვენს აპარატურაზე გონივრულად სჭირდება, და დაე, ამოცანა დანებებისას არანულოვანი სტატუსით დასრულდეს. ჩუმი ამოცანა, რომელიც უბრალოდ წყვეტს ცდას, არ განსხვავდება წარმატებულისგან.
ჩაწერეთ გადასვლა, რათა შემდეგმა ჩატვირთვამ თავად ახსნას თავი
ერთსა და იმავე ხაზზე ჩაწერეთ სამი დროის ნიშა: როდის მიაღწია დამოკიდებულების სერვისმა RUNNING-ს, როდის გამოჩნდა საჭირო რესურსი და როდის მიიღო ის RRAS-მა საბოლოოდ. ეს ერთი ხაზი პასუხობს კითხვას, რომელსაც შემდეგი ინჟინერი დასვამს, და მის შექმნას თითქმის არაფერი ღირს. მის გარეშე შემდეგი გამოძიება იწყება იმავე გამოცნობიდან, როგორც ეს.
შეაჩერეთ ავტომატიზაცია განსაზღვრული რაოდენობის ცდის შემდეგ და შეატყობინეთ უკმარისობას უსასრულო გამეორების ნაცვლად. ჩატვირთვა, რომელიც მთავრდება მკაფიო შეტყობინებით „რესურსი არასდროს გამოჩნდა“, უფრო ღირებულია, ვიდრე ის, რომელიც აგრძელებს სერვისის გადატვირთვას სიბნელეში. როცა ეს შეტყობინება გამოჩნდება, მეორე ნაწილში ჩაწერილი რესურსის სახელია ის, რასაც შემდეგი ადამიანი მოძებნის.