DHCP ನವೀಕರಣದ ನಂತರ VPN ಕುಸಿಯುತ್ತದೆಯೇ? ವಿಳಾಸಗಳನ್ನು ಹೋಲಿಸಿ

ಲೀಜ್ ನವೀಕರಣ ಮತ್ತು VPN ವೈಫಲ್ಯ ಲಾಗ್‌ಗಳಲ್ಲಿ ಒಟ್ಟಿಗೆ ಸಾಕಷ್ಟು ಬಾರಿ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ, ಹಾಗಾಗಿ ಜನರು ಒಂದು ಇನ್ನೊಂದನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ ಎಂದು ತೀರ್ಮಾನಿಸುತ್ತಾರೆ. ಸಮಯದ ಹೊಂದಾಣಿಕೆ ನಿಜ; ಕಾರಣಸಂಬಂಧ ಸಾಮಾನ್ಯವಾಗಿ ಅಲ್ಲ. ನವೀಕರಣವು ಲೀಜ್ ನೀಡಿದ ಸರ್ವರ್‌ಗೆ ಕಳುಹಿಸುವ ಯುನಿಕಾಸ್ಟ್ ವಿನಂತಿ, ಅದೇ ಬೈಂಡಿಂಗ್ ಬಳಸುವುದನ್ನು ಮುಂದುವರಿಸಲು ಕೇಳುತ್ತದೆ, ಮತ್ತು ಕ್ಲೈಂಟ್ ಒಂದೂ ವಿಳಾಸ ಬದಲಿಸದೆ ಸರ್ವರ್ ಅದನ್ನು ವಿಸ್ತರಿಸಬಹುದು. ಘಟನೆಯ ಸುತ್ತ ಕ್ಲೈಂಟ್‌ನ ಸ್ವಂತ ಮೌಲ್ಯಗಳನ್ನು ಪರಿಶೀಲಿಸುವುದು ಮೌನವಾಗಿ ನವೀಕರಿಸಲಾದ ಲೀಜ್ ಅನ್ನು ಚಾಲನೆಯಲ್ಲಿರುವ ಸುರಂಗದ ಕೆಳಗೆ ನಿಜವಾಗಿ ಬದಲಾದ ನೆಟ್‌ವರ್ಕ್‌ನಿಂದ ಬೇರ್ಪಡಿಸುತ್ತದೆ.

ಕುಸಿದ ಕ್ಲೈಂಟ್‌ನಿಂದ ಪ್ರಾರಂಭಿಸಿ

ಮೊದಲು ಕ್ಲೈಂಟ್‌ನ ಸಂಪರ್ಕ ಲಾಗ್ ತೆರೆದು ಕುಸಿತದ ಸಮಯವನ್ನು ಸೆಕೆಂಡಿಗೆ ದಾಖಲಿಸಿ. ನಂತರ ಅದೇ ನಿಮಿಷಕ್ಕೆ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಂನ ನೆಟ್‌ವರ್ಕ್ ಲಾಗ್ ತೆರೆದು ಇಂಟರ್‌ಫೇಸ್ ಏನು ಮಾಡಿತು ಎಂಬುದನ್ನು ಕ್ರಮವಾಗಿ ಓದಿ. ಈ ಕ್ರಮವೇ ಇಡೀ ತನಿಖೆ: ಸಂಪರ್ಕ ಕಡಿತಕ್ಕೆ ಮೊದಲು DHCP ಘಟನೆ, DHCP ಘಟನೆಗೆ ಮೊದಲು ಸಂಪರ್ಕ ಕಡಿತ, ಮತ್ತು ನಡುವೆ ಏನೂ ಇಲ್ಲದ ಎರಡು ಘಟನೆಗಳು ಮೂರು ಬೇರೆ ಬೇರೆ ಕಂಡುಹಿಡಿಯುವಿಕೆಗಳು. ಸುರಂಗ ಈಗಾಗಲೇ ಮತ್ತೆ ಸಂಪರ್ಕ ಹೊಂದುತ್ತಿರುವಾಗ ಕೇವಲ ಲೀಜ್ ಅನ್ನು ಉಲ್ಲೇಖಿಸುವ ಲಾಗ್ ಸಾಲು ಅಲಂಕಾರ, ಸಾಕ್ಷ್ಯವಲ್ಲ.

ಸಮಯರೇಖೆಯನ್ನು ನೆನಪಿನಲ್ಲಿ ಇಟ್ಟುಕೊಳ್ಳುವ ಬದಲು ಮುಂದುವರಿಯುತ್ತಾ ಬರೆಯಿರಿ. ವಿವಿಧ ಉಪಕರಣಗಳ ಸಮಯಮುದ್ರೆಗಳು ಸಂಪೂರ್ಣವಾಗಿ ಹೊಂದಿಕೆಯಾಗುವುದು ಅಪರೂಪ, ಮತ್ತು ವ್ಯತ್ಯಾಸವೇ ಕೆಲವೊಮ್ಮೆ ವಿವರಣೆಯಾಗಿರುತ್ತದೆ.

ಘಟನೆಯ ಸುತ್ತ ನಾಲ್ಕು ಮೌಲ್ಯಗಳನ್ನು ಹೋಲಿಸಿ

ನಾಲ್ಕು ಮೌಲ್ಯಗಳು ಸಂಪರ್ಕದ ಸ್ಥಳೀಯ ಬದಿಯನ್ನು ನಿಜವಾದ ಬದಲಾವಣೆಯನ್ನು ಹಿಡಿಯಲು ಸಾಕಷ್ಟು ಚೆನ್ನಾಗಿ ವಿವರಿಸುತ್ತವೆ: ಇಂಟರ್‌ಫೇಸ್ ವಿಳಾಸ, ಡೀಫಾಲ್ಟ್ ಗೇಟ್‌ವೇ, ರೆಸಾಲ್ವರ್ ಪಟ್ಟಿ ಮತ್ತು ಇಂಟರ್‌ಫೇಸ್‌ನ ಕಾರ್ಯಾಚರಣೆ ಸ್ಥಿತಿ. ಕುಸಿತದ ನಂತರ ಒಂದು ನಿಮಿಷದೊಳಗೆ ಅವುಗಳನ್ನು ತೆಗೆದುಕೊಂಡು ಸುರಂಗ ಆರೋಗ್ಯಕರವಾಗಿದ್ದಾಗ ತೆಗೆದ ಕ್ಯಾಪ್ಚರ್‌ನೊಂದಿಗೆ ಹೋಲಿಸಿ.

ip -4 -brief addr show dev wlan0
ip -4 route show default
resolvectl status | grep -A3 'DNS Servers'
journalctl -u NetworkManager --since -10m --no-pager | grep -i dhcp

ಬದಲಾಗದ ವಿಳಾಸ, ಬದಲಾಗದ ಗೇಟ್‌ವೇ ಮತ್ತು ಬದಲಾದ ರೆಸಾಲ್ವರ್ ಪಟ್ಟಿ ಮಾರ್ಗನಿರ್ದೇಶನಕ್ಕಲ್ಲ, ಹೆಸರು ಪರಿಹಾರಕ್ಕೆ ಸೂಚಿಸುತ್ತದೆ, ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಹೋಸ್ಟ್‌ಗಳನ್ನು ಹುಡುಕುವುದನ್ನು ನಿಲ್ಲಿಸಿದಾಗ ಸುರಂಗ ಬದುಕಿರಬಹುದು. ಬದಲಾದ ಗೇಟ್‌ವೇ ಎಂದರೆ ಸ್ಥಳೀಯ ನೆಟ್‌ವರ್ಕ್‌ನಿಂದ ಹೊರಕ್ಕೆ ಹೋಗುವ ದಾರಿ ಸರಿದಿದೆ, ಮತ್ತು ಹಿಂದಿನದನ್ನು ಸೂಚಿಸಿದ ಮಾರ್ಗವನ್ನು ಅಮಾನ್ಯಗೊಳಿಸಲು ಅದು ಸಾಕು. ನಾಲ್ಕೂ ಮೌಲ್ಯಗಳು ಆರೋಗ್ಯಕರ ಕ್ಯಾಪ್ಚರ್‌ಗೆ ಹೊಂದಿಕೆಯಾದರೆ, ಲೀಜ್ ನಿಮ್ಮ ಕಾರಣವಲ್ಲ ಮತ್ತು ಕ್ಲೈಂಟ್‌ನ ಸ್ವಂತ ಮರುಸಂಪರ್ಕ ತರ್ಕವೇ ವಿಷಯವಾಗುತ್ತದೆ. ದೋಷ ಕಾಣುತ್ತಿರುವಾಗಲೇ ಹೋಲಿಕೆ ತೆಗೆದುಕೊಳ್ಳಿ, ಏಕೆಂದರೆ ಮರುಬೂಟ್ ನಂತರ ತೆಗೆದ ಆರೋಗ್ಯಕರ ಕ್ಯಾಪ್ಚರ್‌ಗೆ ಬೇರೆ ವಿಳಾಸ ಇತಿಹಾಸ ಇರುತ್ತದೆ ಮತ್ತು ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ.

ನವೀಕರಣ ಏನನ್ನು ಬದಲಿಸಬಹುದು ಮತ್ತು ಏನನ್ನು ಬದಲಿಸಲಾಗದು

RFC 2131 ನವೀಕರಣವನ್ನು ಲೀಜ್ ಸಮಯದ ಅರ್ಧದಲ್ಲಿ ಮೂಲ ಸರ್ವರ್‌ಗೆ ವಿನಂತಿಯಾಗಿ ವಿವರಿಸುತ್ತದೆ, ಮೊದಲ ಪ್ರಯತ್ನ ಉತ್ತರವಿಲ್ಲದೆ ಉಳಿದರೆ ಎಂಟರಲ್ಲಿ ಏಳು ಭಾಗದಲ್ಲಿ ಯಾವುದೇ ಸರ್ವರ್‌ಗೆ ಮರುಬೈಂಡಿಂಗ್ ಮಾಡುತ್ತದೆ. ಎರಡೂ ಹಂತಗಳು ಕ್ಲೈಂಟ್ ಬೇರೆ ವಿಳಾಸ ಪಡೆಯಬೇಕೆಂದು ಒತ್ತಾಯಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಸಹಕಾರಿ ಸರ್ವರ್ ಸಾಮಾನ್ಯವಾಗಿ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಬೈಂಡಿಂಗ್ ಅನ್ನು ವಿಸ್ತರಿಸುತ್ತದೆ. ನಿಜವಾದ ವಿಳಾಸ ಬದಲಾವಣೆ ಸಾಮಾನ್ಯವಾಗಿ ಬೇರೆ ದಾರಿಯಲ್ಲಿ ಬರುತ್ತದೆ: ಸರ್ವರ್ ನವೀಕರಣವನ್ನು ನಿರಾಕರಿಸುತ್ತದೆ, ಕ್ಲೈಂಟ್ ತನ್ನ ಸ್ಥಿತಿಯನ್ನು ಕಳೆದುಕೊಂಡು ಮತ್ತೆ ಪ್ರಾರಂಭಿಸುತ್ತದೆ, ಅಥವಾ ನೆಟ್‌ವರ್ಕ್ ಸಾಧನವನ್ನು ಬೇರೆ ವಿಭಾಗಕ್ಕೆ ಸರಿಸುತ್ತದೆ.

ಸಂಪರ್ಕದ ಸಾರ್ವಜನಿಕ ಬದಿ ಯಾವುದೇ ಸ್ಥಳೀಯ ಬದಲಾವಣೆ ಇಲ್ಲದೆಯೇ ಬದಲಾಗಬಹುದು. ಕ್ಯಾರಿಯರ್-ಗ್ರೇಡ್ ಅನುವಾದದ ಹಿಂದೆ, VPN ಸಹವರ್ತಿ ನೋಡುವ ವಿಳಾಸವನ್ನು ಸ್ಥಳೀಯ ಲೀಜ್ ಮಾಡಿದ ಯಾವುದಕ್ಕೂ ಸಂಬಂಧವಿಲ್ಲದೆ ಮರುಹಂಚಿಕೆ ಮಾಡಬಹುದು, ಮತ್ತು ಆ ಮರುಹಂಚಿಕೆ ಕ್ಲೈಂಟ್‌ನ ಒಳಗಿನಿಂದ ಸ್ಥಳೀಯ ನೆಟ್‌ವರ್ಕ್ ವೈಫಲ್ಯದಂತೆಯೇ ಕಾಣುತ್ತದೆ. ಸ್ಥಳೀಯವಾಗಿ ವರದಿ ಮಾಡಿದ ವಿಳಾಸವನ್ನು ಸಹವರ್ತಿಯ ಬದಿಯ ವೀಕ್ಷಣೆಯೊಂದಿಗೆ ಹೋಲಿಸುವುದೇ ಅವುಗಳನ್ನು ಬೇರ್ಪಡಿಸುವ ಏಕೈಕ ದಾರಿ.

ಕ್ಲೈಂಟ್ ಹೊಂದಿಕೊಳ್ಳಲು ವಿಫಲವಾದಾಗ

ತನ್ನ ಸಾಗಣೆಯನ್ನು ಹಳೆಯ ವಿಳಾಸಕ್ಕೆ ಬಂಧಿಸಿದ, ಸಹವರ್ತಿಗೆ ಹಳೆಯ ಮಾರ್ಗವನ್ನು ಕ್ಯಾಶ್ ಮಾಡಿದ ಅಥವಾ ಇಂಟರ್‌ಫೇಸ್ ಗುರುತನ್ನು ಉಳಿಸಿದ ಕ್ಲೈಂಟ್ ಇನ್ನು ಇಲ್ಲದ ದಾರಿಯನ್ನು ಮತ್ತೆ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಬಹುದು. ಅದು ಹೊಂದಾಣಿಕೆಯ ದೋಷ, ಮತ್ತು ಹೋಸ್ಟ್ ಇನ್ನು ತಲುಪಲಾಗದ ವಿಳಾಸದ ಕಡೆಗೆ ಪುನರಾವರ್ತಿತ ಮರುಪ್ರೇಷಣೆಗಳಾಗಿ ಕಾಣುತ್ತದೆ. ಕೆಲವು ಕ್ಲೈಂಟ್‌ಗಳು ಅದನ್ನು ವಿನ್ಯಾಸದಿಂದ ನಿಭಾಯಿಸುತ್ತವೆ: ಉದಾಹರಣೆಗೆ WireGuard ಸರಿಯಾಗಿ ದೃಢೀಕರಿಸಿದ ಪ್ಯಾಕೆಟ್ ಹೊಸ ಮೂಲದಿಂದ ಬಂದಾಗ ಸಹವರ್ತಿಯ ಅಂತ್ಯಬಿಂದುವನ್ನು ನವೀಕರಿಸುತ್ತದೆ.

ಸೇವೆಯನ್ನು ಮರಳಿಸುವ ಕೈಯಿಂದ ಮರುಪ್ರಾರಂಭ ಹೊಂದಾಣಿಕೆ ಎಲ್ಲಿ ವಿಫಲವಾಯಿತು ಎಂಬುದಕ್ಕೆ ಸುಳಿವು, ಲೀಜ್ ಮತ್ತು ಸುರಂಗಗಳು ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷ್ಯವಲ್ಲ. ಪರೀಕ್ಷೆಯ ಸಮಯದಲ್ಲಿ ನಿರ್ಬಂಧ ನೀತಿಯನ್ನು ಜಾರಿಯಲ್ಲಿಡಿ, ಇಲ್ಲದಿದ್ದರೆ ಪರೀಕ್ಷೆಯೇ ಬೇರೆ ಕಾರಣದ ಅಡಚಣೆಯಾಗುತ್ತದೆ. ಕ್ಲೈಂಟ್ ತಾನೇ ಚೇತರಿಸಿಕೊಂಡಿತೇ, ಎಷ್ಟು ಸಮಯ ತೆಗೆದುಕೊಂಡಿತು ಮತ್ತು ಯಾವ ವಿಳಾಸಕ್ಕೆ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಿತು ಎಂಬುದನ್ನು ದಾಖಲಿಸಿ; ಆ ಕ್ರಮ ಇಂಟರ್‌ಫೇಸ್‌ನಲ್ಲಿ ತೋರಿಸುವ ಸಂಪರ್ಕ ಕಡಿತದ ಕಾರಣಕ್ಕಿಂತ ಹೆಚ್ಚು ಹೇಳುತ್ತದೆ.

ದೂಷಿಸುವ ಮೊದಲು ಘಟನೆಯನ್ನು ಪುನರಾವರ್ತಿಸಿ

ವೇಳಾಪಟ್ಟಿಗಾಗಿ ಕಾಯುವ ಬದಲು ಸ್ಥಿತಿಯನ್ನು ಪುನರುತ್ಪಾದಿಸಿ: ಲೀಜ್ ಬಿಡುಗಡೆ ಮಾಡಿ ಮತ್ತೆ ನವೀಕರಿಸಿ, ಅಥವಾ ಸಮಾನ ನಿಯಂತ್ರಿತ ಘಟನೆಯನ್ನು ಒತ್ತಾಯಿಸಿ, ಮತ್ತು ಸುರಂಗ ಬದುಕುತ್ತದೆಯೇ ಎಂದು ಗಮನಿಸಿ. ನಿರ್ವಹಿತ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಯಾವುದೇ ವಿಳಾಸ ಬದಲಾವಣೆಯನ್ನು ನೆಟ್‌ವರ್ಕ್ ಮಾಲೀಕರೊಂದಿಗೆ ಸಮನ್ವಯಗೊಳಿಸಿ, ಏಕೆಂದರೆ ಅನಿಯಂತ್ರಿತ ಸ್ಥಿರ ಹಂಚಿಕೆ ಆ ವಿಳಾಸವನ್ನು ಈಗಾಗಲೇ ಹೊಂದಿರುವ ಸಾಧನದೊಂದಿಗೆ ಘರ್ಷಿಸಬಹುದು.

ಬೆಂಬಲಿತ ಸರಿಪಡಿಸುವಿಕೆಯ ನಂತರ ಅದೇ ಘಟನೆಯನ್ನು ಪುನರಾವರ್ತಿಸಿ, ನಂತರ ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ಹೆಸರು ಹುಡುಕಾಟವನ್ನು ಪರೀಕ್ಷಿಸಿ, ಏಕೆಂದರೆ ಮತ್ತೆ ಸಂಪರ್ಕಗೊಳ್ಳುವ ಆದರೆ DNS ಮುರಿಯುವ ಸುರಂಗವು ಮುಖ್ಯವಾದ ಪರೀಕ್ಷೆಗಿಂತ ದುರ್ಬಲ ಪರೀಕ್ಷೆಯಲ್ಲಿ ಉತ್ತೀರ್ಣವಾಗುತ್ತದೆ. ನಿಗದಿತ ಲೀಜ್ ಅನ್ನು ಕಾರಣ ಎಂದು ಹೆಸರಿಸುವ ಬದಲು ನೀವು ಗಮನಿಸಿದ ನಿರ್ದಿಷ್ಟ ಬದಲಾವಣೆಯನ್ನು ಅದರ ಸಮಯಮುದ್ರೆಯೊಂದಿಗೆ ವರದಿ ಮಾಡಿ. ಈ ಎರಡು ವರದಿಗಳ ನಡುವಿನ ವ್ಯತ್ಯಾಸ ಏನೆಂದರೆ ಮುಂದಿನ ವ್ಯಕ್ತಿ ದೋಷವನ್ನು ಪುನರುತ್ಪಾದಿಸಬಹುದೇ ಅಥವಾ ವದಂತಿಯನ್ನು ಮಾತ್ರ.