RRAS se pokreće prije nego što je OpenVPN tunel spreman pri podizanju sistema

Server se ponovo pokreće, OpenVPN se pokreće, a RRAS se diže dok adapter ili ruta o kojoj zavisi još nedostaje. Ručno ponovno pokretanje RRAS-a minutu kasnije to popravlja, zbog čega se čini da je problem riješen i krije pravi. Ovdje se miješaju dva različita uslova: usluga preduslova radi, i mrežni resurs koji RRAS zapravo treba postao je upotrebljiv. Zavisnost Windows usluge može izraziti prvi uslov i nikada drugi, pa dodavanje zavisnosti bez definisanja resursa daje uredniji izgled podizanja i istu grešku.

Kako simptom izgleda pri hladnom podizanju

Znak je razlika između hladnog starta i ponovnog pokretanja. Pri hladnom startu RRAS prijavljuje da radi dok je tunelski adapter odsutan, ruta nedostaje ili se adresa sagovornika još ne razrješava. Ručno ponovno pokretanje tada uspijeva jer u tom trenutku resurs postoji, a usluga jednostavno ponovo čita svijet koji prije minutu nije mogla vidjeti. Dnevnik usluge pokazat će čisto pokretanje u oba slučaja, zato preglednik događaja sam rijetko objašnjava ovo.

Zabilježite oba stanja prije nego što bilo šta promijenite: šta RRAS prijavljuje pri podizanju i šta postoji u trenutku kada ručno ponovno pokretanje uspije. Ako su ta dva zapažanja identična, redoslijed pokretanja nije vaše objašnjenje i zavisnost neće pomoći. Poređenje košta deset minuta i štedi sedmicu nagađanja.

Zavisnost dodana na osnovu „radi nakon ponovnog pokretanja“ samo odgađa istu grešku za vrijeme koje je potrebno usluzi preduslova da prijavi RUNNING. Ona i podizanje čini težim za razumijevanje, jer ograničenje redoslijeda sada izgleda kao objašnjenje. Pitajte koji objekat zavisnost garantuje i da li je taj objekat onaj koji RRAS nije mogao vidjeti.

Imenujte resurs, ne samo uslugu

Zapišite konkretnu stvar koja nedostaje. To može biti tunelski adapter s adresom, ruta do podmreže sagovornika, odgovor DNS-a ili certifikat koji se još dodjeljuje. „VPN usluga radi“ nije opis resursa, kao ni zelena ikona u klijentu. Dok ne možete imenovati objekat i naredbu koja ga prikazuje, niste definisali uslov koji pokušavate čekati.

Ustanovite i kako se pokreće ova instanca OpenVPN-a. Tunel kojim upravlja GUI i tunel kojim upravlja usluga imaju različite životne cikluse podizanja, a naziv usluge mora doći s mašine pred vama, ne iz primjera pisanog za drugi instalater. Nabrojte kandidate umjesto da vjerujete zapamćenom nazivu.

Get-Service | Where-Object Name -match 'vpn|openvpn' | Select-Object Name, Status, StartType

Pročitajte lanac zavisnosti prije nego što mu nešto dodate

Upravitelj upravljanja uslugama prijavljuje stanja kao što su START_PENDING i RUNNING, a SERVICE_STATUS reference tačno definiše šta svako polje znači. Nijedno od tih stanja ne obećava da su sagovornik, DNS naziv ili aplikacija nizvodno dostupni. Taj jaz je cijeli razlog zašto ova greška preživljava ispravno konfigurisanu zavisnost.

Get-Service -Name RemoteAccess | Select-Object Status, StartType
sc.exe qc RemoteAccess
Get-Service -Name RemoteAccess | Select-Object -ExpandProperty DependentServices

Red DEPENDENCIES iz sc.exe qc je lista koju morate sačuvati, jer sc.exe config RemoteAccess depend= zamjenjuje cijelu listu umjesto da joj dodaje. Izostavljanje nepovezanog preduslova dok dodajete VPN uslugu stvara drugu grešku koja se pojavljuje pri drugom podizanju i mnogo ju je teže dijagnostikovati od originalne. Kopirajte postojeću listu u zapis o promjenama prije nego što je dirnete.

Zavisnosti mijenjaju i ponašanje pri gašenju, jer zaustavljanje preduslova zaustavlja usluge koje o njemu zavise. Provjerite šta se dešava tokom održavanja prije nego što RRAS povežete s nečim što se često ponovo pokreće.

Uslovite ponovno pokretanje uslovom, a ne tajmerom

Fiksno čekanje pretpostavlja da će tunel uvijek biti spreman unutar tog prozora, a to je upravo pretpostavka koja pada pri podizanju kada je certifikat spor ili je veza prekinuta. Provjerite sam resurs, s krajnjim rokom, i pustite provjeru da odluči da li je ponovno pokretanje uopšte potrebno.

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'

Zakazani zadatak pri pokretanju koji izvršava te provjere i ponovo pokreće RRAS samo kada adapter ili ruta još nedostaju je ograničen, revidiran i lak za uklanjanje. Alternativa, ponovno pokretanje RRAS-a pri svakom ponovnom povezivanju, prekida zdrave sesije i pretvara nestabilnu vezu u petlju ponovnog pokretanja. Ta petlja je gora od originalne greške, jer sada pogađa korisnike kojima je bilo dobro.

Dajte provjeri maksimalno čekanje koje odgovara razumnom vremenu tunela na vašem hardveru i neka zadatak završi s nenultim statusom kada odustane. Tihi zadatak koji jednostavno prestane pokušavati ne razlikuje se od onog koji je uspio.

Zabilježite prelaz da se sljedeće podizanje samo objasni

Zabilježite tri vremenske oznake u istom redu: kada je usluga zavisnosti dostigla RUNNING, kada se pojavio potrebni resurs i kada ga je RRAS konačno prihvatio. Taj jedan red odgovara na pitanje koje će sljedeći inženjer postaviti i gotovo ništa ne košta. Bez njega sljedeća istraga počinje od istog nagađanja kao i ova.

Zaustavite automatizaciju nakon definisanog broja pokušaja i prijavite neuspjeh umjesto vječitog ponavljanja. Podizanje koje završi jasnom porukom „resurs se nikada nije pojavio“ vrijedi više od onog koje nastavlja ponovo pokretati uslugu u mraku. Kada se ta poruka pojavi, naziv resursa koji ste zapisali u drugom odjeljku je ono što će sljedeća osoba tražiti.