ISP ಬದಲಿಸಿ, ಸೈಟ್ VPN ವಿಳಾಸಗಳನ್ನು ಮತ್ತೆ ಸಂಖ್ಯೆ ಮಾಡದೆ

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

ಸ್ವತಂತ್ರವಾಗಿ ಚಲಿಸುವ ಎರಡು ವಿಳಾಸ ಯೋಜನೆಗಳು

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

ಪೂರೈಕೆದಾರ ಬದಲಾವಣೆ ಹೊರಗಿನ ಯೋಜನೆಯನ್ನು ಮುಟ್ಟುತ್ತದೆ. ಅದು ತನ್ನಷ್ಟಕ್ಕೆ ಒಳಗಿನ ಯೋಜನೆ ಬದಲಾಗಬೇಕೆಂದು ಒತ್ತಾಯಿಸುವುದಿಲ್ಲ.

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

ಹೊರಗಿನ ಟನೆಲ್ ಒಳಗಿನ ಸಂಭಾಷಣೆಯನ್ನು ಹೊತ್ತೊಯ್ಯುತ್ತದೆ

ಗೇಟ್‌ವೇ-ಇಂದ-ಗೇಟ್‌ವೇ ಟನೆಲ್‌ನಲ್ಲಿ ಹೊರಗಿನ IP ಶೀರ್ಷಿಕೆ ಎರಡು ಗೇಟ್‌ವೇಗಳಿಗೆ ವಿಳಾಸ ನೀಡುತ್ತದೆ. ಒಳಗಿನ ಶೀರ್ಷಿಕೆ ಇನ್ನೂ ಅಪ್ಲಿಕೇಶನ್‌ನ ನಿಜವಾದ ಅಂತಿಮ ಬಿಂದುಗಳನ್ನು ಹೆಸರಿಸುತ್ತದೆ. RFC 7296ರ ಗೇಟ್‌ವೇ-ಇಂದ-ಗೇಟ್‌ವೇ ವಿವರಣೆ ಇದನ್ನು ಟನೆಲ್ ಅಂತಿಮ ಬಿಂದುಗಳ ಮೂಲಕ ಸಂಚಾರ ತಲುಪಿಸುವ ಸಾಮಾನ್ಯ ರೂಟಿಂಗ್ ಎಂದು ಪರಿಗಣಿಸುತ್ತದೆ.

ಅದಕ್ಕಾಗಿಯೇ ಗೇಟ್‌ವೇನ ಸಾರ್ವಜನಿಕ ವಿಳಾಸ ಬದಲಾದರೂ ಶಾಖೆ ಸರ್ವರ್ 10.55.8.20 ಉಳಿಸಿಕೊಳ್ಳಬಲ್ಲದು. ಒಳಗಿನ ಪ್ಯಾಕೆಟ್‌ನಲ್ಲಿ ಪೂರೈಕೆದಾರರ ವಿಳಾಸವೇ ಇರುವುದಿಲ್ಲ.

ಈ ವಿಭಜನೆ ವಿನ್ಯಾಸದ ಗುಣವೇ ಹೊರತು ಸ್ವಯಂಚಾಲಿತ ಖಾತರಿ ಅಲ್ಲ. ಬದಲಿ ಅಪ್ಲಿಂಕ್ ಬೆಂಬಲಿತ ಟನೆಲ್ ಸ್ಥಾಪಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ಅಥವಾ ಒಳಗಿನ ಮಾರ್ಗಗಳು ಮತ್ತೆ ಸ್ಥಾಪಿತವಾಗದಿದ್ದರೆ, ವಿಳಾಸ ಬದಲಾಗದಿದ್ದರೂ ಅಪ್ಲಿಕೇಶನ್ ತನ್ನ ಮಾರ್ಗವನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತದೆ.

ಪೂರೈಕೆದಾರ ಸರಿಸುವಿಕೆಗೆ ಇನ್ನೂ ಪರಿಶೀಲನಾ ಪಟ್ಟಿ ಇದೆ

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

ಅದರ ನಂತರ ಶಾಖೆ ಪ್ರಿಫಿಕ್ಸ್, ಎರಡೂ ದಿಕ್ಕುಗಳ ಮಾರ್ಗ, ಸಂರಕ್ಷಣಾ ನೀತಿ ಮತ್ತು ಒಂದು ನಿಜವಾದ ಅಪ್ಲಿಕೇಶನ್ ಹರಿವನ್ನು ಪರಿಶೀಲಿಸಿ. ಹೊಸದಾಗಿ ದೃಢೀಕೃತಗೊಂಡ ಟನೆಲ್ ಹಳೆಯ ಖಾಸಗಿ ಉಪಜಾಲಕ್ಕೆ ತೋರಿಸುವ ಮಾರ್ಗವನ್ನು ಸರಿಪಡಿಸುವುದಿಲ್ಲ.

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

ಉಳಿಯದಿರುವುದು: ಸಾರ್ವಜನಿಕ ಮೂಲ ಮತ್ತು ಅವಧಿಗಳು

ಸ್ಥಿರ ಖಾಸಗಿ ಸರ್ವರ್ ವಿಳಾಸ ಸ್ಥಿರ ಸಾರ್ವಜನಿಕ ಮೂಲವಲ್ಲ. ಬ್ರೌಸಿಂಗ್ ನೇರವಾಗಿ ಹೊಸ ಪೂರೈಕೆದಾರರ ಮೂಲಕ ಹೊರಹೋದರೆ, ವೆಬ್‌ಸೈಟ್‌ಗಳು ಹೊಸ ಪೂರೈಕೆದಾರ-ಮುಖಿ ವಿಳಾಸವನ್ನು ನೋಡುತ್ತವೆ.

ಆ ವಿಳಾಸವನ್ನು ಸ್ಥಿರವಾಗಿ ಇಡಲು ಸ್ವಂತ ಲಭ್ಯತೆ ಮತ್ತು ನೀತಿಯೊಂದಿಗೆ ಉದ್ದೇಶಪೂರ್ವಕ ನಿರ್ಗಮನ ವಿನ್ಯಾಸ ಬೇಕು. ಅದು ಟನೆಲ್‌ನೊಂದಿಗೆ ಉಚಿತವಾಗಿ ಬರುವುದಿಲ್ಲ.

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

ನಾಲ್ಕು ಪರಿಶೀಲನೆಗಳಿಂದ ಸರಿಸುವಿಕೆಯನ್ನು ಪರಿಶೀಲಿಸಿ

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

Linux ಗೇಟ್‌ವೇನಲ್ಲಿ, ಈ ಮೂರು ಆ ಪಟ್ಟಿಯ ಮಧ್ಯಭಾಗವನ್ನು ಆವರಿಸುತ್ತವೆ:

ip route get 10.55.8.20
ip xfrm policy list
curl -sS -o /dev/null -w "%{http_code}" --max-time 8 http://10.55.8.20/health

ಸಾಗಣೆ ವಿಳಾಸಗಳನ್ನು ಒಂದು ಪಟ್ಟಿಯಲ್ಲಿ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ವಿಳಾಸಗಳನ್ನು ಇನ್ನೊಂದರಲ್ಲಿ ಇಡಿ. ನಿಜವಾಗಿ ಸರಿದ ನಮೂದುಗಳನ್ನು ಮಾತ್ರ ನವೀಕರಿಸಿ. ಟನೆಲ್‌ನ ಹೊರಗಿನ ವಿಳಾಸ ಬದಲಾದ ಕಾರಣ ಒಳಗಿನ ಅವಲಂಬನೆಗಳನ್ನು ಮರುಸಂಖ್ಯೆ ಮಾಡುವುದು ತಪ್ಪಿಸಬಹುದಾದ ಕೆಲಸ.