IP ರೂಟ್ ಒಂದು ವಿಳಾಸ ಪ್ರಿಫಿಕ್ಸ್‌ಗೆ ಹೊಂದುತ್ತದೆ, ಮತ್ತು ಕರ್ನೆಲ್ ಇನ್ನಷ್ಟು ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳದೆ ಅದನ್ನು ಅನ್ವಯಿಸುತ್ತದೆ. ಡೊಮೇನ್-ಆಧಾರಿತ VPN ನಿಯಮವು ಒಂದು ಹೆಸರಿಗೆ ಹೊಂದುತ್ತದೆ, ಅಂದರೆ ಆ ಹೆಸರು ಈಗ ಯಾವ ವಿಳಾಸಗಳನ್ನು ಸೂಚಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಸ್ಟ್ಯಾಕ್‌ನಲ್ಲಿರುವ ಯಾವುದೋ ಒಂದು ನಿರ್ಧರಿಸಿ ಆ ನಿರ್ಧಾರವನ್ನು ನವೀಕೃತವಾಗಿ ಇಡಬೇಕು. ಇವು ವಿಭಿನ್ನ ವೈಫಲ್ಯ ವಿಧಾನಗಳನ್ನು ಹೊಂದಿರುವ ಬೇರೆ ಬೇರೆ ಕಾರ್ಯವಿಧಾನಗಳು, ಮತ್ತು ಮಾರಾಟಗಾರರು ಎರಡಕ್ಕೂ ಒಂದೇ ಪದವನ್ನು ಬಳಸುತ್ತಾರೆ. ವೈಶಿಷ್ಟ್ಯ ಪಟ್ಟಿಗಳಲ್ಲಿ ಅವನ್ನು ಹೋಲಿಸುವುದು ಮುಖ್ಯಾಂಶವನ್ನು ತಪ್ಪಿಸುತ್ತದೆ; ಉತ್ತರ ಬದಲಾದಾಗ ಏನಾಗುತ್ತದೆ ಎಂಬುದರ ಮೇಲೆ ಅವನ್ನು ಹೋಲಿಸಿ.

ಉಪಯುಕ್ತ ವಿಭಜನೆ ಎಂದರೆ ಪರಿಹರಿಸುವ ನಿಯಮ ಮತ್ತು ಪರಿಹರಿಸದ ನಿಯಮದ ನಡುವಿನದು.

ಪ್ರತಿ ನಿಯಮವು ವಾಸ್ತವವಾಗಿ ಯಾವುದಕ್ಕೆ ಹೊಂದುತ್ತದೆ

ಪ್ರಿಫಿಕ್ಸ್ ನಿಯಮವು ರೂಟಿಂಗ್ ಕೋಷ್ಟಕದಲ್ಲಿ ಗಮ್ಯಸ್ಥಾನ ವಿಳಾಸಗಳಿಗೆ ಹೊಂದುತ್ತದೆ. ಯಾವುದೂ ಪರಿಹರಿಸುವುದಿಲ್ಲ, ಯಾವುದೂ ಅವಧಿ ಮುಗಿಯುವುದಿಲ್ಲ, ಮತ್ತು ಪ್ರತಿ ಪ್ಯಾಕೆಟ್‌ಗೂ ಹೊಂದಿಕೆ ನಿಖರವಾಗಿದೆ. ಡೊಮೇನ್ ನಿಯಮವು ಅಪ್ಲಿಕೇಶನ್‌ನ ಹೆಸರಿನ ಬೇಡಿಕೆಗೆ ಹೊಂದುತ್ತದೆ, ಅದನ್ನು RFC 1034 ವಿಳಾಸವಲ್ಲ, ಲೇಬಲ್‌ಗಳ ಮರವೆಂದು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ. ಕೆಲವು ಉತ್ಪನ್ನಗಳು ಹೆಸರನ್ನು ಒಮ್ಮೆ ಪರಿಹರಿಸಿ ಫಲಿತಾಂಶದ ವಿಳಾಸಗಳನ್ನು ರೂಟ್‌ಗಳಾಗಿ ಸ್ಥಾಪಿಸುತ್ತವೆ, ಇದು ನಿಯಮವನ್ನು ರಿಫ್ರೆಶ್ ಟೈಮರ್ ಜೋಡಿಸಿದ IP ನಿಯಮವನ್ನಾಗಿ ಮಾಡುತ್ತದೆ.

ಡೀಬಗ್ ಮಾಡುವ ಮೊದಲು ಈ ಎರಡರಲ್ಲಿ ಯಾವುದು ನಿಮ್ಮಲ್ಲಿದೆ ಎಂದು ತಿಳಿಯಿರಿ, ಏಕೆಂದರೆ ಪ್ರತಿ ಸಂದರ್ಭದಲ್ಲೂ ವೈಫಲ್ಯ ಸಂಪೂರ್ಣವಾಗಿ ಬೇರೆಯಾಗಿ ಕಾಣುತ್ತದೆ.

ಸ್ಟ್ಯಾಕ್‌ನಲ್ಲಿ ಡೊಮೇನ್ ನಿಯಮ ಎಲ್ಲಿದೆ

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

ಸೆಟ್ಟಿಂಗ್‌ನ ಲೇಬಲ್ ಅಲ್ಲ, ಮಾರಾಟಗಾರರ ಮಾದರಿಯನ್ನು ಓದಿ. Split Tunnel ಎಂಬ ಬಾಕ್ಸ್ ಇರುವ ಇಬ್ಬರು ಕ್ಲೈಂಟ್‌ಗಳು ಮೂರು ಬೇರೆ ಬೇರೆ ಕೆಲಸಗಳನ್ನು ಮಾಡುತ್ತಿರಬಹುದು.

ಏನು ಮುರಿಯುತ್ತದೆ ಎಂದು ಹೋಲಿಸಿ

ಮೂರು ವಿಷಯಗಳು ಬೇರೆ ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಮುರಿಯುತ್ತವೆ. ವಿಳಾಸ ಬದಲಾವಣೆ: CDN ಹೋಸ್ಟ್‌ನಾಮ್ ಕೆಲವೇ ನಿಮಿಷಗಳಲ್ಲಿ ಬೇರೆ ವಿಳಾಸ ಗುಂಪಿಗೆ ಪರಿಹರಿಸಬಹುದು, ಆದ್ದರಿಂದ ನಕಲಿಸಿದ ಪಟ್ಟಿ ಬೇಗ ಹಳೆಯದಾಗುತ್ತದೆ. ಸಬ್‌ಡೊಮೇನ್ ವ್ಯಾಪ್ತಿ: example.com ನಿಯಮವು api.example.com ಅನ್ನು ಒಳಗೊಳ್ಳಬಹುದು ಅಥವಾ ಇಲ್ಲ, ಮತ್ತು ದಾಖಲೆ ಸಾಮಾನ್ಯವಾಗಿ ಯಾವುದು ಎಂದು ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳುತ್ತದೆ. ಪರಿಹಾರ ವೈಫಲ್ಯ: ರಿಸಾಲ್ವರ್ ವಿಫಲವಾದಾಗ, ಪರಿಹರಿಸುವ ಕ್ಲೈಂಟ್ ಸಂಚಾರವನ್ನು ಟನೆಲ್ ಮಾಡಲು ಅಥವಾ ನೇರವಾಗಿ ಕಳುಹಿಸಲು ಹಿಂತಿರುಗಬಹುದು.

ಎರಡನೆಯದು ಮಾತ್ರ ಕಾನ್ಫಿಗರೇಶನ್ ಪ್ರಶ್ನೆ. ಉಳಿದ ಎರಡು ಉತ್ಪನ್ನ ಎಷ್ಟು ಊಹಿಸಲು ಸಿದ್ಧವಿದೆ ಎಂಬ ವಿನ್ಯಾಸದ ಪ್ರಶ್ನೆಗಳು.

BehaviourPrefix ruleDomain rule
Match basisdestination addressrequested name or resolved addresses
Stalenessnonedepends on refresh policy
Subdomain scopenot applicableproduct-defined
Resolver outageunaffectedproduct-defined fallback
Where to debugrouting tableclient log plus resolver state

ಪ್ರಿಫಿಕ್ಸ್ ಯಾವಾಗ ಉತ್ತಮ ಉತ್ತರ

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

ಊಹಿಸಿದ ಸ್ಥಿರ ಪಟ್ಟಿ ಎರಡರಲ್ಲೂ ಕೆಟ್ಟದು: ಅದು ನಿರ್ವಹಿಸಲ್ಪಟ್ಟಂತೆ ಕಾಣುತ್ತದೆ, ಮತ್ತು ಪೂರೈಕೆದಾರರು ಹೋಸ್ಟ್ ಸೇರಿಸುವ ದಿನ ಸಂಚಾರವನ್ನು ಸದ್ದಿಲ್ಲದೆ ತಪ್ಪಿಸುತ್ತದೆ.

ಹೊಸ ವಿನಂತಿಯಿಂದ ಪರಿಶೀಲಿಸಿ

ಸಾಮಾನ್ಯ ಮರುಸಂಪರ್ಕದ ನಂತರ ಕೋಲ್ಡ್ ವಿನಂತಿಯಿಂದ ಪರೀಕ್ಷಿಸಿ, ಏಕೆಂದರೆ ಕ್ಯಾಶ್ ಮಾಡಿದ ಪುಟವು ನಿಯಮವನ್ನು ಎಂದಿಗೂ ಸ್ಪರ್ಶಿಸದಿರಬಹುದು. ಹೆಸರನ್ನು ಪರಿಹರಿಸಿ, ನಂತರ ಸಂಪರ್ಕವು ನಿಜವಾಗಿ ಎಲ್ಲಿಗೆ ಹೋಯಿತು ಎಂದು ಪರಿಶೀಲಿಸಿ. dig +short app.example.com ಪ್ರಸ್ತುತ ವಿಳಾಸ ಗುಂಪನ್ನು ನೀಡುತ್ತದೆ, ಮತ್ತು ಕ್ಲೈಂಟ್‌ನ ಸಂಪರ್ಕ ಪಟ್ಟಿ ಯಾವ ಇಂಟರ್ಫೇಸ್ ಹರಿವನ್ನು ಸಾಗಿಸಿತು ಎಂದು ಹೇಳುತ್ತದೆ.

ಉತ್ಪನ್ನವು ದಾಖಲಿಸುವ ರಿಫ್ರೆಶ್ ಮಧ್ಯಂತರದ ನಂತರ ಪುನರಾವರ್ತಿಸಿ. ವಿಳಾಸ ಗುಂಪು ಜಾರಿದರೂ ನಿಯಮವು ಅದನ್ನು ಅನುಸರಿಸದಿದ್ದರೆ, ನೀವು ನಿಜವಾದ ನಡವಳಿಕೆಯನ್ನು ಕಂಡುಕೊಂಡಿದ್ದೀರಿ.

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

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