ಸ್ಪ್ಲಿಟ್ ಟನೆಲಿಂಗ್ ವಿರುದ್ಧ ಕಂಪನಿ ನೀತಿ: ಯಾವ ನಿಯಮ ಗೆಲ್ಲುತ್ತದೆ

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

ಚೆಕ್ಬಾಕ್ಸ್ ಬಗ್ಗೆ ವಾದಿಸುವ ಮೊದಲು ನೀತಿ ಯಾವ ಗುಣವನ್ನು ರಕ್ಷಿಸಲು ಇದೆ ಎಂದು ಕಂಡುಹಿಡಿಯಿರಿ.

ನಿಯಮದ ಹಿಂದಿನ ಗುಣ

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

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

ಇವು ನಾಲ್ಕು ವಿಭಿನ್ನ ಅಗತ್ಯಗಳು, ಮತ್ತು ಪ್ರತಿಯೊಂದನ್ನೂ ಬೇರೆ ವಿನಾಯಿತಿ ಮುರಿಯುತ್ತದೆ. ಬದಲಾವಣೆ ಸೂಚಿಸುವ ಮೊದಲು ಅಗತ್ಯವನ್ನು ಓದಿ, ಏಕೆಂದರೆ ಅದನ್ನು ಬರೆದವರು ಯಾವುದು ಅನ್ವಯಿಸುತ್ತದೆ ಎಂದು ತಕ್ಷಣ ಹೇಳಬಲ್ಲರು. ತಪ್ಪಾದದನ್ನು ಪೂರೈಸುವ ಬದಲಾವಣೆ ಏನನ್ನೂ ಕೊಳ್ಳುವುದಿಲ್ಲ.

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

ತಪಾಸಣೆಗಳನ್ನು ಕ್ರಮದಲ್ಲಿ ನಡೆಸಿ

ಕೆಳಗಿನ ಕ್ರಮವು ವಿನಾಯಿತಿಯನ್ನು ನಿಜವಾಗಿ ವಿಫಲವಾದ ಅತ್ಯಂತ ಚಿಕ್ಕ ವಿಷಯಕ್ಕೆ ಸೀಮಿತಗೊಳಿಸುತ್ತದೆ. ನಿಲ್ಲದ ಮೊದಲ ತಪಾಸಣೆಯಲ್ಲೇ ನಿಲ್ಲಿಸಿ, ಏಕೆಂದರೆ ನಂತರದ ಸರಿಪಡಿಸುವಿಕೆ ಮೊದಲಿನ ಕೊರತೆಯನ್ನು ಸರಿದೂಗಿಸಲಾರದು.

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

ಪ್ರತಿ ಉತ್ತರವೂ ಒಂದು ಸತ್ಯ, ಮತ್ತು ವಿನಾಯಿತಿ ವಿನಂತಿಗೆ ಸತ್ಯಗಳೇ ಬೇಕು. VPN ಕಿರಿಕಿರಿ ಎಂಬ ವಾದ ಅವುಗಳಲ್ಲಿ ಒಂದಲ್ಲ. ಸಂಭಾಷಣೆ ಆರಂಭವಾಗುವ ಮೊದಲು ಉತ್ತರಗಳನ್ನು ಬರೆಯಿರಿ.

ಸಂಕುಚಿತ ವಿನಾಯಿತಿ ಕೇಳಿ

ಅಪ್ಲಿಕೇಶನ್, ಗಮ್ಯಸ್ಥಾನ ಮತ್ತು ವಿಫಲವಾದ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಈ ಕ್ರಮದಲ್ಲಿ ವರದಿ ಮಾಡಿ. ಒಂದು ನವೀಕರಣಕಾರವನ್ನು ನೇರ ಮಾರ್ಗದಲ್ಲಿ ಇಡುವ ವಿನಂತಿಯನ್ನು ಪರಿಶೀಲಿಸಬಹುದು; ಇಡೀ ಬ್ರೌಸರ್‌ಗೆ ಟನೆಲ್ ತಪ್ಪಿಸುವ ವಿನಂತಿಯನ್ನು ಸಾಧ್ಯವಿಲ್ಲ.

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

ಉತ್ತರ ಇಲ್ಲ ಎಂದಾದರೆ ಅದನ್ನು ವಿನ್ಯಾಸ ನಿರ್ಧಾರವೆಂದು ಪರಿಗಣಿಸಿ, ತಪ್ಪಿಸಬೇಕಾದ ಅಡಚಣೆಯೆಂದಲ್ಲ. ಮುಂದಿನ ಪರಿಶೀಲನೆ ಅದನ್ನು ಮತ್ತೆ ತೆರೆಯುವ ಸ್ಥಳ, ವಿಫಲವಾದ ಕಾರ್ಯಾಚರಣೆ ದಾಖಲಾಗಿ ವ್ಯಾಪಾರ ಕಾರಣ ಲಗತ್ತಾಗಿ. ಅದನ್ನು ತಪ್ಪಿಸುವುದು ವಿನಾಯಿತಿ ಎಂದಾದರೂ ಮೌಲ್ಯವಾಗಿದ್ದಕ್ಕಿಂತ ಹೆಚ್ಚು ಅಪಾಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.

ವಿನಾಯಿತಿಯನ್ನು ಉಳಿಯುವಂತೆ ಮಾಡಿ

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

resolvectl query intranet.corp.example
curl -sS -o /dev/null -w '%{http_code}
' https://intranet.corp.example/status

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

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