ಬೂಟ್ನಲ್ಲಿ OpenVPN ಟನೆಲ್ ಸಿದ್ಧವಾಗುವ ಮೊದಲೇ RRAS ಪ್ರಾರಂಭವಾಗುತ್ತದೆ
ಅವಲಂಬನೆಯು ಸೇವೆಯ ಪ್ರಾರಂಭದ ಕ್ರಮವನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ; ಅದು ಟನೆಲ್ ಅನ್ನು ಬಳಸಲು ಯೋಗ್ಯವಾಗಿಸುವುದಿಲ್ಲ. 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 ಅದನ್ನು ಅಂತಿಮವಾಗಿ ಸ್ವೀಕರಿಸಿದಾಗ. ಆ ಒಂದೇ ಸಾಲು ಮುಂದಿನ ಎಂಜಿನಿಯರ್ ಕೇಳುವ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ, ಮತ್ತು ಅದನ್ನು ರಚಿಸಲು ಬಹುತೇಕ ಏನೂ ಖರ್ಚಾಗುವುದಿಲ್ಲ. ಅದಿಲ್ಲದೆ ಮುಂದಿನ ತನಿಖೆ ಈ ತನಿಖೆಯ ಅದೇ ಊಹೆಯಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ.
ನಿಗದಿತ ಸಂಖ್ಯೆಯ ಪ್ರಯತ್ನಗಳ ನಂತರ ಆಟೊಮೇಷನ್ ನಿಲ್ಲಿಸಿ ಮತ್ತು ಶಾಶ್ವತವಾಗಿ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುವ ಬದಲು ವೈಫಲ್ಯವನ್ನು ವರದಿ ಮಾಡಿ. «ಸಂಪನ್ಮೂಲ ಎಂದೂ ಕಾಣಿಸಲಿಲ್ಲ» ಎಂಬ ಸ್ಪಷ್ಟ ಸಂದೇಶದೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುವ ಬೂಟ್ ಕತ್ತಲೆಯಲ್ಲಿ ಸೇವೆಯನ್ನು ಮರುಪ್ರಾರಂಭಿಸುತ್ತಲೇ ಇರುವ ಬೂಟ್ಗಿಂತ ಹೆಚ್ಚು ಮೌಲ್ಯಯುತ. ಆ ಸಂದೇಶ ಬಂದಾಗ, ಎರಡನೇ ವಿಭಾಗದಲ್ಲಿ ನೀವು ಬರೆದ ಸಂಪನ್ಮೂಲದ ಹೆಸರನ್ನೇ ಮುಂದಿನ ವ್ಯಕ್ತಿ ಹುಡುಕುತ್ತಾರೆ.