ಎರಡು VPN, ಒಂದು ರಿಝಾಲ್ವರ್: ಕೊನೆಯಲ್ಲಿ ಬರೆದವನೇ ಗೆಲ್ಲುತ್ತಾನೆ
ಎರಡೂ ಕ್ಲೈಂಟ್‌ಗಳು DNS ನೀತಿಯನ್ನು ಸ್ಥಾಪಿಸಬಹುದು, ಮತ್ತು ಕೊನೆಯ ಬರಹಗಾರ ಗೆಲ್ಲಬಹುದು. ಸಫಿಕ್ಸ್‌ಗಳನ್ನು ರಿಝಾಲ್ವರ್‌ಗಳಿಗೆ ಮ್ಯಾಪ್ ಮಾಡಿ ಮತ್ತು ಟನೆಲ್‌ಗಳ ಹೊರಗೆ ಬೂಟ್‌ಸ್ಟ್ರಾಪ್ ಮಾರ್ಗವನ್ನು ಇರಿಸಿ.
ಎರಡು VPN ಕ್ಲೈಂಟ್‌ಗಳು ಸಂಪರ್ಕಗೊಂಡಿವೆ, ಒಂದು ಕೆಲಸಕ್ಕೆ ಮತ್ತು ಒಂದು ಲ್ಯಾಬ್ ನೆಟ್‌ವರ್ಕ್‌ಗೆ, ಮತ್ತು ಆಂತರಿಕ ಹೆಸರುಗಳು ಕೊನೆಯಲ್ಲಿ ಸಂಪರ್ಕಗೊಂಡ ಕ್ಲೈಂಟ್‌ಗೆ ಮಾತ್ರ ಪರಿಹರಿಸಲ್ಪಡುತ್ತವೆ. ಈ ಮಾದರಿ ಒಂದು ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ ದೋಷದಂತೆ ಕಾಣುತ್ತದೆ. ಸಾಮಾನ್ಯವಾಗಿ ಇದು ಯಾವ ಹೆಸರು ಯಾರಿಗೆ ಸೇರಿದೆ ಎಂಬ ಒಪ್ಪಂದವಿಲ್ಲದೆ ಒಂದೇ ರಿಝಾಲ್ವರ್ ಸಂರಚನೆಯನ್ನು ಬರೆಯುವ ಎರಡು ಪ್ರೋಗ್ರಾಮ್‌ಗಳ ಊಹಿಸಬಹುದಾದ ಫಲಿತಾಂಶವಾಗಿದೆ.
ಪುರಾಣ: ಹೊಸ VPN ಗೆ DNS ಸೇರಿದೆ
ಇತ್ತೀಚಿನ ಸಂಪರ್ಕ ಗೆಲ್ಲುತ್ತದೆ ಎಂಬ ಸಾಮಾನ್ಯ ನಿಯಮವಿಲ್ಲ. ಏನಾಗುತ್ತದೆ ಎಂಬುದು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಕಾರ್ಯವಿಧಾನ ಮತ್ತು ಪ್ರತಿ ಕ್ಲೈಂಟ್ ಅದನ್ನು ಹೇಗೆ ಬರೆಯುತ್ತದೆ ಎಂಬುದರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ. ರಿಝಾಲ್ವರ್ ಫೈಲ್ ಅನ್ನು ಬದಲಿಸುವ ಕ್ಲೈಂಟ್ ಒಂದು ಫಲಿತಾಂಶ ನೀಡುತ್ತದೆ; ಪ್ರತಿ ಲಿಂಕ್‌ಗೆ ಡೊಮೇನ್ ಸೇರಿಸುವ ಕ್ಲೈಂಟ್ ಇನ್ನೊಂದು ನೀಡುತ್ತದೆ; ಏನೂ ಮಾಡದ ಕ್ಲೈಂಟ್ ಹಿಂದಿನ ಸ್ಥಿತಿಯನ್ನು ಅಸ್ಪೃಶವಾಗಿ ಬಿಡುತ್ತದೆ.
ಆದ್ದರಿಂದ ಕಂಡುಬರುವ ವರ್ತನೆ ಎರಡು ಅನುಷ್ಠಾನಗಳ ಗುಣಲಕ್ಷಣ, ದಾಖಲಾದ ಆದ್ಯತೆ ಅಲ್ಲ. ಕೇವಲ ಪ್ರಾರಂಭ ಕ್ರಮದಿಂದ ತರ್ಕಿಸುವುದು ಕೆಲವೊಮ್ಮೆ ಸರಿಯಾಗಿರುತ್ತದೆ ಮತ್ತು ಕೆಲವೊಮ್ಮೆ ಪುನರುತ್ಪಾದಿಸಲು ಕಷ್ಟವಾದ ರೀತಿಯಲ್ಲಿ ತಪ್ಪಾಗುತ್ತದೆ. ಬದಲಾಗಿ ಮ್ಯಾಪಿಂಗ್ ಬರೆಯಿರಿ. ಎರಡು ಕ್ಲೈಂಟ್‌ಗಳಲ್ಲಿ ಬದುಕುವ ವಿನ್ಯಾಸ ವಿನ್ಯಾಸವಲ್ಲ.
ಹೆಸರಿನ ಸ್ಥಳಗಳನ್ನು ರಿಝಾಲ್ವರ್‌ಗಳಿಗೆ ಮ್ಯಾಪ್ ಮಾಡಿ
ಖಾಸಗಿ ಸಫಿಕ್ಸ್‌ಗಳನ್ನು ಮತ್ತು ಪ್ರತಿ ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಬೇಕಾದ ರಿಝಾಲ್ವರ್ ಅನ್ನು ಪಟ್ಟಿ ಮಾಡಿ, ನಂತರ ಸಾರ್ವಜನಿಕ ಹೆಸರುಗಳು ಎಲ್ಲಿಗೆ ಹೋಗಬೇಕು ಎಂದು ನಿರ್ಧರಿಸಿ. ಆ ಪಟ್ಟಿಯೇ ವಿನ್ಯಾಸ. ಅದಿಲ್ಲದೆ, ಕ್ಲೈಂಟ್‌ಗಳು ಆಕಸ್ಮಿಕವಾಗಿ ನಿರ್ಧಾರ ತೆಗೆದುಕೊಳ್ಳುತ್ತವೆ.
ಪ್ರತಿ ಲಿಂಕ್‌ಗೆ DNS ಅಥವಾ ರೂಟಿಂಗ್ ಡೊಮೇನ್‌ಗಳನ್ನು ಬೆಂಬಲಿಸುವ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ವಿಭಜನೆಯನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ವ್ಯಕ್ತಪಡಿಸಬಹುದು: ಒಂದು ಡೊಮೇನ್ ಒಂದು ಲಿಂಕ್‌ಗೆ ಹೋಗುತ್ತದೆ, ಇನ್ನೊಂದು ಡೊಮೇನ್ ಇನ್ನೊಂದಕ್ಕೆ, ಮತ್ತು ಉಳಿದೆಲ್ಲವೂ ಸ್ಪಷ್ಟ ಡೀಫಾಲ್ಟ್ ಅನ್ನು ಅನುಸರಿಸುತ್ತದೆ. ಒಂದೇ ಫೈಲ್ ಅನ್ನು ಮತ್ತೆ ಬರೆಯುವ ಎರಡು ಸಮತಟ್ಟು ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು ಆ ವಿನ್ಯಾಸವನ್ನು ಉಳಿಸಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಿಲ್ಲ, ಏಕೆಂದರೆ ಪ್ರತಿಯೊಂದೂ ಇಡೀ ಸಂರಚನೆ ತನ್ನದೇ ಎಂದು ನಂಬುತ್ತದೆ.
Windows ನಲ್ಲಿ, ಹೆಸರು ಪರಿಹಾರ ನೀತಿ ಕೋಷ್ಟಕವು ಸಫಿಕ್ಸ್‌ಗಳನ್ನು ನಿರ್ದಿಷ್ಟ ಸರ್ವರ್‌ಗಳಿಗೆ ನಿರ್ದೇಶಿಸಬಹುದು, ಮತ್ತು VPN ಕ್ಲೈಂಟ್ ಅಲ್ಲಿ ನಿಯಮಗಳನ್ನು ಸ್ಥಾಪಿಸಬಹುದು. ಅಡಾಪ್ಟರ್ ಪಟ್ಟಿಯ ಬದಲು ನೀತಿಯನ್ನು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಹೆಸರನ್ನು ಅಡಾಪ್ಟರ್ ಪಟ್ಟಿ ಪರಿಹರಿಸುವುದಿಲ್ಲ.
ಬೂಟ್‌ಸ್ಟ್ರಾಪ್ ಮಾರ್ಗವನ್ನು ಇರಿಸಿ
ಪ್ರತಿ ಕ್ಲೈಂಟ್ ತನ್ನ ಸ್ವಂತ ಅಂತ್ಯಬಿಂದುವನ್ನು ಹುಡುಕಬೇಕು, ಆಗ ಮಾತ್ರ ಆ ಅಂತ್ಯಬಿಂದು ಒದಗಿಸುವ ಸೇವೆಯನ್ನು ಬಳಸಬಹುದು. ಅಂತ್ಯಬಿಂದುವಿನ ಹೋಸ್ಟ್‌ಹೆಸರನ್ನು ಟನೆಲ್ ಮೂಲಕ ಮಾತ್ರ ಪರಿಹರಿಸಬಹುದಾದರೆ, ಮತ್ತು ಟನೆಲ್‌ಗೆ ಪರಿಹರಿಸಿದ ಹೋಸ್ಟ್‌ಹೆಸರು ಬೇಕಾದರೆ, ನಿಮಗೆ ಸಂಪರ್ಕ ಟೈಮ್‌ಔಟ್ ಆಗಿ ಕಾಣುವ ಚಕ್ರೀಯ ಅವಲಂಬನೆ ಇದೆ. ಎರಡೂ ಟನೆಲ್‌ಗಳ ಹೊರಗೆ ಒಂದು ಬೂಟ್‌ಸ್ಟ್ರಾಪ್ ಮಾರ್ಗವನ್ನು ಇರಿಸಿ. ಸಂಪರ್ಕವನ್ನು ಉಳಿಸುವ ದಿನದವರೆಗೆ ಅದಕ್ಕೆ ಯಾವುದೇ ವೆಚ್ಚವಿಲ್ಲ.
ಪ್ರತಿ ರಿಝಾಲ್ವರ್‌ಗೆ ಇರುವ ಮಾರ್ಗವನ್ನು ನೋಡಿ, ಅದಕ್ಕೆ ಸಂರಚಿಸಿದ ಹೆಸರನ್ನು ಮಾತ್ರವಲ್ಲ. ಇನ್ನೊಂದು ಟನೆಲ್ ಮೂಲಕ ಮಾತ್ರ ತಲುಪಬಹುದಾದ ರಿಝಾಲ್ವರ್ ಕಾಣೆಯಾದಂತೆ ವರ್ತಿಸುತ್ತದೆ, ಮತ್ತು ಲಕ್ಷಣ ರೂಟಿಂಗ್ ದೋಷವಲ್ಲ, ಟೈಮ್‌ಔಟ್.
ಅತಿಪಾತ ಸರನಾಮೆಗಳು DNS ಸಮಸ್ಯೆಯಲ್ಲ
ಒಂದೇ ವಿಳಾಸ ಶ್ರೇಣಿಯನ್ನು ಬಳಸುವ ಎರಡು ಖಾಸಗಿ ನೆಟ್‌ವರ್ಕ್‌ಗಳನ್ನು DNS ಕ್ರಮದಿಂದ ಸರಿಪಡಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಎರಡೂ ಟನೆಲ್‌ಗಳು 10.0.0.0/8 ಅನ್ನು ಕ್ಲೈಮ್ ಮಾಡಿದರೆ, ಸರಿಯಾಗಿ ಪರಿಹರಿಸಲ್ಪಟ್ಟ ಹೆಸರೂ ಸಹ ಹೋಸ್ಟ್ ಸರಿಯಾದ ಟನೆಲ್‌ಗೆ ರೂಟ್ ಮಾಡಲಾಗದ ವಿಳಾಸಕ್ಕೆ ತೋರಿಸುತ್ತದೆ. ಇದಕ್ಕೆ ವಿಳಾಸ ಮಟ್ಟದ ಪರಿಹಾರ ಬೇಕು, ಉದಾಹರಣೆಗೆ ವಿಭಿನ್ನ ಶ್ರೇಣಿಗಳು, ಹೆಸರಿನ ಸ್ಥಳ ಅಥವಾ ಅನುವಾದ, ಇನ್ನೊಂದು ರಿಝಾಲ್ವರ್ ಸೆಟ್ಟಿಂಗ್ ಅಲ್ಲ. ಇದನ್ನು ಬೇಗ ನಿರ್ಧರಿಸುವುದು ಎಂದಿಗೂ ಕೆಲಸ ಮಾಡದ DNS ಸಂರಚನೆಯ ಮೂಲಕ ದೀರ್ಘ ಸುತ್ತುದಾರಿಯನ್ನು ತಪ್ಪಿಸುತ್ತದೆ.
ಹೆಸರು ಪರಿಹಾರವನ್ನು ದೂಷಿಸುವ ಮೊದಲು ಎರಡೂ ಟನೆಲ್‌ಗಳ ವಿಳಾಸ ಹಂಚಿಕೆಗಳನ್ನು ಹೋಲಿಸಿ. ಎರಡೂ ಕಡೆಗಳು ಒಂದೇ ಪೂರ್ವಪ್ರತ್ಯಯವನ್ನು ತಳ್ಳಿದಾಗ, ಹೋಸ್ಟ್ ಅದಕ್ಕೆ ಒಂದೇ ಮಾರ್ಗವನ್ನು ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ಎರಡನೇ ಟನೆಲ್ ಮೂಲಕ ಪರಿಹರಿಸಲ್ಪಟ್ಟ ಹೆಸರು ಇನ್ನೂ ಮೊದಲ ಟನೆಲ್‌ಗೆ ಸೇರಿದ ವಿಳಾಸದಲ್ಲೇ ಇಳಿಯುತ್ತದೆ. ವಿಭಿನ್ನ ಶ್ರೇಣಿಗಳು, ಪ್ರತಿ ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಹೆಸರಿನ ಸ್ಥಳ ಅಥವಾ ಅನುವಾದವೇ ಪರಿಹಾರಗಳು; ಪ್ರತಿ ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕಗೊಂಡ ನಂತರ ರೂಟ್ ಕೋಷ್ಟಕ ನೀವು ಉದ್ದೇಶಿಸಿದ ಮಾರ್ಗವನ್ನು ತೋರಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ.
ನಿಜವಾದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳೊಂದಿಗೆ ಅದನ್ನು ಸಾಬೀತುಪಡಿಸಿ
ತಮ್ಮದೇ ಹೆಸರಿನ ಸ್ಥಳದಲ್ಲಿ ಮಾತ್ರ ಇರುವ ಎರಡು ಹೋಸ್ಟ್‌ಗಳನ್ನು ಮತ್ತು ಒಂದು ಸಾರ್ವಜನಿಕ ಹೆಸರನ್ನು ಆಯ್ಕೆಮಾಡಿ, ನಂತರ ಪ್ರತಿಯೊಂದನ್ನು ಅದನ್ನು ಹೊಂದಿರಬೇಕಾದ ಕ್ಲೈಂಟ್ ಮೂಲಕ ಪರಿಹರಿಸಿ. ನಿರೀಕ್ಷಿತ ರಿಝಾಲ್ವರ್‌ನಿಂದ ಸರಿಯಾದ ಉತ್ತರವು ಅಪ್ಲಿಕೇಶನ್ ಹೋಸ್ಟ್ ತಲುಪುತ್ತದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಆ ವಿಳಾಸಕ್ಕೆ ಇರುವ ಮಾರ್ಗ ಇನ್ನೂ ವಿಫಲವಾಗಬಹುದು. ಪ್ರತಿ ಹುಡುಕಾಟದ ನಂತರ ಬಳಕೆದಾರರು ನಿಜವಾಗಿ ಚಲಾಯಿಸುವ ಪ್ರೋಗ್ರಾಮ್‌ನಿಂದ ಸಂಪರ್ಕ ಪರೀಕ್ಷೆ ಮಾಡಿ.
ತಮ್ಮದೇ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಆದ DNS ಆಯ್ಕೆ ಹೊಂದಿರುವ ಕ್ಲೈಂಟ್ ನೀವು ಈಗಷ್ಟೇ ಪರಿಶೀಲಿಸಿದ ನೀತಿಯನ್ನು ಬೈಪಾಸ್ ಮಾಡಬಹುದು, ಆದ್ದರಿಂದ ಆ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಪರಿಶೀಲನೆಯ ಭಾಗವಾಗಿ ಪರಿಶೀಲಿಸಿ. ನಂತರ ವೆಂಡರ್ ಬೆಂಬಲಿಸುವ ಕ್ರಮದಲ್ಲಿ ಎರಡೂ ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿ ಮತ್ತು ಹುಡುಕಾಟಗಳನ್ನು ಪುನರಾವರ್ತಿಸಿ; ಕ್ರಮ ಬದಲಾದಾಗ ಉತ್ತರಗಳು ಅದಲುಬದಲಾದರೆ, ಸ್ಪರ್ಧಿ ಬರಹಗಾರ ಇನ್ನೂ ಸಂರಚನೆಯ ಭಾಗವನ್ನು ಹೊಂದಿದ್ದಾನೆ. ಏನನ್ನೂ ಸಂಪಾದಿಸುವ ಮೊದಲು ಯಾವ ಘಟಕ ನಿಯಮವನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ ಎಂದು ಕಂಡುಹಿಡಿಯಿರಿ - ಕ್ಲೈಂಟ್, ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಂ ಪ್ರೊಫೈಲ್ ಅಥವಾ ನಿರ್ವಹಣಾ ಏಜೆಂಟ್. ಕ್ರಮ ಮತ್ತು ಮಾಲೀಕರನ್ನು ದಾಖಲಿಸಿ, ಮುಂದಿನ ವ್ಯಕ್ತಿ ಅವನ್ನು ಮತ್ತೆ ಕಂಡುಹಿಡಿಯಬೇಕಾಗಿಲ್ಲ.