Windows ನಲ್ಲಿ OpenVPN ಅಡಾಪ್ಟರ್ ಮತ್ತೆ ಮತ್ತೆ ಬೀಳುತ್ತಿದೆಯೇ? ನಕಲಿ IP ಪರಿಶೀಲಿಸಿ
Windows ನಲ್ಲಿ ಪದೇ ಪದೇ ಬೀಳುವ ಅಡಾಪ್ಟರ್ ಸಾಮಾನ್ಯವಾಗಿ ವಿಳಾಸ ಘರ್ಷಣೆ, ಡ್ರೈವರ್ ದೋಷ ಅಲ್ಲ. 4198 ಮತ್ತು 4199 ಘಟನೆಗಳನ್ನು ಓದಿ, ಎರಡನೇ ಮಾಲೀಕರನ್ನು ಹುಡುಕಿ, ನಂತರ ಅನನ್ಯ ವಿಳಾಸಗಳನ್ನು ಪಿನ್ ಮಾಡಿ.
Windows ನಲ್ಲಿ, ವಿಳಾಸವನ್ನು ತೆಗೆದುಕೊಂಡು, ಅದನ್ನು ಬಿಟ್ಟು, ಪ್ರತಿ ಕೆಲವು ಸೆಕೆಂಡುಗಳಿಗೊಮ್ಮೆ ಅದನ್ನು ಪುನರಾವರ್ತಿಸುವ OpenVPN ಅಡಾಪ್ಟರ್ ಸಾಮಾನ್ಯವಾಗಿ DHCP ದೋಷವಲ್ಲ. ಇನ್ನೊಂದು ಈಗಾಗಲೇ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತಿರುವ ವಿಳಾಸವನ್ನು ಬಳಸಲು ಅಡಾಪ್ಟರ್ಗೆ ಹೇಳಲಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ Windows ಅದನ್ನು ಬಳಸಲಾಗದು ಎಂದು ಗುರುತಿಸುತ್ತದೆ ಮತ್ತು ಕ್ಲೈಂಟ್ ಮತ್ತೆ ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಘರ್ಷಣೆಯು ಅದರ ಕೆಳಗೆ, ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಂನ ಸ್ವಂತ ನೆಟ್ವರ್ಕ್ ಸ್ಟ್ಯಾಕ್ನೊಳಗೆ ಪರಿಹಾರವಾಗುವುದರಿಂದ ಕ್ಲೈಂಟ್ ಲಾಗ್ ಶಾಂತವಾಗಿರುತ್ತದೆ.
ಈ ವ್ಯತ್ಯಾಸ ಮುಖ್ಯ, ಏಕೆಂದರೆ ಟನೆಲ್ ಕಾನ್ಫಿಗರೇಶನ್ ಕಡೆಗೆ ಗುರಿಯಾದ ಪ್ರತಿ ದೋಷನಿವಾರಣೆ ಹಂತವೂ ಸರ್ವರ್ ಬದಿಯ ನಕಲಿ ವಿಳಾಸವನ್ನು ತಪ್ಪಿಸಿಕೊಳ್ಳುತ್ತದೆ.
ಕ್ಲೈಂಟ್ ಲಾಗ್ನಿಂದ ಅಲ್ಲ, Windows ಈವೆಂಟ್ ಲಾಗ್ನಿಂದ ಪ್ರಾರಂಭಿಸಿ
Windows ವಿಳಾಸ ಘರ್ಷಣೆಗಳನ್ನು ಸಿಸ್ಟಂ ಲಾಗ್ನಲ್ಲಿ 4198 ಮತ್ತು 4199 ಈವೆಂಟ್ IDಗಳೊಂದಿಗೆ ದಾಖಲಿಸುತ್ತದೆ. ಮೊದಲನೆಯದು ವಿಳಾಸಕ್ಕೆ ಪತ್ತೆಯಾದ ಘರ್ಷಣೆಯನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ, ಎರಡನೆಯದು ಇಂಟರ್ಫೇಸ್ ತಾನು ಕಾನ್ಫಿಗರ್ ಆಗಿದ್ದ ವಿಳಾಸವನ್ನು ಬಳಸಲಾಗಲಿಲ್ಲ ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ. ಎರಡೂ OpenVPN ಅನ್ನು ಉಲ್ಲೇಖಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಅದಕ್ಕಾಗಿಯೇ ಅವನ್ನು ಕಡೆಗಣಿಸುವುದು ಸುಲಭ.
ಇತ್ತೀಚಿನ ಈವೆಂಟ್ಗಳನ್ನು ಎಳೆಯಿರಿ ಮತ್ತು ಅವುಗಳ ಸಮಯ ಮುದ್ರೆಗಳನ್ನು ಅಡಾಪ್ಟರ್ನ ನವೀಕರಣ ಚಕ್ರದೊಂದಿಗೆ ಹೋಲಿಸಿ: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. ಪ್ರತಿ ಹದಿನೈದು ಸೆಕೆಂಡುಗಳಿಗೊಮ್ಮೆ ಘರ್ಷಣೆ ಎಂದರೆ ಅದೇ ವಿಳಾಸಕ್ಕೆ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತಲೇ ಇರುವ ಮಾಲೀಕರ ವಿರುದ್ಧ ಅದೇ ವಿಳಾಸವನ್ನು ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುವ ಕ್ಲೈಂಟ್ಗೆ ಹೊಂದುತ್ತದೆ. ಸಂಪರ್ಕದ ಸಮಯದಲ್ಲಿ ಒಂಟಿ ಘರ್ಷಣೆ ಬದಲಿಗೆ ಒಂದೇ ಬಾರಿಯ ಢಿಕ್ಕಿಯನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ, ಮುಂದಿನ ಪ್ರಶ್ನೆ ಎಂದರೆ ವಿಳಾಸವನ್ನು ಇನ್ನಾರು ಹೊಂದಿದ್ದಾರೆ.
ಮೂರು ಜೋಡಣೆಗಳು ಎರಡು ಹೋಸ್ಟ್ಗಳನ್ನು ಒಂದೇ ವಿಳಾಸದ ಮೇಲೆ ಇಡುತ್ತವೆ
ಸರ್ವರ್ನಿಂದ ಅದರ ಅಭಿಪ್ರಾಯದಲ್ಲಿ ವಿಳಾಸ ಯಾರ ಬಳಿ ಇದೆ ಎಂದು ಕೇಳಿ, ನಂತರ ಅದಕ್ಕೆ ಯಾರು ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತಾರೆ ಎಂದು ನೆಟ್ವರ್ಕ್ನಿಂದ ಕೇಳಿ. grep -H ifconfig-push /etc/openvpn/ccd/* ಪ್ರತಿ ಪಿನ್ ಮಾಡಿದ ಟನೆಲ್ ವಿಳಾಸ ಮತ್ತು ಅದು ಸೇರಿದ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ. ip -4 neigh show dev tap0 ಬ್ರಿಡ್ಜ್ ಎರಡನೇ ಪದರದಲ್ಲಿ ಏನು ಕಲಿತಿದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ. ಆ ಎರಡು ಪಟ್ಟಿಗಳನ್ನು ಹೋಲಿಸುವುದು ಹೆಚ್ಚಿನ ನಕಲುಗಳನ್ನು ಒಂದು ನಿಮಿಷಕ್ಕಿಂತ ಕಡಿಮೆ ಸಮಯದಲ್ಲಿ ಕಂಡುಕೊಳ್ಳುತ್ತದೆ.
ಮೂರು ಜೋಡಣೆಗಳು ಬಹುತೇಕ ಎಲ್ಲವನ್ನೂ ವಿವರಿಸುತ್ತವೆ: client-config-dir ನಮೂದು ಎರಡು ಪ್ರಮಾಣಪತ್ರಗಳಿಗೆ ಒಂದು ವಿಳಾಸವನ್ನು ಪಿನ್ ಮಾಡುತ್ತದೆ, ಬ್ರಿಡ್ಜ್ ಮಾಡಿದ tap ವಿಭಾಗವು ಇನ್ನೊಂದು ಹೋಸ್ಟ್ ಈಗಾಗಲೇ ಸ್ಥಿರವಾಗಿ ಹೊಂದಿರುವ ವಿಳಾಸವನ್ನು ಯಂತ್ರಕ್ಕೆ ನೀಡುತ್ತದೆ, ಅಥವಾ ಹಳೆಯ ಗುತ್ತಿಗೆ ಫೈಲ್ ಇನ್ನೂ ಸಂಪರ್ಕಿತವಾಗಿರುವ ಕ್ಲೈಂಟ್ ತನ್ನದೆಂದು ಭಾವಿಸುವ ವಿಳಾಸವನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ. ಮೂರನೇ ಪ್ರಕರಣ ಅತ್ಯಂತ ಮೋಸದಾಯಕ, ಏಕೆಂದರೆ ifconfig-pool-persist ತಿಳಿದಿರುವ ಕ್ಲೈಂಟ್ಗಳಿಗೆ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ವಿಳಾಸಗಳನ್ನು ಮರುಬಳಕೆ ಮಾಡುತ್ತದೆ.
ವಿಳಾಸಕ್ಕಾಗಿ ಓಡುವ ಬದಲು ಅದನ್ನು ಅನನ್ಯಗೊಳಿಸಿ
ಬೂಟ್ ಕ್ರಮವು ಇಂದು ಯಾರು ಗೆಲ್ಲುತ್ತಾರೆ ಎಂಬುದನ್ನು ಮಾತ್ರ ನಿರ್ಧರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಮರುಪ್ರಾರಂಭದ ಕ್ರಮವನ್ನು ಆಧರಿಸಿದ ಯಾವುದೇ ಸರಿಪಡಿಸುವಿಕೆಯನ್ನು ತಾತ್ಕಾಲಿಕವೆಂದು ಪರಿಗಣಿಸಿ. ಪ್ರತಿ ಕ್ಲೈಂಟ್ಗೆ ಅದರ ಸ್ವಂತ ifconfig-push ಸಾಲನ್ನು ನೀಡಿ, ಅಥವಾ ಯಾವುದೇ ಬ್ರಿಡ್ಜ್ ಅಥವಾ ಸರ್ವರ್ ಇಂಟರ್ಫೇಸ್ ಮುಟ್ಟದ ಶ್ರೇಣಿಯಿಂದ ಸ್ಥಿರ ವಿಳಾಸಗಳನ್ನು ಹಂಚಿ. ಕ್ಲೈಂಟ್ ಪಟ್ಟಿಯಲ್ಲಿ ನಕಲಿ ಸಾಮಾನ್ಯ ಹೆಸರುಗಳನ್ನೂ ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ duplicate-cn ಎರಡು ಅವಧಿಗಳಿಗೆ ಒಂದು ಗುರುತನ್ನು ಮತ್ತು ಆದ್ದರಿಂದ ಒಂದು ಪಿನ್ ಮಾಡಿದ ವಿಳಾಸವನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ಅನುಮತಿಸುತ್ತದೆ. ಬ್ರಿಡ್ಜ್ ಮಾಡಿದ ಸಾಧನಕ್ಕೆ ನಿಜವಾಗಿಯೂ ಸ್ಥಿರ ವಿಳಾಸ ಬೇಕಿದ್ದರೆ, ಅದನ್ನು ಅದರ ಸ್ವಂತ ಸಬ್ನೆಟ್ಗೆ ಸರಿಸಿ ಅಥವಾ ಸರ್ವರ್ ದಾಖಲಿಸುವ ಸ್ಥಳದಲ್ಲಿ ಪೂಲ್ನಿಂದ ಕಾಯ್ದಿರಿಸಿ.
persist ಫೈಲ್ ಯಾವ ಗುತ್ತಿಗೆಗಳನ್ನು ಹೊಂದಿದೆ ಎಂದು ತಿಳಿದ ನಂತರವೇ ಅದನ್ನು ಅಳಿಸಿ, ಇಲ್ಲದಿದ್ದರೆ ಮುಂದಿನ ಮರುಸಂಪರ್ಕ ಅದೇ ವಿಳಾಸಗಳನ್ನು ಮತ್ತೆ ಹಂಚುತ್ತದೆ.
ಸರಿಯಾದ ಕ್ರಮದಲ್ಲಿ ಮರುಪ್ರಾರಂಭಿಸಿ ಮತ್ತು ಪ್ರತಿ ವಿಳಾಸಕ್ಕೆ ಒಬ್ಬ ಮಾಲೀಕರನ್ನು ಖಚಿತಪಡಿಸಿ
ಬದಲಾವಣೆಯನ್ನು ಮೊದಲು ಸರ್ವರ್ನಲ್ಲಿ ಅನ್ವಯಿಸಿ, ನಂತರ ಕ್ಲೈಂಟ್ಗಳನ್ನು ಮರುಸಂಪರ್ಕಿಸಿ, ಇದರಿಂದ ಪ್ರತಿ ಭಾಗವಹಿಸುವವರೂ ಸರಿಪಡಿಸಿದ ಪೂಲ್ನ ವಿರುದ್ಧ ನೋಂದಾಯಿಸುತ್ತಾರೆ. ಕ್ಲೈಂಟ್ಗಳನ್ನು ಮೊದಲು ಮರುಪ್ರಾರಂಭಿಸಿದರೆ ಅವು ಸರ್ವರ್ ಇನ್ನೂ ಆಕ್ರಮಿತ ಎಂದು ಭಾವಿಸುವ ವಿಳಾಸಗಳೊಂದಿಗೆ ಉಳಿಯುತ್ತವೆ. ಮರುಪ್ರಾರಂಭದ ನಂತರ ಸ್ಥಿತಿ ಫೈಲ್ ಓದಿ ಮತ್ತು ಪ್ರತಿ ಸಾಮಾನ್ಯ ಹೆಸರು ಒಂದು ವಿಳಾಸದೊಂದಿಗೆ ಒಮ್ಮೆ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ. ಒಂದು ಹೆಸರಿಗೆ ಎರಡು ನಮೂದುಗಳು ಎಂದರೆ ಹಳೆಯ ಅವಧಿ ಎಂದಿಗೂ ಮುಚ್ಚಲಿಲ್ಲ, ಪೂಲ್ ಮುರಿದಿಲ್ಲ.
ಕ್ಲೈಂಟ್ ಇನ್ನೂ ತನ್ನ ವಿಳಾಸವನ್ನು ಉಳಿಸಿಕೊಳ್ಳಲಾಗದಿದ್ದರೆ, ಅದೇ ಹೋಸ್ಟ್ನ ಬ್ರಿಡ್ಜ್ ಇಂಟರ್ಫೇಸ್ ಅದನ್ನು ಹೊತ್ತಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ. ಮಾರಾಟಗಾರರ ಸಾಧನದಿಂದ ವಿಳಾಸವನ್ನು ಆನುವಂಶಿಕವಾಗಿ ಪಡೆದ ಬ್ರಿಡ್ಜ್, VPN ಸರ್ವರ್ ಈಗಾಗಲೇ ಆ ವಿಳಾಸವನ್ನು ಕ್ಲೈಂಟ್ಗೆ ನೀಡಿದ್ದರೂ ಅದಕ್ಕೆ ARP ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ.
ಟಿಕೆಟ್ ಮುಚ್ಚುವ ಮೊದಲು ಪೂರ್ಣ ನವೀಕರಣ ಚಕ್ರದ ಉದ್ದಕ್ಕೂ ಗಮನಿಸಿ
ಒಂದು ಸ್ವಚ್ಛ ಓದುವಿಕೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ಕನಿಷ್ಠ ಹತ್ತು ನಿಮಿಷ ಅಡಾಪ್ಟರ್ ಅನ್ನು ಗಮನಿಸಿ ಮತ್ತು ಮಧ್ಯದಲ್ಲಿ ಮರುಸಂಪರ್ಕವನ್ನು ಒತ್ತಾಯಿಸಿ: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. ವಿಳಾಸವು ಮರುಸಂಪರ್ಕವನ್ನು ದಾಟಿ ಉಳಿಯಬೇಕು ಮತ್ತು ಆದ್ಯತೆಯ ಸ್ಥಿತಿಯಲ್ಲಿ ಇರಬೇಕು.
ನಂತರ ಮೊದಲ ಹಂತದ ಈವೆಂಟ್ ಪ್ರಶ್ನೆಯನ್ನು ಮತ್ತೆ ನಡೆಸಿ ಮತ್ತು ಅದು ಹೊಸದೇನನ್ನೂ ಹಿಂತಿರುಗಿಸುವುದಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿ. ಮರುಸಂಪರ್ಕದ ಉದ್ದಕ್ಕೂ ಶಾಂತ ಲಾಗ್ ಘರ್ಷಣೆ ಹೋಗಿದೆ ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷಿ, ಆದರೆ ಒಂದೇ ಸಂಪರ್ಕದ ನಂತರದ ಶಾಂತ ಲಾಗ್ ಎಂದರೆ ಸ್ಪರ್ಧೆ ಇನ್ನೂ ನಡೆದಿಲ್ಲ ಎಂದಷ್ಟೇ ಅರ್ಥ. ಕೊನೆಯದಾಗಿ, ಟನೆಲ್ ಇರುವ ಸಂಪನ್ಮೂಲವನ್ನು ಪರೀಕ್ಷಿಸಿ, ಏಕೆಂದರೆ ವಿಳಾಸ ಕಳೆದುಕೊಂಡ ಬ್ರಿಡ್ಜ್ VPN ಸ್ವತಃ ಆರೋಗ್ಯವಾಗಿ ಕಂಡರೂ ಮಾರಾಟಗಾರರ ಮಾರ್ಗವನ್ನು ಮುರಿಯಬಹುದು.
ಪೂಲ್ ಶ್ರೇಣಿ, ಪ್ರತಿ ಪಿನ್ ಮಾಡಿದ ವಿಳಾಸ ಮತ್ತು ಅದನ್ನು ಹೊಂದಿರುವ ಹೋಸ್ಟ್ ಅನ್ನು ಸರ್ವರ್ ಟಿಪ್ಪಣಿಗಳಲ್ಲಿ ದಾಖಲಿಸಿ. ಆಗ ಮುಂದಿನ ಢಿಕ್ಕಿಯನ್ನು ಗುರುತಿಸಲು ನಿಮಿಷಗಳು ಸಾಕು, ಮತ್ತೆ ಕಂಡುಹಿಡಿಯಲು ಇಡೀ ಮಧ್ಯಾಹ್ನ ಬೇಕಿಲ್ಲ.