VPN ಎಂಡ್‌ಪಾಯಿಂಟ್ ಹೆಸರು ಮತ್ತು ಖಾಸಗಿ ಸೇವೆಯ ಹೆಸರು: ಇಬ್ಬರು ಮಾಲೀಕರು

ಎರಡು ಹೆಸರುಗಳು ಒಂದೇ ಶಾಖೆಯನ್ನು ವಿವರಿಸಬಹುದು ಮತ್ತು ಸಂಪೂರ್ಣವಾಗಿ ಬೇರೆ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸಬಹುದು. vpn.branch.example ದೂರದ ಸಹಯೋಗಿಗೆ VPN ಎಂಡ್‌ಪಾಯಿಂಟ್ ಎಲ್ಲಿ ಸಿಗುತ್ತದೆ ಎಂದು ಹೇಳುತ್ತದೆ, ಮತ್ತು ಯಾವುದೇ ಸುರಂಗ ಇರುವ ಮೊದಲೇ ಅದು ಪರಿಹರಿಸಲ್ಪಡಬೇಕು. inventory.branch.example ಅಧಿಕೃತ ಬಳಕೆದಾರರಿಗೆ ಖಾಸಗಿ ಅಪ್ಲಿಕೇಶನ್ ಎಲ್ಲಿ ಇರುತ್ತದೆ ಎಂದು ಹೇಳುತ್ತದೆ, ಮತ್ತು ಸುರಂಗ ಮೇಲೇರಿದ ನಂತರವೇ ಅದು ಮುಖ್ಯ. ಒಂದನ್ನು ನಿರ್ವಹಿಸುವುದು ಇನ್ನೊಂದಕ್ಕೆ ಏನನ್ನೂ ಮಾಡುವುದಿಲ್ಲ.

ಯಾವುದನ್ನೂ ಡೀಬಗ್ ಮಾಡುವ ಮೊದಲು ಎರಡೂ ದಾಖಲೆಗಳಿಗೆ ಹೆಸರಿಸಿ

ಎರಡನ್ನೂ ಅವುಗಳ ಮಾಲೀಕರೊಂದಿಗೆ ಬರೆಯಿರಿ. ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಾಗಿ ಸಾರ್ವಜನಿಕ ವಿಳಾಸವನ್ನು ಯಾರು ನವೀಕರಿಸುತ್ತಾರೆ ಮತ್ತು VPN ಕ್ಲೈಂಟ್ ತನ್ನ ಉತ್ತರವನ್ನು ಹೇಗೆ ರಿಫ್ರೆಶ್ ಮಾಡುತ್ತದೆ ಎಂದು ದಾಖಲಿಸಿ. ಸೇವೆಗಾಗಿ ಖಾಸಗಿ ವಿಳಾಸದ ಮಾಲೀಕರು ಯಾರು, ಯಾವ ವಲಯವು ದಾಖಲೆಯನ್ನು ಹಿಡಿದಿದೆ ಮತ್ತು ಯಾವ ರಿಝಾಲ್ವರ್‌ಗಳು ಅದಕ್ಕೆ ಉತ್ತರಿಸಬೇಕು ಎಂದು ದಾಖಲಿಸಿ.

ಈ ಸಣ್ಣ ಪಟ್ಟಿ ಈ ಕ್ಷೇತ್ರದ ಅತ್ಯಂತ ಸಾಮಾನ್ಯ ತಪ್ಪು ನಿದಾನವನ್ನು ತಡೆಯುತ್ತದೆ: ಸಂಪೂರ್ಣವಾಗಿ ತನ್ನೊಳಗೇ ಇರುವ ದಾಖಲೆಯನ್ನು ಸರಿಪಡಿಸಲು ಕೆಲಸ ಮಾಡುತ್ತಿರುವ ಶಾಖಾ ಸುರಂಗವನ್ನು ಮರುಪ್ರಾರಂಭಿಸುವುದು. ಸುರಂಗವು ಸೇವೆಯ ಹೆಸರಿನ ಸಾಗಣೆ; ಅದು ಅದರ ಅಧಿಕಾರವಲ್ಲ.

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

ಯಾವುದೇ ಸುರಂಗ ಇರುವ ಮೊದಲೇ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಪರಿಹರಿಸಲ್ಪಡಬೇಕು

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

ಈ ಆರಂಭಿಕ ಅವಲಂಬನೆಯನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳುವುದು ಯೋಗ್ಯ, ಏಕೆಂದರೆ ಎಲ್ಲಾ ಆಂತರಿಕ ರಿಝಾಲ್ವರ್‌ಗಳು VPN ಹಿಂದೆ ಇದ್ದಾಗ ಅದನ್ನು ಆಕಸ್ಮಿಕವಾಗಿ ರಚಿಸುವುದು ಸುಲಭ. ಎಂಡ್‌ಪಾಯಿಂಟ್ ಹುಡುಕಾಟಕ್ಕಾಗಿ ಸುರಂಗದ ಮೊದಲಿನ ಮಾರ್ಗವನ್ನು ಇಟ್ಟುಕೊಳ್ಳಿ, ಮತ್ತು ಹೊಸ ಉತ್ತರ ತಕ್ಷಣ ಸ್ವೀಕರಿಸಲ್ಪಡುತ್ತದೆ ಎಂದು ಊಹಿಸುವ ಬದಲು ಕ್ಲೈಂಟ್‌ನ ಮರುಸಂಪರ್ಕ ನಡವಳಿಕೆಯನ್ನು ದೃಢೀಕರಿಸಿ.

ಕ್ರಿಯಾತ್ಮಕ DNS ಗೂ ದಾಖಲೆ ನವೀಕರಣವು ದಾಟಲಾಗದ ಮಿತಿಗಳಿವೆ. ದಾಖಲೆಯನ್ನು ನವೀಕರಿಸುವುದು ಯಾವುದೇ ಫೈರ್‌ವಾಲ್ ಪೋರ್ಟ್ ತೆರೆಯುವುದಿಲ್ಲ, NAT ಮ್ಯಾಪಿಂಗ್ ರಚಿಸುವುದಿಲ್ಲ ಮತ್ತು ಸಹಯೋಗಿಯ ಗುರುತನ್ನು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ಮುಚ್ಚಿದ ಪೋರ್ಟ್‌ನೊಂದಿಗೆ ಪ್ರಕಟಿಸಿದ ವಿಳಾಸವು ಸರಿಯಾಗಿ ಪರಿಹರಿಸುವ ಮತ್ತು ಆದರೂ ಯಾವುದಕ್ಕೂ ಸಂಪರ್ಕಿಸಲಾಗದ ಕ್ಲೈಂಟ್ ನೀಡುತ್ತದೆ.

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

ಸೇವೆಯ ಹೆಸರು ಅಪ್ಲಿಕೇಶನ್ ಎಲ್ಲಿ ಇರುತ್ತದೆ ಎಂದು ವಿವರಿಸುತ್ತದೆ

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

ಇಲ್ಲಿ ಎರಡು ನವೀಕರಣ ವಿಧಾನಗಳು ಬೆರೆತುಹೋಗುತ್ತವೆ. RFC 2136 ವಲಯದಲ್ಲಿ DNS ದಾಖಲೆಗಳನ್ನು ಸೇರಿಸುವ ಮತ್ತು ಅಳಿಸುವ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ, ಆದರೆ ವಾಣಿಜ್ಯ ಕ್ರಿಯಾತ್ಮಕ DNS ಪೂರೈಕೆದಾರರು ಬೇರೆ ಉದ್ದೇಶಕ್ಕಾಗಿ ಸಂಪೂರ್ಣವಾಗಿ ಬೇರೆ HTTP API ಒದಗಿಸಬಹುದು. ಒಂದನ್ನು ಬಳಸುವುದು ಇನ್ನೊಂದು ನಿಮ್ಮ ಪರಿಸರದಲ್ಲಿದೆ ಎಂದು ಅರ್ಥವಲ್ಲ. ಅದರ ವಿರುದ್ಧ ನವೀಕರಣಕಾರನನ್ನು ಬರೆಯುವ ಮೊದಲು ನಿಮ್ಮ ವಲಯವು ನಿಜವಾಗಿ ಯಾವ ವಿಧಾನವನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ.

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

ಎರಡು ಮಾರ್ಗಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರೀಕ್ಷಿಸಿ

ಸುರಂಗದ ಹೊರಗಿನಿಂದ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಮತ್ತು ಒಳಗಿನಿಂದ ಸೇವೆಯನ್ನು ಪರಿಶೀಲಿಸಿ, ಫಲಿತಾಂಶಗಳನ್ನು ಎರಡು ಸ್ವತಂತ್ರ ಸತ್ಯಗಳಾಗಿ ಇರಿಸಿ:

$ dig +short vpn.branch.example @1.1.1.1
$ dig +short inventory.branch.example @172.26.0.53
$ ip route get 172.26.14.35

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

ಪ್ರತಿ ವಿಳಾಸ ಬದಲಾವಣೆಯ ನಂತರ ಜೋಡಿಯನ್ನು ಚಲಾಯಿಸಿ ಮತ್ತು ಯಾವ ದಾಖಲೆ ಸರಿದಿದೆ ಎಂದು ಗಮನಿಸಿ. «DNS ನವೀಕರಿಸಲಾಗಿದೆ» ಎಂದು ಮಾತ್ರ ಹೇಳುವ ಹಸ್ತಾಂತರವು ಎರಡು ಜೀವನ ಚಕ್ರಗಳಲ್ಲಿ ಯಾವುದು ನಿಜವಾಗಿ ನಡೆಯಿತು ಎಂದು ಮುಂದಿನ ಎಂಜಿನಿಯರ್‌ಗೆ ಊಹಿಸಲು ಬಿಡುತ್ತದೆ.