RRAS બૂટ વખતે OpenVPN ટનલ તૈયાર થાય તે પહેલાં શરૂ થાય છે

સર્વર ફરી બૂટ થાય છે, 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

ઉમેરતા પહેલાં નિર્ભરતાની સાંકળ વાંચો

Service Control Manager 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 એ ક્યારે છેવટે તેને સ્વીકાર્યું. એ જ એક લાઇન આગલા એન્જિનિયર પૂછશે તે પ્રશ્નનો જવાબ આપે છે, અને તેને બનાવવાનો ખર્ચ લગભગ કંઈ જ નથી. તેના વિના આગલી તપાસ આ તપાસની જ અટકળોથી શરૂ થાય છે.

નિશ્ચિત સંખ્યાના પ્રયાસો પછી ઓટોમેશન બંધ કરો અને કાયમ ફરી પ્રયાસ કરવાને બદલે નિષ્ફળતા જણાવો. «સંસાધન ક્યારેય દેખાયું નહીં» એવા સ્પષ્ટ સંદેશ સાથે પૂરું થતું બૂટ અંધકારમાં સેવા ફરી શરૂ કરતું બૂટ કરતાં વધુ મૂલ્યવાન છે. જ્યારે એ સંદેશ આવશે, ત્યારે બીજા વિભાગમાં તમે લખેલું સંસાધનનું નામ આગલી વ્યક્તિ શોધશે તે જ હશે.