ISP ನ ಮರುಸಂಪರ್ಕ ಅಥವಾ ಮೇಲ್ಭಾಗದ ಅನುವಾದದಲ್ಲಿ ಬದಲಾವಣೆ VPN ಸೆಷನ್‌ನ ಸಾರ್ವಜನಿಕ ಮೂಲವನ್ನು ಬದಲಿಸುತ್ತದೆ, ಆದರೆ ಕ್ಲೈಂಟ್‌ನ ಸ್ಥಳೀಯ ಖಾಸಗಿ ವಿಳಾಸ ಸಾಮಾನ್ಯವಾಗಿ ಇದ್ದಂತೆಯೇ ಇರುತ್ತದೆ. ಆಗ ಸುರಂಗ ಸಂಪರ್ಕಗೊಂಡಂತೆ ಕಾಣುತ್ತದೆ, ಆದರೆ ಅದರ ಮೂಲಕ ಉಪಯುಕ್ತವಾದ ಯಾವುದೂ ಸಾಗುವುದಿಲ್ಲ. ಎರಡೂ ಅವಲೋಕನಗಳು ಒಂದೇ ಸಮಯದಲ್ಲಿ ನಿಜ, ಮತ್ತು ಅದೇ ವರದಿಯನ್ನು ಗೊಂದಲಮಯಗೊಳಿಸುತ್ತದೆ.

ನಾಲ್ಕು ಪರಿಶೀಲನೆಗಳನ್ನು ಕ್ರಮವಾಗಿ ಮಾಡಿ ಮತ್ತು ಮೊದಲು ವಿಫಲವಾದುದರಲ್ಲಿ ನಿಲ್ಲಿಸಿ.

ವಾಸ್ತವವಾಗಿ ಯಾವ ವಿಳಾಸ ಬದಲಾಯಿತು

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

ಹೊರಗಿನ ಮೂಲ ಬದಲಾಯಿತೇ, ಒಳಗಿನ ಸುರಂಗ ವಿಳಾಸ ಬದಲಾಯಿತೇ, ಅಥವಾ ಎರಡೂ ಎಂದು ನಿರ್ದಿಷ್ಟವಾಗಿ ಕೇಳಿ. ಮೊದಲನೆಯದು ಮಾತ್ರ ಇನ್ನು ಇಲ್ಲದ ಮಾರ್ಗಕ್ಕೆ ಕಳುಹಿಸುವುದನ್ನು ಮುಂದುವರಿಸುವ ಸಹಚರನನ್ನು ವಿವರಿಸುತ್ತದೆ.

ಸ್ಥಳಾಂತರವನ್ನು ಪ್ರೋಟೋಕಾಲ್ ನಿಭಾಯಿಸಲಿ

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

ನೀವು ಮಾಡಬಾರದ್ದು ಎಂದರೆ ದೃಢೀಕರಿಸದ ಸಂದೇಶವನ್ನು ಸಹಚರನ ಗುರುತು ಸರಿದಿದೆ ಎಂಬ ಸಾಕ್ಷ್ಯವಾಗಿ ಸ್ವೀಕರಿಸುವುದು. ಹೊಸ ವಿಳಾಸವನ್ನು ಹೇಳಿಕೊಳ್ಳುವ ಡೇಟಾಗ್ರಾಮ್ ಸುಳ್ಳು ಮಾಡುವುದು ಸುಲಭ, ಮತ್ತು ಕ್ಲೈಂಟ್ ತಾನು ದಾಳಿಕೋರನ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗೆ ತಿರುಗಿಸಬಹುದು ಎಂದು ನಂಬುತ್ತದೆ. ದೃಢೀಕೃತ ಪ್ರೋಟೋಕಾಲ್ ಮಾತ್ರ ಕಾರ್ಯವಿಧಾನ; ಅಧಿಸೂಚನೆ ಅಲ್ಲ.

wg show wg0 endpoints
wg show wg0 latest-handshakes
conntrack -L -p udp --dport 51820 | head -n 10

ಹಳೆಯ ಹೊರಗಿನ ಬಂಧವನ್ನು ಅಳಿಸಿ

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

ತನಿಖೆಯ ಸಮಯದಲ್ಲಿ ಅಗತ್ಯ ತಡೆ ಮುಂದುವರಿಯಲಿ. ಸುರಂಗ ಚೇತರಿಸಿಕೊಳ್ಳುತ್ತದೆಯೇ ಎಂದು ಪರೀಕ್ಷಿಸಲು ನೀತಿಯನ್ನು ಸಂಪೂರ್ಣ ತೆರೆಯುವುದು ಕಾರಣದ ಬಗ್ಗೆ ಏನನ್ನೂ ಕಲಿಸುವುದಿಲ್ಲ ಮತ್ತು ನಿಯೋಜನೆಯನ್ನು ನೀವು ಕಂಡದ್ದಕ್ಕಿಂತ ಕೆಟ್ಟದಾಗಿ ಬಿಡುತ್ತದೆ.

ಹೊಸ ವಿನಂತಿಯೊಂದಿಗೆ ಮತ್ತೆ ಪರೀಕ್ಷಿಸಿ

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

ನಂತರ ರೋಗನಿರ್ಣಯದ ಎರಡೂ ಭಾಗಗಳನ್ನು ದಾಖಲಿಸಿ: ಮೇಲ್ಭಾಗದಲ್ಲಿ ಏನು ಬದಲಾಯಿತು, ಮತ್ತು ಯಾವ ಬೆಂಬಲಿತ ಚೇತರಿಕೆ ಹಂತ ಹರಿವನ್ನು ಮರಳಿಸಿತು. ಮುಂದಿನ ಬಾರಿ ವೇಗವಾಗಿರುತ್ತದೆ, ಮತ್ತು ಟಿಪ್ಪಣಿಯೇ ಅದನ್ನು ವೇಗಗೊಳಿಸುತ್ತದೆ.

ಹೊಸ ವಿನಂತಿ ಯಶಸ್ವಿಯಾಗಿ ಹಳೆಯದು ಎಂದಿಗೂ ಮತ್ತೆ ಆರಂಭವಾಗದಿದ್ದರೆ, ಸುರಂಗ ಸರಿಪಡಿಸಲಾಗಿದೆ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತೆ ಸಂಪರ್ಕಿಸಬೇಕಷ್ಟೇ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು