ನಿರ್ವಹಿತ iPhone ಅಪ್ಲಿಕೇಶನ್ಗಳಲ್ಲಿ ಪ್ರತಿ-ಅಪ್ಲಿಕೇಶನ್ VPN: ಯಾವುದು ಮಾರ್ಗವಾಗುತ್ತದೆ ಮತ್ತು ಯಾವುದು ಇಲ್ಲ
ಪ್ರತಿ-ಅಪ್ಲಿಕೇಶನ್ ಟನೆಲ್ ನಿರ್ವಹಿತ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಅನುಸರಿಸುತ್ತದೆ, ಫೋನ್ ಅನ್ನಲ್ಲ. ಪೇಲೋಡ್ ಸಂಬಂಧ, ನಿರ್ವಹಿತ ಪ್ರತಿ, ಬೇಡಿಕೆಯ ಮೇಲಿನ ನಿಯಮಗಳು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ನಿಂದ ಹೊರಬರುವ ಹರಿವುಗಳನ್ನು ಪರಿಶೀಲಿಸಿ.
iPhone ನಲ್ಲಿ ಪ್ರತಿ-ಅಪ್ಲಿಕೇಶನ್ VPN ಇಡೀ ಫೋನ್ನ ಸ್ವಿಚ್ ಅಲ್ಲ. ಇದು ಒಂದು ನಿರ್ವಹಿತ ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ಒಂದು VPN ಪೇಲೋಡ್ ನಡುವಿನ ಸಂಬಂಧ, ಅಪ್ಲಿಕೇಶನ್ ನಿಯೋಜಿಸಿದಾಗ ರಚನೆಯಾಗುತ್ತದೆ, ಮತ್ತು ಉಳಿದ ಎಲ್ಲದರ ಸಂಚಾರ ಹಿಂದಿನ ಮಾರ್ಗವನ್ನೇ ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ. ಆದ್ದರಿಂದ ಅದೇ ಫೋನ್ ಅಸಂಗತವಾಗಿ ವರ್ತಿಸುತ್ತದೆ: ಕೆಲಸದ ಅಪ್ಲಿಕೇಶನ್ ಖಾಸಗೀ ಪುಟ ತೆರೆಯುತ್ತದೆ ಆದರೆ Safari ಅದೇ ಹೋಸ್ಟ್ ತಲುಪಲಾರದು, ಅಥವಾ ಟನೆಲ್ ಎಂದಿಗೂ ಮೇಲೇರದು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಕೆಟ್ಟ ರುಜುವಾತುಗಳಂತೆ ಕಾಣುವ ಸಮಯ ಮೀರುವಿಕೆಯನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ. ಪರಿಶೀಲನೆಗಳು ಅಗಲವಾದ ಕಾರಣದಿಂದ ಕೆಳಗೆ ಹೋಗುತ್ತವೆ, ಆದ್ದರಿಂದ ವಿಫಲವಾದ ಮೊದಲನೇದರಲ್ಲೇ ನಿಲ್ಲಿಸಿ.
ಮೊದಲು ಪೇಲೋಡ್ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ದಾಖಲೆಯನ್ನು ಪರಿಶೀಲಿಸಿ
ಸಂಬಂಧ ಎರಡು ವಸ್ತುಗಳಲ್ಲಿ ಇರುತ್ತದೆ, ಒಂದರಲ್ಲ. VPN ಪೇಲೋಡ್ ಟನೆಲ್ ಅನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ: ಪ್ರಕಾರ, ಸರ್ವರ್, ದೃಢೀಕರಣ, DNS ಮತ್ತು ಕಸ್ಟಮ್ ಕ್ಲೈಂಟ್ ಬಳಸಿದಾಗ ಪೂರೈಕೆದಾರರ ಬಂಡಲ್ ಗುರುತಿಸುವಿಕೆ. ಅಪ್ಲಿಕೇಶನ್ ದಾಖಲೆ ಆ ಪೇಲೋಡ್ಗೆ ಸೂಚಿಸುತ್ತದೆ, ಮತ್ತು ಹೆಚ್ಚಿನ ನಿರ್ವಹಣಾ ಕನ್ಸೋಲ್ಗಳು ಇದನ್ನು ಅಪ್ಲಿಕೇಶನ್ ಸಂರಚನೆಯಲ್ಲಿ ಪ್ರತಿ-ಅಪ್ಲಿಕೇಶನ್ ಆಯ್ಕೆಯಾಗಿ, Per-App VPN ಗೆ ಹತ್ತಿರವ ಹೆಸರಿನಲ್ಲಿ ನೀಡುತ್ತವೆ. ಯಾವ ಅಪ್ಲಿಕೇಶನ್ ಸೂಚಿಸದ ಪೇಲೋಡ್ ಪ್ರತಿ-ಅಪ್ಲಿಕೇಶನ್ ಆಗಿ ಯಾವುದನ್ನೂ ಮಾರ್ಗ ಮಾಡುವುದಿಲ್ಲ; ಅದು ಯಾರೋ ಕೈಯಿಂದ ಪ್ರಾರಂಭಿಸಬೇಕಾದ ಸಾಮಾನ್ಯ ಟನೆಲ್ನಂತೆ ವರ್ತಿಸುತ್ತದೆ.
ಫೋನ್ ಮುಟ್ಟುವ ಮೊದಲು ಎರಡೂ ವಸ್ತುಗಳನ್ನೂ ಓದಿ. ಅಪ್ಲಿಕೇಶನ್ ಸಂರಚನೆ ನೀವು ಪರೀಕ್ಷಿಸುತ್ತಿರುವ ಪೇಲೋಡ್ಗೆ ಸೂಚಿಸುತ್ತದೆಯೇ ಮತ್ತು ಅದರ ಹಳೆ ಪ್ರತಿಗೆ ಅಲ್ಲವೇ ಎಂದು ಖಾತ್ರಿಪಡಿಸಿ, ಏಕೆಂದರೆ ಸ್ಥಳಾಂತರದ ನಂತರ ಸುಮಾರು ಒಂದೇ ಹೆಸರಿನ ನಕಲಿ ಪೇಲೋಡ್ಗಳು ಸಾಮಾನ್ಯ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಸಂತೋಷದಿಂದ ಹಿಂತೆಗೆದದ್ದಕ್ಕೆ ಸೂಚಿಸುತ್ತದೆ. ನಂತರ ಸಂರಚನೆ ಸಾಧನವನ್ನು ತಲುಪಿದೆಯೇ ಎಂದು ಖಾತ್ರಿಪಡಿಸಿ: ಸೆಟ್ಟಿಂಗ್ಸ್, ಸಾಮಾನ್ಯ, VPN ಮತ್ತು ಸಾಧನ ನಿರ್ವಹಣೆ ಅದನ್ನು ಸ್ಥಾಪಿತ ಪ್ರೊಫೈಲ್ ಆಗಿ ತೋರಿಸಬೇಕು. ಅಲ್ಲಿನ VPN ಪಟ್ಟಿ ಪರೀಕ್ಷೆ ಅಲ್ಲ. ಪ್ರತಿ-ಅಪ್ಲಿಕೇಶನ್ ಸೇವೆಗೆ ಸಾಮಾನ್ಯವಾಗಿ ಕೈ ಸ್ವಿಚ್ ಇರುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಸರಿಯಾಗಿ ನಿಯೋಜಿತ ಸಂರಚನೆ ಪ್ರಾರಂಭಿಸಬಹುದಾದ VPN ಗಳ ನಡುವೆ ಎಂದಿಗೂ ಕಾಣಿಸದಿರಬಹುದು. ಅನುಪಸ್ಥಿತಿ ಅಪ್ಲಿಕೇಶನ್ ದಾಖಲೆಯಲ್ಲಿ ಮತ್ತು ಟನೆಲ್ ಅಪ್ಲಿಕೇಶನ್ನ ಮೊದಲ ವಿನಂತಿಯಲ್ಲಿ ಮೇಲೇರುತ್ತದೆಯೇ ಎಂಬುದರಲ್ಲಿ ಕಾಣುತ್ತದೆ.
ಒಂದು ಷರತ್ತು ಅನೇಕ ಟಿಕೆಟ್ಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ: ಈ ಮಾದರಿಗೆ ಅಪ್ಲಿಕೇಶನ್ ನಿರ್ವಹಣೆಯ ಮೂಲಕ ಬರಬೇಕು. ಪಕ್ಕದಿಂದ ಸ್ಥಾಪಿಸಿದ ಅಥವಾ ವೈಯಕ್ತಿಕವಾಗಿ ಖರೀದಿಸಿದ ಪ್ರತಿ ಸಂಬಂಧವನ್ನು ಪಡೆಯುವುದಿಲ್ಲ, ಅದರ ಬಂಡಲ್ ಗುರುತಿಸುವಿಕೆ ಹೊಂದಿದರೂ. VPN ಗಾಗಿ Apple ನ ನಿಯೋಜನಾ ಮಾರ್ಗದರ್ಶಿ ಇದರ ಹಿಂದಿನ ಪೇಲೋಡ್ ಮಾದರಿಯನ್ನು ವಿವರಿಸುತ್ತದೆ (support.apple.com/guide/deployment/vpn-overview-depae3d361d0/web).
ಸ್ಥಾಪಿತ ಅಪ್ಲಿಕೇಶನ್ ನಿರ್ವಹಿತ ಪ್ರತಿಯೇ ಎಂದು ಖಾತ್ರಿಪಡಿಸಿ
ಸಂಬಂಧ ಸ್ಥಾಪಿತ, ನಿರ್ವಹಿತ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಅನುಸರಿಸುತ್ತದೆ. ಯಾರಾದರೂ ಅದನ್ನು ವೈಯಕ್ತಿಕ Apple ID ಜೊತೆಯಿಂದ App Store ನಿಂದ ಮರುಸ್ಥಾಪಿಸಿದರೆ, ಮರುಸಹಿ ಮಾಡಿದ ಎಂಟರ್ಪ್ರೈಝ್ ಬಿಲ್ಡ್ನಿಂದ ಬದಲಿಸಿದರೆ, ಅಥವಾ ಸಾಧನ ಮತ್ತೆ ನೋಂದಣೆಯಾಗಿ ಅಪ್ಲಿಕೇಶನ್ ಬೇರೆ ಚ್ಯಾನಲ್ ಮೂಲಕ ಮರಳಿದರೆ, ಅಪ್ಲಿಕೇಶನ್ ಸಂಪೂರ್ಣ ಸಾಮಾನ್ಯವಾಗಿ ಕಾಣುತ್ತಿದ್ದರೂ ಟನೆಲ್ ಕೆಳಗೆ ಉಳಿಯಬಹುದು.
ಹೋಲಿಕೆಯಿಂದ ಪರೀಕ್ಷಿಸಿ, ಒಂದೇ ಅವಲೋಕನದಿಂದ ಅಲ್ಲ. ನಿರ್ವಹಣಾ ದಾಖಲೆಯಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ ಆ ಸಾಧನಕ್ಕೆ ನಿರ್ವಹಿತ ಎಂದು ಅದರ ದಾಖಲೆಯಲ್ಲಿ VPN ಮ್ಯಾಪಿಂಗ್ನೊಂದಿಗೆ ಕಾಣಬೇಕು. ಫೋನ್ನಲ್ಲಿ ಟನೆಲ್ ಅಪ್ಲಿಕೇಶನ್ ಪ್ರಾರಂಭವಾದಾಗ ಮತ್ತು ಅದರ ಮೊದಲ ವಿನಂತಿ ಹೊರಬನ್ದಾಗ ಮೇಲೇರಬೇಕು, ಯಾರಾದರೂ ಸೆಟ್ಟಿಂಗ್ಸ್ನಲ್ಲಿ ಪ್ರತ್ಯೇಕ ಕೈ ಸಂರಚನೆ ಪ್ರಾರಂಭಿಸಿದಾಗ ಮಾತ್ರವಾಗಿಯಲ್ಲ. ಅಪ್ಲಿಕೇಶನ್ ಪ್ರಾರಂಭಿಸಿದರೆ ಯಾವುದೂ ಬದಲಾಗದಿದ್ದರೆ ಮತ್ತು ಆ ಕೈ ಸಂರಚನೆ ಬದಲಾದರೆ, ಅಪ್ಲಿಕೇಶನ್ ಪ್ರತಿ-ಅಪ್ಲಿಕೇಶನ್ ಟನೆಲ್ಗೆ ಸಂಪೂರ್ಣವಾಗಿ ಬದ್ಧವಾಗಿಲ್ಲ.
ನವೀಕರಣಗಳು ಮುಖ್ಯ: ನಿರ್ವಹಣೆಯ ಮೂಲಕ ತಳ್ಳಿದ ನವೀಕರಣ ಮ್ಯಾಪಿಂಗ್ ಉಳಿಸುತ್ತದೆ, ಬಳಕೆದಾರ ಪ್ರಾರಂಭಿಸಿದ ಮರುಸ್ಥಾಪನೆ ಅದನ್ನು ಕಳೆದುಕೊಳ್ಳಬಹುದು. ದೂರು ನವೀಕರಣದಿಂದ ದಿನಾಂಕಿತವಾಗಿದ್ದರೆ, ನೆಟ್ವರ್ಕ್ಗಿಂತ ಮೊದಲು ಅಪ್ಲಿಕೇಶನ್ ದಾಖಲೆ ಪರಿಶೀಲಿಸಿ.
ಟನೆಲ್ ಏನನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು ಎಂದು ಪರಿಶೀಲಿಸಿ
ಪ್ರತಿ-ಅಪ್ಲಿಕೇಶನ್ ಟನೆಲ್ ಮೂಲ ಅಪ್ಲಿಕೇಶನ್ನಿಂದ ಆಯ್ಕೆಯಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಫೋನ್ನ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗ ಇನ್ನೂ Wi-Fi ಅಥವಾ ಸೆಲ್ಯುಲಾರ್ಗೆ ಸೇರಿದೆ. OverridePrimary ಅದನ್ನು ಬದಲಿಸುವ ಕೀ. ಪ್ರೊಫೈಲ್ ಅದನ್ನು ಹೊಂದಿಸಿದಾಗ, ಟನೆಲ್ ಪೂರ್ಣ ಟನೆಲ್ನಂತೆ ವರ್ತಿಸುತ್ತದೆ ಮತ್ತು ಪ್ರತಿ ಅಪ್ಲಿಕೇಶನ್ ಅದನ್ನು ಪಡೆದುಕೊಳ್ಳುತ್ತದೆ, ಆದ್ದರಿಂದ VPN ಮೂಲಕ ಹೋಗುವ ಎಲ್ಲವೂ ಅಪ್ಲಿಕೇಶನ್ ವೈಫಲ್ಯವಲ್ಲ, ಪ್ರೊಫೈಲ್ ಪ್ರಶ್ನೆಯಾಗುತ್ತದೆ.
ಬೇಡಿಕೆಯ ಮೇಲಿನ ನಿಯಮಗಳು ಸ್ಥಿರತೆಯನ್ನು ನಿರ್ಧಾರಿಸುತ್ತವೆ. OnDemandEnabled ಮತ್ತು ಅದರ ನಿಯಮ ಸಮೂಹ ಟನೆಲ್ ಅಪ್ಲಿಕೇಶನ್ ಸಂಚಾರ ಕಳುಹಿಸಿದಾಗ ಮರಳಿಸುತ್ತದೆ, Wi-Fi ನಿಂದ ಸೆಲ್ಯುಲಾರ್ಗೆ ಬದಲಾವಣೆಯನ್ನು ತಟ್ಟಿಕೊಳ್ಳುತ್ತದೆ, ಅಥವಾ ಅಪ್ಲಿಕೇಶನ್ ಹಿನ್ನೆಲೆಗೆ ಹೋದಾಗ ಇಳಿಯುತ್ತದೆ. ಸಂಪರ್ಕಗೊಂಡು ನಂತರ ಸದ್ದಿಲ್ಲದೆ ಸಾಯುವ ನಿಯೋಜನೆಗೆ ಸಾಮಾನ್ಯವಾಗಿ ಅಪ್ಲಿಕೇಶನ್ ನಿಷ್ಕ್ರಿಯವಾಗಿರುವಾಗ ಎಂದಿಗೂ ಚಲನೆಯಾಗದ ಪ್ರೋಬ್ಗೆ ಮಾತ್ರ ಹೊಂದುವ ನಿಯಮ ಇರುತ್ತದೆ.
ನಂತರ ಮಾರ್ಗದ ಬದಿಯನ್ನು ಪ್ರಾಮಾಣಿಕವಾಗಿ ಓದಿ. ಪೂರೈಕೆದಾರ ಅಥವಾ ಮಾರಾಟಗಾರ ಪ್ರೊಫೈಲ್ ಸೇರ್ಪಡೆ ಪಟ್ಟಿ ನೀಡಿದರೆ, 10.20.0.0/16 ಮಾತ್ರ ಹೊತ್ತ ಟನೆಲ್ 10.30.0.0/16 ನಲ್ಲಿನ ಸೇವೆಯನ್ನು ಹೊತ್ತೊಯ್ಯುವುದಿಲ್ಲ; ಅದು ಪಟ್ಟಿ ತನ್ನ ಕೆಲಸ ಮಾಡುತ್ತಿದೆ, ಪ್ರತಿ-ಅಪ್ಲಿಕೇಶನ್ ವೈಫಲ್ಯ ಅಲ್ಲ. ಒಳಗೊಂಡ iOS ಪೇಲೋಡ್ಗೆ ಸೇರ್ಪಡೆ ಪಟ್ಟಿ ಇಲ್ಲ. ಅದಿಲ್ಲದೆ ವಿಭಜನೆ ಪೂರೈಕೆದಾರರ ಡೀಫಾಲ್ಟ್ಗಳು ಮತ್ತು IncludeAllNetworks ಅನ್ನು ಅನುಸರಿಸುತ್ತದೆ, ಗುಪ್ತ ಪಟ್ಟಿಯನ್ನಲ್ಲ.
ಅಪ್ಲಿಕೇಶನ್ ಪರೀಕ್ಷಿಸಿ, ನಂತರ ಅದರಿಂದ ಏನು ಹೊರಬರುತ್ತದೆ ಎಂದು ಪರೀಕ್ಷಿಸಿ
ಹೆಸರಿನಿಂದ ಪರೀಕ್ಷಿಸಿ, ಕೇವಲ ವಿಳಾಸದಿಂದ ಅಲ್ಲ. ನಿರ್ವಹಿತ ಅಪ್ಲಿಕೇಶನ್ ಒಳಗೆ ಆಂತರಿಕ ಹೋಸ್ಟ್ ಬಗೆಹರಿಯುವುದು DNS ಸಹ ಟನೆಲ್ ಮೂಲಕ ಹೋಯಿತು ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಪೇಲೋಡ್ ಯಾವ ರಿಜಾಲ್ವರ್ ಉತ್ತರಿಸುತ್ತದೆ ಮತ್ತು ಯಾವ ಹುಡುಕಾಟ ಡೊಮೆಯಿನ್ಗಳು ಅನ್ವಯಿಸುತ್ತವೆ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ. ಹೆಸರು ಹುಡುಕಾಟ ವಿಫಲವಾದರೂ ಮಾರ್ಗದರ್ಶನ ಪರಿಪೂರ್ಣವಾಗಿರಬಹುದು, ಮತ್ತು ಎರಡು ಲಕ್ಷಣಗಳು ಬೇರೆ ಬೇರೆ ಸೆಟ್ಟಿಂಗ್ಸ್ಗೆ ಸೂಚಿಸುತ್ತವೆ.
ನಂತರ ಎರಡೂ ಕಡೆಯಿಂದ ಗಡಿಯನ್ನು ಪರೀಕ್ಷಿಸಿ. ವೈಯಕ್ತಿಕ ಅಪ್ಲಿಕೇಶನ್ ಅಥವಾ Safari ಸಾಮಾನ್ಯ ಸಾರ್ವಜನಿಕ ಪುಟ ತಲುಪಿ ಆಫರೇಟರ್ ಅಥವಾ ಮನೆಯ ವಿಳಾಸ ವರದಿ ಮಾಡಬೇಕು, ಆದರೆ ನಿರ್ವಹಿತ ಅಪ್ಲಿಕೇಶನ್ ಖಾಸಗೀ ಸೇವೆ ತಲುಪುತ್ತದೆ. ಎರಡೂ ಒಂದೇ ಸಾರ್ವಜನಿಕ ವಿಳಾಸ ವರದಿ ಮಾಡಿದರೆ, ಅಪ್ಲಿಕೇಶನ್ ದಾಖಲೆ ಏನೇ ಹೇಳಿಕೊಂಡರೂ ಟನೆಲ್ ಇನ್ನು ಪ್ರತಿ-ಅಪ್ಲಿಕೇಶನ್ ಅಲ್ಲ.
ಅಪ್ಲಿಕೇಶನ್ ಬಿಟ್ಟು ಹೋಗುವ ಹರಿವುಗಳು ಗೊಂದಲದ ಟಿಕೆಟ್ಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತವೆ. Safari ನಲ್ಲಿ ತೆರೆಯುವ ಲಿಂಕ್, ಹಂಚಿಕೆ ಹಾಳೆಯ ಮೂಲಕ ಕಳುಹಿಸಿದ ದಾಖಲೆ, ಅಥವಾ ಬ್ರೌಝರ್ಗೆ ಬದಲಾಗುವ SSO ಲಾಗಿನ್ ಅಪ್ಲಿಕೇಶನ್ ಪ್ರಕ್ರಿಯೆ ಮತ್ತು ಅದರೊಂದಿಗೆ ಟನೆಲ್ ಬಿಟುತ್ತವೆ. ಅಪ್ಲಿಕೇಶನ್ ಒಳಗೆ ತೋರಿಸಿದ ಲಾಗಿನ್ ಸಾಮಾನ್ಯವಾಗಿ ಅಪ್ಲಿಕೇಶನ್ಗೆಯೇ ಆರೋಪಿಸಲಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದೇ URL Safari ನಲ್ಲಿ ವಿಫಲವಾಗುವಲ್ಲಿ ಎಂಬೆಡೆಡ್ ಸೈನ್-ಇನ್ ಯಶಸ್ವಿಯಾಗಬಹುದು; ಅದನ್ನು ಊಹಿಸದೆ ಪರಿಶೀಲಿಸಿ. ಗುರುತು ಪೂರೈಕೆದಾರರು ಟನೆಲ್ ಮೂಲಕವೇ ತಲುಪಲು ಬಹುದಾದರೆ, ಲಾಗಿನ್ ಅನ್ನು ಅಪ್ಲಿಕೇಶನ್ ಒಳಗೆ ಇರಿಸಿ ಅಥವಾ ಪೂರೈಕೆದಾರರ ಡೊಮೆಯಿನ್ ಅನ್ನು ಪೇಲೋಡ್ನ Safari ಡೊಮೆಯಿನ್ಗಳಿಗೆ ಸೇರಿಸಿ, ಹೊಂದುವ Safari ಸಂಚಾರ ಸೆರೆಹಿಡಿಯಲ್ಲಿ.
ಲಕ್ಷಣವನ್ನು ಪದರಕ್ಕೆ ಹೊಂದಿಸಿ
ವೈಫಲ್ಯದ ಆಕೃತಿ ಯಾವ ಪರಿಶೀಲನೆ ಪುನರಾವರ್ತಿಸಬೇಕು ಎಂದು ಹೇಳುತ್ತದೆ.
| What you see | Where the repair is |
|---|---|
| Tunnel never appears when the app opens | App-to-payload association, or the app is not the managed copy |
| Tunnel connects, internal name resolves, connection times out | Provider or vendor include list missing the subnet, or a far-side firewall |
| Tunnel connects, internal name fails to resolve | DNS servers or search domains in the payload |
| Every app uses the tunnel | OverridePrimary set, or a full-tunnel payload reused |
| Worked until an update, broken since | Association lost on reinstall, or the payload was replaced |
ಮಧ್ಯದ ಸಾಲುಗಳ ಹಿಂದೆ ಎರಡು ವಿವರಗಳಿವೆ: ಪ್ರತಿ-ಅಪ್ಲಿಕೇಶನ್ ಟನೆಲ್ ಆರೋಗ್ಯಕರವಾಗಿದ್ದರೂ ಯಾವುದೇ ಪೂರೈಕೆದಾರ ಪಟ್ಟಿಯಲ್ಲಿ ಇಲ್ಲದ ಉಪಮಾರ್ಗವನ್ನು ತಪ್ಪಬಹುದು, ಮತ್ತು ನಿರ್ವಹಿತ ಫೋನ್ ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು VPN ಸಂರಚನೆಗಳನ್ನು ಇರಿಸಿಕೊಳ್ಳಬಹುದು, ಆದ್ದರಿಂದ ಅಪ್ಲಿಕೇಶನ್ ಯಾವುದಕ್ಕೆ ಬದ್ಧವಾಗಿದೆ ಎಂದು ಖಾತ್ರಿಪಡಿಸಿ, ನೀವು ಓದುತ್ತಿರುವುದೇ ಅದು ಎಂದು ಊಹಿಸಬೇಡಿ.
ಈ ಕ್ರಮದಲ್ಲಿ ಸರಿಪಡಿಸಿ: ಅಪ್ಲಿಕೇಶನ್ ದಾಖಲೆಯನ್ನು ಜೀವಂತ ಪೇಲೋಡ್ಗೆ ಸೂಚಿಸುವಂತೆ ಸರಿಪಡಿಸಿ, ನಿರ್ವಹಣೆಯ ಮೂಲಕ ಅಪ್ಲಿಕೇಶನ್ ಮರುಸ್ಥಾಪಿಸಿ, ಟನೆಲ್ ಅಪ್ಲಿಕೇಶನ್ನ ಮೊದಲ ವಿನಂತಿಯಲ್ಲಿ ಮೇಲೇರುತ್ತದೆ ಎಂದು ಖಾತ್ರಿಪಡಿಸಿ, ನಂತರ ಹೆಸರು ಮತ್ತು ಗಡಿ ಪರೀಕ್ಷೆಗಳನ್ನು ಪುನರಾವರ್ತಿಸಿ. ಮೊದಲ ವಿನಂತಿ ಟನೆಲ್ ಪ್ರಾರಂಭಿಸಲೇ ಆಗದಿದ್ದರೆ, ನಿಲ್ಲಿಸಿ ಪೂರೈಕೆದಾರರ ಬದಿ ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಕಸ್ಟಮ್ ಕ್ಲೈಂಟ್ಗೆ Network Extension ಇರುವುದು ಮತ್ತು ಅದರ ಗುರುತಿಸುವಿಕೆ ಸ್ಥಾಪಿತ ಅಪ್ಲಿಕೇಶನ್ಗೆ ಹೊಂದುವುದು ಅಗತ್ಯ.
ಸ್ಕ್ರೀನ್ಶಾಟ್ ಬದಲು ಮೂರು ಸತ್ಯಗಳನ್ನು ಹಿಂತಿರುಗಿಸಿ: ಅಪ್ಲಿಕೇಶನ್ ದಾಖಲೆ ಯಾವ ಪೇಲೋಡ್ಗೆ ಸೂಚಿಸುತ್ತದೆ, ಸೆಟ್ಟಿಂಗ್ಸ್ ಅದನ್ನು ಸ್ಥಾಪಿತ ಪ್ರೊಫೈಲ್ ಆಗಿ ತೋರಿಸುತ್ತವೇ, ಮತ್ತು ವಿಫಲವಾದ ವಿನಂತಿ ಏನಾಗಿತ್ತು — ಹೆಸರು, ವಿಳಾಸ ಅಥವಾ ಬ್ರೌಝರ್ಗೆ ಹಸ್ತಾಂತರ. ಈ ಮೂರು ಉತ್ತರಗಳು ನಿಯೋಜನಾ ತಪ್ಪನ್ನು ಮಾರ್ಗದರ್ಶನ ತಪ್ಪಿನಿಂದ ಬೇರ್ಪಡಿಸುತ್ತವೆ, ಮತ್ತು ಮುಂದಿನ ವ್ಯಕ್ತಿ ರೋಗನಿರ್ಣಯ ಪುನರಾವರ್ತಿಸದೆ ಕೆಲಸ ಮಾಡಬಹುದು.