ನೆಟ್ವರ್ಕ್ ಬದಲಾದಾಗ MOBIKE IKEv2 VPN ಅನ್ನು ಹೇಗೆ ಜೀವಂತವಾಗಿ ಇಡುತ್ತದೆ

ಒಂದು ಫೋನ್ Wi-Fi ಬಿಟ್ಟು ಸೆಲ್ಯುಲರ್ ನೆಟ್ವರ್ಕ್ಗೆ ಸೇರುತ್ತದೆ, ಲ್ಯಾಪ್ಟಾಪ್ Ethernet ನಿಂದ ಹಾಟ್ಸ್ಪಾಟ್ಗೆ ಹೋಗುತ್ತದೆ, ಮತ್ತು IKEv2 ಸುರಂಗ ಉಳಿಯುತ್ತದೆ ಅಥವಾ ಇಲ್ಲ। MOBIKE ಎಂಬುದು ಅದನ್ನು ಉಳಿಸುವ ವಿಸ್ತರಣೆಯಾಗಿದೆ, ಆರಂಭದಿಂದ ಮತ್ತೆ ಪ್ರಾರಂಭಿಸುವ ಬದಲು ಮೂಲ ವಿಳಾಸ ಬದಲಾಗಿದೆ ಎಂದು ದೂರದ ತುದಿಗೆ ತಿಳಿಸುತ್ತದೆ। ಅದು ಮಾಡದಿರುವುದು ಬದಲಾವಣೆಯ ಉದ್ದಕ್ಕೂ ಪ್ರತಿ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಜೀವಂತವಾಗಿ ಇಡುವುದು। ಇವು ಎರಡು ಹೇಳಿಕೆಗಳು, ಮತ್ತು ಎರಡನೆಯದೇ ಜನರು ಸಾಮಾನ್ಯವಾಗಿ ಅರ್ಥೈಸುವುದು।

ಪರಿವರ್ತನೆಯನ್ನು ಹಂತಗಳಲ್ಲಿ ನೋಡಿ, ಏಕೆಂದರೆ ಪ್ರತಿ ಹಂತ ವಿಭಿನ್ನವಾಗಿ ವಿಫಲವಾಗುತ್ತದೆ।

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

ಭದ್ರತಾ ಸಂಬಂಧ ಇನ್ನೂ ಮಾನ್ಯವಾಗಿರುವಾಗ, ಪ್ರಾರಂಭಿಸುವವನು ತನ್ನ ಹೊಸ ವಿಳಾಸವನ್ನು ತಿಳಿದು ಪ್ರತಿಸ್ಪಂದಕನಿಗೆ ನವೀಕರಣ ಕಳುಹಿಸುತ್ತಾನೆ, ಅವನು ನಂತರ ಅದೇ ಸಂಬಂಧಕ್ಕೆ ಆ ವಿಳಾಸವನ್ನು ಬಳಸುತ್ತಾನೆ। ಭದ್ರತಾ ನಿಯತಾಂಕಗಳು ಶೂನ್ಯದಿಂದ ಮತ್ತೆ ಚರ್ಚಿಸಲ್ಪಡುವುದಿಲ್ಲ। ಇದೇ ಇಡೀ ಪ್ರಯೋಜನ: ಹೊಸ ದೃಢೀಕರಣ ಸುತ್ತು ಇಲ್ಲ, ಹೊಸ ಕೀಲಿ ವಿನಿಮಯ ಇಲ್ಲ, ಬಳಕೆದಾರರಿಗೆ ಯಾವುದೇ ವಿನಂತಿ ಇಲ್ಲ। ಇದರ ಅರ್ಥ ಉಳಿದ ಸ್ಥಿತಿ ಇನ್ನೂ ಹಳೆಯ ಅವಧಿಗೆ ಸೇರಿದೆ ಎಂದೂ।

MOBIKE ಸಂಚಾರವನ್ನು UDP ಸುತ್ತುವಿಕೆಗೂ ಸಾಗಿಸಬಹುದು, ಆದ್ದರಿಂದ ಕೆಲಸ ಮಾಡುವ ಸುರಂಗ ಕೆಲವೊಮ್ಮೆ ನೆಟ್ವರ್ಕ್ ಬದಲಾವಣೆಯ ನಂತರ 4500 ಪೋರ್ಟ್ ಬಳಸಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ। ಆ ಪರಿವರ್ತನೆ ತಾನಾಗಿಯೇ NAT ಪತ್ತೆಯಾಯಿತು ಎಂದು ಸಾಬೀತು ಮಾಡುವುದಿಲ್ಲ, ಆದರೂ ಎರಡೂ ಹೆಚ್ಚಾಗಿ ಒಟ್ಟಿಗೆ ಕಾಣಿಸುತ್ತವೆ।

ನಿಮ್ಮ ಪ್ರೊಫೈಲ್ ನಿಜವಾಗಿಯೂ ಅದನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುತ್ತದೆಯೇ

ಎರಡೂ ಕಡೆಗಳು ವಿಸ್ತರಣೆಯನ್ನು ಬೆಂಬಲಿಸಬೇಕು, ಮತ್ತು ನಿಯೋಜನೆ ಅದನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಬೇಕು। strongSwan ನಲ್ಲಿ ನಡವಳಿಕೆ ಪ್ರತಿ ಸಂಪರ್ಕಕ್ಕೂ ಸಂರಚಿಸಬಹುದು, ಮತ್ತು ಇಂಟರ್ಫೇಸ್ ಅಥವಾ ಮಾರ್ಗ ಬದಲಾವಣೆಗಳು ಅಗತ್ಯವಿದ್ದಾಗ ಮಾರ್ಗ ಹುಡುಕಾಟ ಮತ್ತು ನವೀಕರಣವನ್ನು ಪ್ರಾರಂಭಿಸಬಹುದು। ಪ್ರತಿ IKEv2 ಪ್ರೊಫೈಲ್ ಅದನ್ನು ಆನ್ ಮಾಡುತ್ತದೆ ಎಂದು ಊಹಿಸುವ ಬದಲು ಸಂಪರ್ಕದ ನಿಜವಾದ ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ। ಈ ವೈಶಿಷ್ಟ್ಯಕ್ಕಿಂತ ಹಳೆಯ ಮಾರ್ಗದರ್ಶಿಯಿಂದ ನಕಲಿಸಿದ ಪ್ರೊಫೈಲ್ ಇದಕ್ಕೆ ಸಾಮಾನ್ಯ ಕಾರಣ।

ಎರಡೂ ತುದಿಗಳಲ್ಲಿ ಚರ್ಚಿಸಿದ ಸ್ಥಿತಿಯೇ ಅಧಿಕಾರ, ಉತ್ಪನ್ನ ಕುಟುಂಬದ ದಾಖಲೆ ಅಲ್ಲ।

ಪರಿವರ್ತನೆಯನ್ನು ಹಂತಗಳಲ್ಲಿ ನೋಡಿ

ನೆಟ್ವರ್ಕ್ ಬದಲಿಸುವ ಮೊದಲು ಅಪ್ಲಿಕೇಶನ್ ಸ್ಥಿತಿಯನ್ನು ದಾಖಲಿಸಿ। ನಂತರ ಬದಲಿಸಿ, ಮತ್ತು ನಂತರ ಕ್ಲೈಂಟ್ ಹಾಗೂ ಸರ್ವರ್ ಸ್ಥಿತಿಯನ್ನು ದಾಖಲಿಸಿ। ಕಳೆದುಹೋದ ವಿಳಾಸ, ತಲುಪಲಾಗದ ಸಹಚರ ಮತ್ತು ತನ್ನ ಅವಧಿಯನ್ನು ಮತ್ತೆ ಸಂಪರ್ಕಿಸಬೇಕಾದ ಅಪ್ಲಿಕೇಶನ್—ಇವು ಮೂರು ವಿಭಿನ್ನ ಫಲಿತಾಂಶಗಳು। ಮೊದಲ ಎರಡು ಮಾತ್ರ VPN ಪದರಕ್ಕೆ ಸೇರಿವೆ; ಮೂರನೆಯದು ಅಪ್ಲಿಕೇಶನ್ ಮಾತನಾಡುವ ಪ್ರೋಟೋಕಾಲ್ಗೆ ಸೇರಿದೆ।

ನೆಟ್ವರ್ಕ್ ಬದಲಾವಣೆಯನ್ನು ಸ್ಥಿರ ಪರೀಕ್ಷೆಯೊಂದಿಗೆ ಹೋಲಿಸಿ, ಯಾವ ಘಟನೆ ಸಮಸ್ಯೆಯನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ ಎಂದು ತಿಳಿಯಲು। ಅಂತಿಮ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಥ್ರೂಪುಟ್ ಮಾಪನವು ಪರಿವರ್ತನೆಯನ್ನು ಮರುಸೃಷ್ಟಿಸಲಾರದು। ಅದು ಗಮ್ಯಸ್ಥಾನವನ್ನು ಅಳೆಯುತ್ತದೆ, ಪ್ರಯಾಣವನ್ನಲ್ಲ।

ವಿಫಲತೆಯ ಪದರಗಳನ್ನು ಬೇರ್ಪಡಿಸಿ

ದೀರ್ಘಕಾಲದ TCP ಅವಧಿ IKEv2 ವಿನಿಮಯದ ಹೊರಗಿನ ಕಾರಣಗಳಿಂದ ವಿಫಲವಾಗಬಹುದು। ಹೊಸ ನೆಟ್ವರ್ಕ್ ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಫಿಲ್ಟರ್, ಪರಿಹರಿಸು ಅಥವಾ ಮಾರ್ಗ ಮಾಡಬಹುದು। ಕೆಳಗಿನ ಮಾರ್ಗ ಬದಲಾದಾಗ ಸುರಂಗದ ವಿಳಾಸ ಸ್ವಲ್ಪವೂ ಬದಲಾಗದೇ ಇರಬಹುದು। ಆದ್ದರಿಂದ ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತೆ ಸಂಪರ್ಕಿಸುವುದು VPN ಎಂದೂ ಮುರಿಯದ್ದನ್ನು ಸರಿಪಡಿಸಬಹುದು।

ಚೇತರಿಸಿಕೊಳ್ಳುವಾಗಲೂ ತಡೆ ನೀತಿಯನ್ನು ಜಾಗದಲ್ಲಿರಿಸಿ।

ಸ್ವಯಂಚಾಲಿತ ಚಲನಶೀಲತೆ ಮತ್ತು ನೇರ ಸಂಚಾರವನ್ನು ತಡೆಯುವ ನಿಯಮ ಬೇರೆ ಬೇರೆ ನಿಯಂತ್ರಣಗಳು, ಮತ್ತು ಮೊದಲನೆಯದು ಕೆಲಸ ಮಾಡಲು ಎರಡನೆಯದನ್ನು ಆಫ್ ಮಾಡುವುದು ಕೆಟ್ಟ ವ್ಯಾಪಾರ। ಚಲನಶೀಲತೆ ನವೀಕರಣ ವಿಫಲವಾದರೆ, ಸುರಂಗದ ಸುತ್ತ ಸಂಚಾರ ಸೋರಿಕೆಯಾಗಲು ಬಿಡುವ ಬದಲು ತಡೆ ಉಳಿಯಬೇಕು।

ಇದು ಪುನರಾವರ್ತನೆಯಾದಾಗ ಏನನ್ನು ದಾಖಲಿಸಬೇಕು

ಎರಡೂ ಕಡೆಗಳಿಂದ ಸಮಯಮುದ್ರೆಗಳು ಮತ್ತು ಎರಡೂ ವಿಳಾಸ ಮೌಲ್ಯಗಳನ್ನು ಇರಿಸಿಕೊಳ್ಳಿ। ಆ ದಾಖಲೆ ಅಪ್ಲಿಕೇಶನ್ ಸಂಪರ್ಕ ಕಳೆದುಕೊಳ್ಳುವ ಮೊದಲು ನವೀಕರಣ ಪೂರ್ಣಗೊಂಡಿತೇ ಎಂದು ತೋರಿಸುತ್ತದೆ, ಅದೇ ಚಲನಶೀಲತೆ ದೋಷ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಸಮಯ ಮೀರಿಕೆ ನಡುವಿನ ವ್ಯತ್ಯಾಸ। ನಂತರ ಬದಲಾವಣೆಯ ದಿಕ್ಕನ್ನು ಹೋಲಿಸಿ: Wi-Fi ಬಿಟ್ಟು ಸೆಲ್ಯುಲರ್ಗೆ ಹೋಗುವುದು ವಿರುದ್ಧ ದಿಕ್ಕಿಗೆ ಸಮ್ಮಿತೀಯವಲ್ಲ। ಒಂದು ದಿಕ್ಕು ಕೆಲಸ ಮಾಡಬಹುದು, ಇನ್ನೊಂದು ವಿಫಲವಾಗುತ್ತದೆ।

ಈ ಅಸಮ್ಮಿತಿ ಮೊದಲು ಪರೀಕ್ಷಿಸಬೇಕಾದ ವಿಷಯವಾಗುವಷ್ಟು ಸಾಮಾನ್ಯವಾಗಿದೆ।

ದಾಖಲೆ ಕೈಯಲ್ಲಿದ್ದಾಗ, ಘಟನೆ ಇನ್ನೊಂದು ಸಂಪರ್ಕ ಕಡಿತಗೊಂಡ ಐಕಾನ್ ಆಗುವುದನ್ನು ನಿಲ್ಲಿಸಿ ತಿಳಿದ ಮಾಲೀಕರಿರುವ ಅನುಕ್ರಮದಲ್ಲಿ ಒಂದು ಘಟನೆಯಾಗುತ್ತದೆ। ಮತ್ತು ಸುತ್ತೋಟವು ಪ್ರಾಮಾಣಿಕವಾಗಿ ಭರವಸೆ ನೀಡಬಹುದಾದದ್ದು ಅಷ್ಟೇ।