Apple VPN On Demand ನ ಡೊಮೇನ್ ನಿಯಮಗಳು ಟನೆಲ್ ಅನ್ನು ಹೇಗೆ ಪ್ರಾರಂಭಿಸುತ್ತವೆ
ಡೊಮೇನ್ ನಿಯಮವು ಟನೆಲ್ ಯಾವಾಗ ತೆರೆಯುತ್ತದೆ ಎಂಬುದನ್ನು ಮಾತ್ರ ನಿರ್ಧರಿಸುತ್ತದೆ. connect-if-needed DNS ಪ್ರೋಬ್ ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಮಾರ್ಗಗಳು ಇನ್ನೂ ಸಂಚಾರವನ್ನು ಏಕೆ ಆಯ್ಕೆ ಮಾಡುತ್ತವೆ ಮತ್ತು ಪ್ರೊಫೈಲ್ ಅನ್ನು ಹೇಗೆ ಪರೀಕ್ಷಿಸಬೇಕು.
ನೀವು ಒಂದು ಆಂತರಿಕ ಹೆಸರನ್ನು ಕೇಳಿದಾಗ ಟನೆಲ್ ತೆರೆಯುತ್ತದೆ ಮತ್ತು ಮುಂದಿನ ಆ್ಯಪ್‌ಗೆ ಅದೇ ರೀತಿ ಬೇಕಾದಾಗ ಮುಚ್ಚಿಯೇ ಇರುತ್ತದೆ. ಇದು ಆ್ಯಪ್‌ನ ದೋಷವಲ್ಲ; ಇದು ಡೊಮೇನ್ ನಿಯಮದ ಆಕಾರ. Apple ನ on-demand ಸಂರಚನೆ ಸಂಪರ್ಕ ಮಾಡುವ ಷರತ್ತುಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ, ಮತ್ತು ಆ ಷರತ್ತುಗಳ ಡೊಮೇನ್ ರೂಪವು ಒಂದು ಪ್ಯಾಕೆಟ್ ಕೂಡ ಚಲಿಸುವ ಮೊದಲು ಸಿಸ್ಟಂ ರಿಸಾಲ್ವರ್‌ಗೆ ಪ್ರಶ್ನೆ ಹಾಕುತ್ತದೆ. ಎರಡು ಪ್ರಶ್ನೆಗಳು ಸತತವಾಗಿ ಬೆರೆಯುತ್ತವೆ: ಟನೆಲ್ ಯಾವಾಗ ಏರಬೇಕು, ಮತ್ತು ಟನೆಲ್ ಇದ್ದ ಮೇಲೆ ಏನನ್ನು ಸಾಗಿಸುತ್ತದೆ. ಮೊದಲನೆಯದು ಟ್ರಿಗರ್, ಎರಡನೆಯದು ಮಾರ್ಗ ಮತ್ತು ರಿಸಾಲ್ವರ್ ನೀತಿ, ಮತ್ತು ಒಂದು ಪ್ರೊಫೈಲ್ ಸಾಮಾನ್ಯವಾಗಿ ಎರಡನ್ನೂ ಒಂದೇ payload ನಲ್ಲಿ ಹೊಂದಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಸರಿಯಾದ ಡೊಮೇನ್ ನಿಯಮವೂ ನಿಮ್ಮನ್ನು ತಪ್ಪು ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಬಿಡಬಹುದು.
ಟ್ರಿಗರ್ ಮತ್ತು ಸಂಚಾರ ಆಯ್ಕೆ ಬೇರೆ ಬೇರೆ ಪದರಗಳಲ್ಲಿ
on-demand ನಿಯಮವು VPN payload ನ on-demand ನಿಘಂಟಿನಲ್ಲಿ ವಾಸಿಸುತ್ತದೆ: ಕ್ರಮಬದ್ಧ ನಿಯಮಗಳ ಪಟ್ಟಿ, ಪ್ರತಿಯೊಂದೂ ಒಂದು ಕ್ರಿಯೆ ಮತ್ತು ಹೊಂದಾಣಿಕೆ ಷರತ್ತುಗಳ ಗುಂಪನ್ನು ಹೊಂದಿದೆ. ಸಂಪರ್ಕ ಬದಲಾದಾಗ ಅಥವಾ ಏನಾದರೂ ನೆಟ್‌ವರ್ಕ್ ತಲುಪಲು ಪ್ರಯತ್ನಿಸಿದಾಗ ಸಿಸ್ಟಂ ಅವನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಕ್ರಿಯೆಯು ಟನೆಲ್ ಏರಿಸಬೇಕೆ, ಮೌಲ್ಯಮಾಪನ ಮಾಡಬೇಕೆ, ಸಂಪರ್ಕ ಕಡಿತಗೊಳಿಸಬೇಕೆ ಅಥವಾ ನಿರ್ಲಕ್ಷಿಸಬೇಕೆ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ. ಇದೆಲ್ಲವೂ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನ ನೆಟ್‌ವರ್ಕಿಂಗ್ ಪದರದಲ್ಲಿ, ನಿಮ್ಮ ಆ್ಯಪ್‌ಗೆ ಸಾಕೆಟ್ ಸಿಗುವ ಮೊದಲು ನಡೆಯುತ್ತದೆ.
ಅದಾದ ಮೇಲೆ ಬರುವುದು ಬೇರೆ ಕೀ ಗುಂಪು: ಟನೆಲ್‌ನ IPv4 ಮತ್ತು IPv6 ಸೆಟ್ಟಿಂಗ್‌ಗಳು, ಅದರ ಒಳಗೊಂಡ ಮತ್ತು ಹೊರಗಿಟ್ಟ ಮಾರ್ಗಗಳು, DNS ಸರ್ವರ್ ವಿಳಾಸಗಳು, ಮತ್ತು iOS ಹಾಗೂ iPadOS ನಲ್ಲಿ ಯಾವ ಆ್ಯಪ್‌ಗಳು ಟನೆಲ್ ಬಳಸಬಹುದು ಎಂದು ನಿರ್ಧರಿಸುವ ಪ್ರತಿ-ಆ್ಯಪ್ ಮ್ಯಾಪಿಂಗ್. ಒಂದು ಪ್ರೊಫೈಲ್ ಅಗಲವಾದ ಟ್ರಿಗರ್ ಅನ್ನು ಸಣ್ಣ ಮಾರ್ಗದೊಂದಿಗೆ ಜೋಡಿಸಬಹುದು, ಅಥವಾ ಸಣ್ಣ ಟ್ರಿಗರ್ ಅನ್ನು ಡಿಫಾಲ್ಟ್ ಮಾರ್ಗದೊಂದಿಗೆ. ಒಂದು ಅರ್ಧ ಮಾತ್ರ ಓದಿ, ಇನ್ನೊಂದು ಅರ್ಧ ದೋಷದಂತೆ ಕಾಣುತ್ತದೆ.
ನನ್ನ ಪ್ರಯೋಗಾಲಯದ ಪ್ರೊಫೈಲ್ ಆಂತರಿಕ ಡೊಮೇನ್ ಅಡಿಯಲ್ಲಿ ಏನಾದರೂ ಕೇಳಿದಾಗ ಸಂಪರ್ಕಿಸುತ್ತದೆ ಆದರೆ ಟನೆಲ್‌ಗೆ ಒಂದು /16 ಮಾತ್ರ ರೂಟ್ ಮಾಡುತ್ತದೆ. ಅದು ತನ್ನ payload ಹೇಳುವುದನ್ನೇ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಇದು ಟಿಕೆಟ್‌ಗಳನ್ನು ಸೃಷ್ಟಿಸುವ ಪ್ರೊಫೈಲ್ ಪ್ರಕಾರವೂ ಆಗಿದೆ: ಜನರು ಸಂಪರ್ಕಗೊಂಡ ಟನೆಲ್ ಎಂದರೆ ತಮ್ಮ ಸಂಚಾರ ಅದರೊಳಗಿದೆ ಎಂದು ಭಾವಿಸುತ್ತಾರೆ.
ಡೊಮೇನ್ ನಿಯಮ ರಿಸಾಲ್ವರ್‌ಗೆ ನಿಜವಾಗಿ ಏನನ್ನು ಕೇಳುತ್ತದೆ
ಸಾಮಾನ್ಯವಾಗಿ connect-if-needed ಎಂದು ಕರೆಯುವ ನಿಯಮದ ಡೊಮೇನ್ ರೂಪವು ಪ್ಯಾಕೆಟ್ payload ಪರಿಶೀಲಿಸುವುದಿಲ್ಲ ಮತ್ತು URL ನೋಡುವುದಿಲ್ಲ. ಹೆಸರು ಪರಿಹರಿಸಲ್ಪಟ್ಟಾಗ, ಸಿಸ್ಟಂ ಅದನ್ನು ನಿಯಮದ ಡೊಮೇನ್‌ಗಳೊಂದಿಗೆ ಹೋಲಿಸುತ್ತದೆ ಮತ್ತು ಹೊಂದಿಕೆಯಾದರೆ ಆ ಹೆಸರನ್ನು ಟನೆಲ್ ಒದಗಿಸುವ DNS ಸರ್ವರ್‌ಗಳ ಮೂಲಕ ಪರಿಹರಿಸಬಹುದೇ ಎಂದು ಕೇಳುತ್ತದೆ. ಟನೆಲ್‌ನ ರಿಸಾಲ್ವರ್ ಉತ್ತರಿಸಿದರೆ, ಹೆಸರು ಆಂತರಿಕ ಎಂದು ಪರಿಗಣಿಸಿ ಸಂಪರ್ಕ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ಬದಲಿಗೆ ಸ್ಥಳೀಯ ರಿಸಾಲ್ವರ್ ಉತ್ತರಿಸಿದರೆ, ಹೆಸರು ಬಾಹ್ಯ ಎಂದು ಪರಿಗಣಿಸಿ ಟನೆಲ್ ಕಾಣಿಸುವುದಿಲ್ಲ. Apple ನ ನಿಯೋಜನೆ ಅವಲೋಕನ ಇದನ್ನು ನೆಟ್‌ವರ್ಕ್ ಪತ್ತೆ ಮತ್ತು ನಂತರ ಸಂಪರ್ಕ ಮೌಲ್ಯಮಾಪನ ಎಂದು ವಿವರಿಸುತ್ತದೆ.
ಎರಡು ಪರಿಣಾಮಗಳು ಉಂಟಾಗುತ್ತವೆ. ಪ್ರೊಫೈಲ್ ಟನೆಲ್ ಒಳಗೆ DNS ಸರ್ವರ್‌ಗಳನ್ನು ಹೆಸರಿಸಬೇಕು; ಟನೆಲ್ ರಿಸಾಲ್ವರ್ ಇಲ್ಲದ ಡೊಮೇನ್ ನಿಯಮಕ್ಕೆ ಹೋಲಿಸಲು ಏನೂ ಇಲ್ಲ, ಆದ್ದರಿಂದ ಮೌಲ್ಯಮಾಪನ ನೀವು ನಿರೀಕ್ಷಿಸುವ ಹೊಂದಾಣಿಕೆಯನ್ನು ನೀಡಲಾರದು. ಮತ್ತು ಹುಡುಕಾಟ ಸಿಸ್ಟಂ ರಿಸಾಲ್ವರ್ ತಲುಪಬೇಕು. ತಮ್ಮದೇ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಿದ DNS ಚಲಾಯಿಸುವ ಆ್ಯಪ್ ಅಥವಾ ಬ್ರೌಸರ್, ಸ್ಥಳೀಯವಾಗಿ ಉತ್ತರಿಸುವ ವಿಸ್ತರಣೆ, ಅಥವಾ ಅಕ್ಷರಶಃ ವಿಳಾಸಕ್ಕೆ ಸಂಪರ್ಕ — ಇವು ನಿಯಮ ಕಾಯುತ್ತಿದ್ದ ಹೆಸರು ಪರಿಹಾರವನ್ನು ಎಂದಿಗೂ ಉಂಟುಮಾಡುವುದಿಲ್ಲ. ನಾನು ಕಳೆದ ಅತಿ ಉದ್ದದ ಮಧ್ಯಾಹ್ನಗಳಲ್ಲಿ ಒಂದು, ಟನೆಲ್ ಮುಂದಿನ ಕ್ಲೈಂಟ್ DNS over HTTPS ಬಳಸುತ್ತಿದೆ ಎಂದು ತಿಳಿದಾಗ ಮುಗಿಯಿತು.
ಕ್ಯಾಶಿಂಗ್ ಕೂಡ ಟ್ರಿಗರ್ ತೆಗೆದುಹಾಕುತ್ತದೆ. ಈಗಾಗಲೇ ಕ್ಯಾಶ್‌ನಲ್ಲಿರುವ ಹೆಸರಿಗೆ ಟನೆಲ್ ಪ್ರಾರಂಭಿಸುತ್ತಿದ್ದ ಪ್ರೋಬ್ ಇಲ್ಲದೆ ಉತ್ತರ ನೀಡಬಹುದು, ಆದ್ದರಿಂದ ನಿನ್ನೆ ಕೆಲಸ ಮಾಡಿದ ನಿಯಮವು ಮರುಬೂಟ್ ನಂತರ ಅಥವಾ ಟನೆಲ್ ಸ್ವಲ್ಪ ಸಮಯ ಮೇಲಿದ್ದ ಮೇಲೆ ವಿಫಲವಾಗುತ್ತದೆ. macOS ನಲ್ಲಿ sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder ಸ್ಥಿತಿಯನ್ನು ಮರುಹೊಂದಿಸುತ್ತದೆ; iOS ನಲ್ಲಿ ಏರ್‌ಪ್ಲೇನ್ ಮೋಡ್ ಆನ್-ಆಫ್ ಮಾಡುವುದು ಅಥವಾ ಸಾಧನ ಮರುಪ್ರಾರಂಭಿಸುವುದು ಹೋಲುವ ಸ್ವಚ್ಛ ಆರಂಭ ನೀಡುತ್ತದೆ.
ಹೊಂದಾಣಿಕೆಯ ವ್ಯಾಪ್ತಿ: ಹೆಸರು, ಆ್ಯಪ್ ಮತ್ತು ನೆಟ್‌ವರ್ಕ್
ಡೊಮೇನ್ ಹೊಂದಾಣಿಕೆ ಹಲವು ಪ್ರಕಾರಗಳಲ್ಲಿ ಒಂದು. ನಿಯಮವು ಇಂಟರ್ಫೇಸ್ ಪ್ರಕಾರ (Wi-Fi, ಸೆಲ್ಯುಲರ್, Ethernet) ಮತ್ತು ನಿರ್ದಿಷ್ಟ SSID ಗೂ ಹೊಂದಬಹುದು, ಮತ್ತು ಪ್ರತಿ-ಆ್ಯಪ್ ಅಥವಾ Safari ಡೊಮೇನ್ ನಮೂದುಗಳು ಟನೆಲ್ ಅನ್ನು ಒಂದು ಕೆಲಸದ ಹರಿವಿಗೆ ಬಂಧಿಸುತ್ತವೆ. ಆ ಬಂಧವೇ ಒಂದೇ ಆ್ಯಪ್ ಉಳಿದೆಲ್ಲದಕ್ಕಿಂತ ಬೇರೆಯಾಗಿ ವರ್ತಿಸುವ ವಿಚಿತ್ರ ಅನುಭವವನ್ನು ವಿವರಿಸುತ್ತದೆ: ಉಳಿದ ಆ್ಯಪ್‌ಗಳು ಟನೆಲ್ ವ್ಯಾಪ್ತಿಯ ಹೊರಗಿವೆ, ಆದ್ದರಿಂದ ಟನೆಲ್ ಐಕಾನ್ ಸಂಪರ್ಕಗೊಂಡಿದೆ ಎಂದು ಹೇಳಿದರೂ ಅವು ಸ್ಥಳೀಯ ಮಾರ್ಗವನ್ನೇ ಬಳಸುತ್ತವೆ.
ಕ್ರಮವು ಜನರು ನಿರೀಕ್ಷಿಸುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು ಮುಖ್ಯ. ನಿಯಮಗಳು ಕ್ರಮವಾಗಿ ಮೌಲ್ಯಮಾಪನಗೊಳ್ಳುತ್ತವೆ ಮತ್ತು ಮೊದಲು ಹೊಂದುವುದು ಕ್ರಿಯೆಯನ್ನು ನೀಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಸಣ್ಣ ಡೊಮೇನ್ ನಿಯಮದ ಮೇಲೆ ಇರಿಸಿದ ಅಗಲವಾದ ಯಾವುದೇ-Wi-Fi-ಗೆ-ಸಂಪರ್ಕಿಸು ನಿಯಮವು ಮೌನವಾಗಿ ಗೆದ್ದು ಡೊಮೇನ್ ನಿಯಮವನ್ನು ಪರೀಕ್ಷಿಸಲಾಗದಂತೆ ಮಾಡುತ್ತದೆ. ಡೊಮೇನ್ ಪಟ್ಟಿಯನ್ನು ಮತ್ತೆ ಬರೆಯುವ ಮೊದಲು ಹಿಂದಿನ ಯಾವುದೇ ನಿಯಮ ಈಗಾಗಲೇ ಹೊಂದಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿ.
ಇದಕ್ಕಾಗಿಯೇ always-on ಕೇವಲ ಕಟ್ಟುನಿಟ್ಟಾದ on-demand ನಿಯಮವಲ್ಲ. always-on ಜಾರಿಗೊಳಿಸುವಿಕೆ ಪ್ರತ್ಯೇಕ ನಿಯೋಜನೆ ಮೋಡ್ ಆಗಿದ್ದು ಅದರದೇ ಮೇಲ್ವಿಚಾರಣೆ ಮತ್ತು ನಿರ್ವಹಣಾ ಅಗತ್ಯಗಳನ್ನು ಹೊಂದಿದೆ; ಅದು ಹೆಸರಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುವ ಬದಲು ಟನೆಲ್ ತೆರೆದಿಡುತ್ತದೆ. ಎಂದಿಗೂ ಬೀಳದ ಟನೆಲ್ ಬೇಕಾದರೆ, ಡೊಮೇನ್ ನಿಯಮ ತಪ್ಪು ಸಾಧನ.
ಮುರಿದ ನಿಯಮದಂತೆ ಕಾಣುವ ವೈಫಲ್ಯಗಳು
ಡೊಮೇನ್ ನಿಯಮ ಕೆಲಸ ಮಾಡುತ್ತಿಲ್ಲ ಎಂಬ ವರದಿಗಳ ಹೆಚ್ಚಿನವು ಐದು ಸ್ಥಳಗಳಲ್ಲಿ ಒಂದಕ್ಕೆ ಬೀಳುತ್ತವೆ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಕೊನೆಯದು ಮಾತ್ರ ನಿಯಮದ ಪಠ್ಯ.
| What you see | Layer | First check |
|---|---|---|
| Tunnel comes up, internal site still fails | route or resolver after connect | netstat -rn, scutil --dns |
| Tunnel never comes up for that name | trigger path | fresh lookup, cache flush, private DNS |
| Tunnel comes up for every app | scope, or an earlier rule | rule order, per-app mapping |
| Tunnel drops and will not return on the same Wi-Fi | interface or SSID match, admission | captive portal, SSID string, auth prompt |
| Tunnel returns after you disconnect it | profile ownership | profiles show |
ಕ್ಯಾಪ್ಟಿವ್ ಪೋರ್ಟಲ್‌ಗಳು ತಮ್ಮದೇ ಸಾಲಿಗೆ ಅರ್ಹ. ಹೋಟೆಲ್ ಮತ್ತು ವಿಮಾನ ನಿಲ್ದಾಣದ Wi-Fi ನಿಯಮ ಅವಲಂಬಿಸಿರುವ ಹುಡುಕಾಟವನ್ನೇ ತಡೆಯುತ್ತದೆ. ಪೋರ್ಟಲ್ ಸಾಧನವನ್ನು ಒಳಗೆ ಬಿಡುವವರೆಗೆ ಟನೆಲ್‌ನ DNS ಸರ್ವರ್ ತಲುಪಲಾಗದು, ಪ್ರೋಬ್ ವಿಫಲವಾಗುತ್ತದೆ, ಮತ್ತು ವೈಫಲ್ಯ ತಪ್ಪಾಗಿ ಬರೆದ ಡೊಮೇನ್‌ನಂತೆ ಕಾಣುತ್ತದೆ. ದೃಢೀಕರಣ ಇನ್ನೊಂದು ಮೌನ ಸಂದರ್ಭ: ನಿಯಮ ಪ್ರಚೋದಿಸಬಹುದು, ಟನೆಲ್ ಸಂಪರ್ಕಿಸಲು ಪ್ರಾರಂಭಿಸಬಹುದು, ಮತ್ತು ಸಂಪರ್ಕ ಅವಧಿ ಮುಗಿದ ಪ್ರಮಾಣಪತ್ರದಲ್ಲಿ ಅಥವಾ ಇನ್ನೊಂದು ಡಿಸ್‌ಪ್ಲೇಯಲ್ಲಿ ಕಾಣುವ ಪ್ರಾಂಪ್ಟ್‌ನಲ್ಲಿ ಸಾಯುತ್ತದೆ.
IPv6 ಸುಲಭವಾಗಿ ತಪ್ಪು ನಿರ್ಣಯಿಸಬಹುದಾದ ರೂಪಾಂತರವನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ. ಎರಡೂ ವಿಳಾಸ ಕುಟುಂಬಗಳಿರುವ ಹೆಸರಿಗೆ ಮೊದಲು AAAA ದಾಖಲೆಯಿಂದ ಉತ್ತರ ನೀಡಬಹುದು, ಆದರೆ ಟನೆಲ್‌ನ ಮಾರ್ಗ ಪಟ್ಟಿ IPv4 ಮಾತ್ರ ಸಾಗಿಸುತ್ತದೆ. ಒಂದು ಬ್ರೌಸರ್ ಯಶಸ್ವಿಯಾಗುತ್ತದೆ, ಇನ್ನೊಂದು ವಿಫಲವಾಗುತ್ತದೆ, ಮತ್ತು ಡೊಮೇನ್ ಪಟ್ಟಿ ಸಂಪೂರ್ಣ ನಿರ್ದೋಷಿ.
ನಿಜವಾದ ವಿನಂತಿಯೊಂದಿಗೆ, ಈ ಕ್ರಮದಲ್ಲಿ ಪರೀಕ್ಷಿಸಿ
ಊಹಿಸುವ ಮೊದಲು ನೀತಿ ಓದಿ. macOS ನಲ್ಲಿ sudo profiles show -type configuration VPN payload ಸೇರಿದಂತೆ ಸ್ಥಾಪಿತ ಪ್ರೊಫೈಲ್‌ಗಳನ್ನು ಮುದ್ರಿಸುತ್ತದೆ, scutil --nc list ಸೇವೆಯ ಸ್ಥಿತಿ ತೋರಿಸುತ್ತದೆ, ಮತ್ತು scutil --nc show <service> ಸಿಸ್ಟಂ ಬಳಸುವ on-demand ನಿಘಂಟನ್ನು ಮುದ್ರಿಸುತ್ತದೆ. ನಿರ್ವಹಿತ iPhone ಅಥವಾ iPad ನಲ್ಲಿ ಅದೇ payload ನಿರ್ವಹಣಾ ಕನ್ಸೋಲ್ ಅಥವಾ MDM ವರದಿಯಿಂದ ಬರುತ್ತದೆ. ನೆಟ್‌ವರ್ಕಿಂಗ್ ಲಾಗ್‌ಗಳು macOS ನಲ್ಲಿ log stream --predicate 'subsystem == "com.apple.networkextension"' ನೊಂದಿಗೆ, ಮತ್ತು ಫೋನ್ ಸಂಪರ್ಕಗೊಂಡಾಗ ಸಾಧನ ಕನ್ಸೋಲ್ ಮೂಲಕ ಲಭ್ಯ.
ನಂತರ ಈ ಅಧಿವೇಶನದಲ್ಲಿ ಮೊದಲು ಕೇಳದ ಹೋಸ್ಟ್‌ನಾಮದೊಂದಿಗೆ ಪರೀಕ್ಷಿಸಿ. ಟನೆಲ್‌ನ DNS ವಲಯದಲ್ಲಿ ಆಂತರಿಕವಾಗಿ ಪರಿಹರಿಸುತ್ತದೆ ಎಂದು ನಿಮಗೆ ತಿಳಿದಿರುವ ಹೆಸರನ್ನು ಆರಿಸಿ, ಒಮ್ಮೆ ಕೇಳಿ, ಮತ್ತು ಟನೆಲ್ ಕಾಣಿಸುತ್ತದೆಯೇ ಎಂದು ನೋಡಿ. ಅದೇ ಹುಡುಕಾಟವನ್ನು ಎರಡು ಬಾರಿ ಚಲಾಯಿಸಿ: ಎರಡನೇ ಪ್ರಯತ್ನ ಕ್ಯಾಶ್ ಮಾರ್ಗವನ್ನು ಅಭ್ಯಾಸ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಎರಡರ ನಡುವಿನ ವ್ಯತ್ಯಾಸ ಟ್ರಿಗರ್ ಪರಿಹಾರವೋ ಮಾರ್ಗನಿರ್ದೇಶನವೋ ಎಂದು ಹೇಳುತ್ತದೆ.
ಟನೆಲ್ ಮೇಲೆ ಬಂದ ಮೇಲೆ ಎರಡು ಪದರಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರಿಶೀಲಿಸಿ. netstat -rn -f inet ಮತ್ತು netstat -rn -f inet6 ಪ್ರತಿ ಪ್ರಿಫಿಕ್ಸ್ ಎಲ್ಲಿಗೆ ತೋರಿಸುತ್ತದೆ ಎಂದು ತೋರಿಸುತ್ತವೆ, scutil --dns ರಿಸಾಲ್ವರ್ ಕ್ರಮ ಮತ್ತು ಯಾವ ಇಂಟರ್ಫೇಸ್ ಯಾವ ರಿಸಾಲ್ವರ್ ಹೊಂದಿದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ, ಮತ್ತು nettop -m route ಯಾವ ಇಂಟರ್ಫೇಸ್ ಬೈಟ್‌ಗಳನ್ನು ಸಾಗಿಸಿತು ಎಂದು ತೋರಿಸುತ್ತದೆ. ಟನೆಲ್ ಮೇಲಿದ್ದು ರಿಸಾಲ್ವರ್ ಸರಿಯಾಗಿದ್ದರೂ ಸಂಪನ್ಮೂಲ ವಿಫಲವಾದರೆ, ನಿಯಮ ಸಂಪಾದಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ; ಸರ್ವರ್-ಸೈಡ್ ಅನುಮತಿ ಮತ್ತು ಹಿಂತಿರುಗುವ ಮಾರ್ಗವನ್ನು ಪರಿಶೀಲಿಸಿ.
ನಿಯಮ ಬೇರೊಬ್ಬರದ್ದಾದಾಗ
ಸಂಪರ್ಕ ಕಡಿತಗೊಳಿಸಿದ ನಂತರ ಟನೆಲ್ ಮತ್ತೆ ಕಾಣಿಸಿದರೆ, ನಿಯಮ ಸಾಮಾನ್ಯವಾಗಿ ಆ್ಯಪ್‌ನದಲ್ಲ, ಪ್ರೊಫೈಲ್‌ನದು: MDM ಮೂಲಕ ತಳ್ಳಿದ ಸಂರಚನೆ, ಉಳಿದಿರುವ ವೈಯಕ್ತಿಕ ಪ್ರೊಫೈಲ್, ಅಥವಾ ಇನ್ನೊಂದು ಕ್ಲೈಂಟ್ ಸ್ಥಾಪಿಸಿದ ಪ್ರೊಫೈಲ್. sudo profiles show -type configuration ಮತ್ತು on-demand ಕೀಗಳ ಹುಡುಕಾಟ ಅದನ್ನು ಸಂಕುಚಿಸುತ್ತದೆ, ಮತ್ತು ತೆಗೆದುಹಾಕುವ ಮಾರ್ಗ ಪ್ರೊಫೈಲ್, ಮೆನು ಬಾರ್‌ನ ಟೋಗಲ್ ಅಲ್ಲ. ಸೇವಾ ನಮೂದು ಅಥವಾ ಆ್ಯಪ್ ಅಳಿಸಿದರೆ ನಿಯಮ ಉಳಿಯುತ್ತದೆ, ಮತ್ತು ಮುಂದಿನ ಸ್ಥಾಪನೆ ಅದನ್ನು ಮತ್ತೆ ಬಳುವಳಿಯಾಗಿ ಪಡೆಯುತ್ತದೆ.
ಒಂದು ಪರೀಕ್ಷೆ ಮಾಲೀಕತ್ವವನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ: ಸಂಪರ್ಕ ಕಡಿತಗೊಳಿಸಿ, ಕಾಯಿರಿ, ಆಂತರಿಕ ಹೆಸರನ್ನು ಮತ್ತೆ ಕೇಳಿ. ಟನೆಲ್ ಮರಳಿದರೆ, ಟ್ರಿಗರ್ ವಿನ್ಯಾಸದಂತೆ ಕೆಲಸ ಮಾಡುತ್ತಿದೆ ಮತ್ತು ತೆರೆದ ಪ್ರಶ್ನೆ ಎಂದರೆ ಅದನ್ನು ಯಾರು ನಿರ್ವಹಿಸುತ್ತಾರೆ ಮತ್ತು ಆ ವ್ಯಾಪ್ತಿಯೇ ನೀವು ಬಯಸುವುದು.
ಇದನ್ನು ದೋಷ ಎಂದು ದಾಖಲಿಸುವ ಮೊದಲು ಅದೇ ಐದು ಪರಿಶೀಲನೆಗಳನ್ನು ಮಾಡಿ: payload ನಲ್ಲಿ ಟನೆಲ್ ರಿಸಾಲ್ವರ್ ವಿಳಾಸಗಳಿವೆ, ಹೆಸರು ಕ್ಯಾಶ್ ಆಗಿಲ್ಲ, ಹಿಂದಿನ ಯಾವುದೇ ನಿಯಮ ಈಗಾಗಲೇ ಹೊಂದಿಲ್ಲ, ಮಾರ್ಗ ಪಟ್ಟಿ AAAA ಮಾರ್ಗವನ್ನು ಆವರಿಸುತ್ತದೆ, ಮತ್ತು ಆ್ಯಪ್ ಟನೆಲ್ ವ್ಯಾಪ್ತಿಯಲ್ಲಿದೆ. ಐದೂ ಸರಿಯಿದ್ದರೆ ನಿಯಮ ತನ್ನ ಕೆಲಸ ಮಾಡುತ್ತಿದೆ ಮತ್ತು ದೋಷ ಮಾರ್ಗದಲ್ಲಿ ಮುಂದಿದೆ.