ಸ್ಪ್ಲಿಟ್ ಟನೆಲ್ ಬ್ರೌಸರ್ ಅನ್ನು ಹೊರಗಿಡುತ್ತದೆ, ಅದರ DNS ಪ್ರಶ್ನೆಗಳನ್ನಲ್ಲ

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

ಡೇಟಾ ಮಾರ್ಗ ಮತ್ತು ರೆಸಾಲ್ವರ್ ಮಾರ್ಗ ಬೇರ್ಪಡುತ್ತವೆ

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

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

ಯಾವ ಪ್ರಕ್ರಿಯೆ ಪ್ರಶ್ನೆ ಕೇಳುತ್ತದೆ ಎಂದು ಕಂಡುಹಿಡಿಯಿರಿ

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

resolvectl status
resolvectl query intranet.example.net
dig +short +time=2 intranet.example.net @10.52.0.2
scutil --dns | head -n 40

ಪರೀಕ್ಷಿಸುವ ಮೊದಲು ಪರಿಣಾಮಕಾರಿ ಸಂರಚನೆಯನ್ನು ಓದಿ: ಯಾವ ಲಿಂಕ್ಗಳು DNS ಸರ್ವರ್ಗಳನ್ನು ಹೊತ್ತುಕೊಳ್ಳುತ್ತವೆ, ಯಾವ ಹೆಸರಿನ ಸ್ಥಳಗಳನ್ನು ಕ್ಲೇಮ್ ಮಾಡುತ್ತವೆ, ಮತ್ತು ಪ್ರತಿ-ಹೆಸರಿನ ನೀತಿ ಡೀಫಾಲ್ಟ್ ಅನ್ನು ಅತಿಕ್ರಮಿಸುತ್ತದೆಯೇ. Linux ನಲ್ಲಿ ಸ್ಪ್ಲಿಟ್ DNS ರೂಟಿಂಗ್ ಡೊಮೇನ್ಗಳನ್ನು ಬಳಸುತ್ತದೆ; Windows ನಲ್ಲಿ ಹೆಸರಿನ ಪರಿಹಾರ ನೀತಿ ಕೋಷ್ಟಕ ಹೆಸರಿನ ಸ್ಥಳಗಳಿಗೆ ಅದೇ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಎರಡೂ ಸೋರಿಕೆ ಪರೀಕ್ಷಾ ಪುಟದಿಂದ ಕಾಣುವುದಿಲ್ಲ.

ಯಾವ ರೆಸಾಲ್ವರ್ ಯಾವ ಹೆಸರನ್ನು ನೋಡುತ್ತದೆ ಎಂದು ನಿರ್ಧರಿಸಿ

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

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

ಒಂದು ಪರೀಕ್ಷಾ ಲೇಬಲ್ ಹಸಿರಾಗಲು ಪ್ರತಿ DNS ಕ್ಷೇತ್ರವನ್ನು ಮತ್ತೆ ಬರೆಯಬೇಡಿ. ಲೇಬಲ್ ಒಂದು ಕ್ಷಣದಲ್ಲಿ ಒಂದು ಪ್ರಕ್ರಿಯೆಯ ಒಂದು ಪ್ರಶ್ನೆಯನ್ನು ವಿವರಿಸುತ್ತದೆ.

ಪ್ರಶ್ನೆ ಮತ್ತು ಸಂಪರ್ಕವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರಿಶೀಲಿಸಿ

ಎರಡು ಮಾರ್ಗಗಳನ್ನು ಸ್ವತಂತ್ರವಾಗಿ ಪರೀಕ್ಷಿಸಿ. ಸಂಪರ್ಕ ಪರೀಕ್ಷೆ ಡೇಟಾ ಮಾರ್ಗವನ್ನು ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ರೆಸಾಲ್ವರ್ ಪರೀಕ್ಷೆ ಹೆಸರನ್ನು ಯಾರು ಪಡೆದರು ಎಂದು ತೋರಿಸುತ್ತದೆ.

curl -sS --max-time 8 https://api.ipify.org
resolvectl query example.net
dig +short example.net

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

ಅನುಮೋದಿತ ಬದಲಾವಣೆಯ ನಂತರ ಡೇಟಾ ಮಾರ್ಗ ಮತ್ತು ರೆಸಾಲ್ವರ್ನ ಸ್ವೀಕರಿಸುವವರನ್ನು ಎರಡು ಪ್ರತ್ಯೇಕ ಸಾಲುಗಳಾಗಿ ದಿನಾಂಕದೊಂದಿಗೆ ದಾಖಲಿಸಿ. ಮುಂದಿನ ಮರುಸಂಪರ್ಕದಲ್ಲಿ ವರ್ತನೆ ಮರಳಿದರೆ, ಅದನ್ನು ಒದಗಿಸುವ ಪ್ರೊಫೈಲ್ ಸರಿಪಡಿಸಬೇಕು, ಬ್ರೌಸರ್ ಅಲ್ಲ.