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

ರೂಟ್ ಏನನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ, ಮತ್ತು ಏನನ್ನು ಎಂದಿಗೂ ಓದುವುದಿಲ್ಲ

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

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

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

ಗಮ್ಯಸ್ಥಾನ ನಿಜವಾಗಿಯೂ ಪೂರ್ವಪ್ರತ್ಯಯವಾದಾಗ

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

route 10.60.4.20 255.255.255.255
route 10.60.0.0 255.255.0.0

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

ಒಂದೇ DNS ಉತ್ತರದಿಂದ ದೊಡ್ಡ ಪೂರ್ವಪ್ರತ್ಯಯವನ್ನು ಊಹಿಸಬೇಡಿ. ಒಂದು ವಿಳಾಸಕ್ಕೆ ಪರಿಹರಿಸಲ್ಪಡುವ ಒಂದು ಹೋಸ್ಟ್‌ನಾಮ್ ಅದರ ಹಿಂದಿನ ನೆಟ್‌ವರ್ಕ್‌ನ ಗಾತ್ರದ ಬಗ್ಗೆ ನಿಮಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ, ಮತ್ತು ಊಹಿಸಿದ ಪೂರ್ವಪ್ರತ್ಯಯವೇ ಸುರಂಗವು ಯಾರೂ ಅದರ ಮೂಲಕ ಕಳುಹಿಸಲು ಉದ್ದೇಶಿಸದ ಸಂಚಾರವನ್ನು ಹಿಡಿಯುವ ರೀತಿ. ಹುಡುಕಾಟದಿಂದ ಊಹಿಸುವ ಬದಲು ನೆಟ್‌ವರ್ಕ್ ಮಾಲೀಕರನ್ನು ನಿಜವಾದ ಪೂರ್ವಪ್ರತ್ಯಯವನ್ನು ಕೇಳಿ.

ಕೆಲಸದ ಘಟಕ ಹೋಸ್ಟ್‌ನಾಮ್ ಆಗಿರುವಾಗ

ಡೊಮೇನ್ ಮೂಲಕ ಆಯ್ಕೆ ಮಾಡಲು ಡೊಮೇನ್ ಓದುವ ಯಾವುದೋ ಬೇಕು, ಅಂದರೆ ಅಪ್ಲಿಕೇಶನ್ ಪದರದ ಘಟಕ. ಸಾಮಾನ್ಯ ಉತ್ತರ ಸುರಂಗದ ಆಚೆ ಬದಿಯಲ್ಲಿ ವಾಸಿಸುವ HTTP ಪ್ರಾಕ್ಸಿ, ಮತ್ತು ಯಾವ ವಿನಂತಿಗಳನ್ನು ಅದಕ್ಕೆ ಕಳುಹಿಸಬೇಕೆಂದು ಕ್ಲೈಂಟ್ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ.

ಪ್ರಾಕ್ಸಿ ಸಂರಚನಾ ಫೈಲ್ ಆ ಆಯ್ಕೆಯನ್ನು ವ್ಯಕ್ತಪಡಿಸಬಹುದು. ಕೆಳಗಿನ ಉದಾಹರಣಾ ನಿಯಮಗಳು ಒಂದು ಡೊಮೇನ್ ಮತ್ತು ಅದರ ಉಪಡೊಮೇನ್‌ಗಳನ್ನು ಪ್ರಾಕ್ಸಿಗೆ, ಉಳಿದೆಲ್ಲವನ್ನೂ ನೇರವಾಗಿ ಕಳುಹಿಸುತ್ತವೆ:

function FindProxyForURL(url, host) {
    var h = host.toLowerCase();
    if (h === "corp.example" || dnsDomainIs(h, ".corp.example")) {
        return "PROXY 10.60.0.12:3128";
    }
    return "DIRECT";
}

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

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

ಪ್ರಾಕ್ಸಿ ಆಯ್ಕೆ ಏನನ್ನು ಆವರಿಸುವುದಿಲ್ಲ

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

ನೇರವಾಗಿ ಹಿಂತಿರುಗುವುದೂ ತಪ್ಪಿಸಿಕೊಳ್ಳುವ ದಾರಿಯಲ್ಲ. ಯಂತ್ರದ ರೂಟಿಂಗ್ ನೀತಿ ಈಗಾಗಲೇ ಎಲ್ಲವನ್ನೂ ಸುರಂಗಕ್ಕೆ ಕಳುಹಿಸುತ್ತಿದ್ದರೆ, ನೇರ ಎಂದು ಗುರುತಿಸಲಾದ ವಿನಂತಿ ಅದರೊಳಗೇ ಉಳಿಯುತ್ತದೆ, ಏಕೆಂದರೆ ಪ್ರಾಕ್ಸಿ ಆಯ್ಕೆ ಮತ್ತು ರೂಟ್ ಟೇಬಲ್ ಬೇರೆ ಬೇರೆ ಪದರಗಳಲ್ಲಿ ತೆಗೆದುಕೊಳ್ಳುವ ಬೇರೆ ಬೇರೆ ನಿರ್ಧಾರಗಳು.

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

ಎರಡೂ ಮಾರ್ಗಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ, ಸುಖಕರವನ್ನು ಮಾತ್ರವಲ್ಲ

ಹೊಂದಬೇಕಾದ ಹೋಸ್ಟ್‌ನಾಮ್, ಹೊಂದಬಾರದ ಹೋಸ್ಟ್‌ನಾಮ್, ಮತ್ತು ಡೊಮೇನ್‌ನ ಶಿಖರವನ್ನು ಪರೀಕ್ಷಿಸಿ, ಏಕೆಂದರೆ ಶಿಖರವು ಪ್ರತ್ಯಯ-ಮಾತ್ರ ನಿಯಮದಿಂದ ಅತ್ಯಂತ ಹೆಚ್ಚು ತಪ್ಪಿಹೋಗುವ ಸಂದರ್ಭ. ನಂತರ ಪುಟ ಲೋಡ್ ಆಯಿತೇ ಎಂಬುದರಿಂದ ಊಹಿಸುವ ಬದಲು ಪ್ರತಿ ವಿನಂತಿ ವಾಸ್ತವವಾಗಿ ಯಾವ ಮಾರ್ಗ ತೆಗೆದುಕೊಂಡಿತು ಎಂದು ದೃಢೀಕರಿಸಿ.

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

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