ਬੂਟ ਵੇਲੇ 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

ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਨਿਰਭਰਤਾ ਲੜੀ ਪੜ੍ਹੋ

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 ਨੇ ਅੰਤ ਵਿੱਚ ਉਸ ਨੂੰ ਕਦੋਂ ਸਵੀਕਾਰ ਕੀਤਾ। ਉਹੀ ਇੱਕ ਲਾਈਨ ਅਗਲੇ ਇੰਜੀਨੀਅਰ ਵੱਲੋਂ ਪੁੱਛੇ ਜਾਣ ਵਾਲੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਇਸ ਨੂੰ ਬਣਾਉਣ ਵਿੱਚ ਲਗਭਗ ਕੁਝ ਵੀ ਖ਼ਰਚ ਨਹੀਂ ਹੁੰਦਾ। ਇਸ ਤੋਂ ਬਿਨਾਂ ਅਗਲੀ ਜਾਂਚ ਇਸੇ ਜਾਂਚ ਦੇ ਅੰਦਾਜ਼ੇ ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ।

ਨਿਸਚਿਤ ਗਿਣਤੀ ਦੀਆਂ ਕੋਸ਼ਿਸ਼ਾਂ ਤੋਂ ਬਾਅਦ ਆਟੋਮੇਸ਼ਨ ਰੋਕੋ ਅਤੇ ਬੇਅੰਤ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਦੀ ਥਾਂ ਅਸਫਲਤਾ ਦੱਸੋ। «ਸਰੋਤ ਕਦੇ ਪ੍ਰਗਟ ਨਹੀਂ ਹੋਇਆ» ਵਰਗੇ ਸਾਫ਼ ਸੰਦੇਸ਼ ਨਾਲ ਖ਼ਤਮ ਹੋਣ ਵਾਲਾ ਬੂਟ ਹਨੇਰੇ ਵਿੱਚ ਸੇਵਾ ਮੁੜ ਸ਼ੁਰੂ ਕਰਦੇ ਰਹਿਣ ਵਾਲੇ ਬੂਟ ਨਾਲੋਂ ਵਧੇਰੇ ਕੀਮਤੀ ਹੈ। ਜਦੋਂ ਉਹ ਸੰਦੇਸ਼ ਆਵੇਗਾ, ਦੂਜੇ ਭਾਗ ਵਿੱਚ ਤੁਸੀਂ ਲਿਖਿਆ ਸਰੋਤ ਦਾ ਨਾਮ ਹੀ ਅਗਲਾ ਵਿਅਕਤੀ ਲੱਭੇਗਾ।