Android always-on VPN: ಎಂಡ್‌ಪಾಯಿಂಟ್ ಹೆಸರು ಮೊದಲು ಹೇಗೆ ಪರಿಹರಿಸುತ್ತದೆ
Android ಟನೆಲ್ ಇರುವ ಮೊದಲೇ ಸಂಚಾರವನ್ನು ನಿರ್ಬಂಧಿಸುತ್ತದೆ, ಆದರೂ ಕ್ಲೈಂಟ್ ತನ್ನ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಅನ್ನು ಇನ್ನೂ ಪರಿಹರಿಸಬೇಕು. ಇಲ್ಲಿ ಕ್ರಮ ಮತ್ತು ಅದು ಎಲ್ಲಿ ಸಿಕ್ಕಿಹಾಕಿಕೊಳ್ಳುತ್ತದೆ.
ಫೋನ್ ಮರುಬೂಟ್ ಆಗುತ್ತದೆ, always-on ಸಕ್ರಿಯವಾಗಿದೆ, «VPN ಇಲ್ಲದೆ ಸಂಪರ್ಕಗಳನ್ನು ನಿರ್ಬಂಧಿಸು» ಆನ್ ಆಗಿದೆ, ಆದರೆ ಟನೆಲ್ ಎಂದಿಗೂ ಬರುತ್ತಿಲ್ಲ. ಯಾವುದೇ ತಪ್ಪು ಕಾನ್ಫಿಗರೇಶನ್ ಇಲ್ಲ: ನಿರ್ಬಂಧವು ತನ್ನ ಕೆಲಸ ಮಾಡುತ್ತಿದೆ, ಮತ್ತು ಕ್ಲೈಂಟ್‌ನ ಸ್ವಂತ ಪ್ರಯತ್ನವೂ ಅದಕ್ಕೆ ಒಳಪಟ್ಟಿದೆ. ಎಂಡ್‌ಪಾಯಿಂಟ್ ಹೆಸರನ್ನು ಟನೆಲ್ ಇರುವ ಮೊದಲೇ ಪರಿಹರಿಸಬೇಕು, ಇತರ ಎಲ್ಲಾ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಅನುಮತಿ ಇಲ್ಲದಿರುವಾಗ ನೆಟ್‌ವರ್ಕ್ ಜೊತೆ ಮಾತನಾಡಲು ಅನುಮತಿ ಇರುವ ಕ್ಲೈಂಟ್‌ನಿಂದ. ಯಾವ ಘಟಕ ಇದನ್ನು ಮಾಡುತ್ತದೆ ಮತ್ತು ಯಾವ ಕ್ರಮದಲ್ಲಿ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದೇ ಈ ಒಗಟನ್ನು ಕಾನ್ಫಿಗರೇಶನ್ ಪ್ರಶ್ನೆಯಾಗಿ ಬದಲಿಸುತ್ತದೆ.
VPN ಬಿಲ್ಡರ್ ನಿಜವಾಗಿ ಏನನ್ನು ಕೇಳುತ್ತದೆ
Android VPN ಅಪ್ಲಿಕೇಶನ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗೆ ಸರ್ವರ್ ವಿಳಾಸವನ್ನು ನೀಡುವುದಿಲ್ಲ. ಅದು ಸ್ಥಳೀಯ ಇಂಟರ್‌ಫೇಸ್ ನಿರ್ಮಿಸುತ್ತದೆ: ಟನೆಲ್‌ನ ವಿಳಾಸಗಳು ಮತ್ತು ಮಾರ್ಗಗಳು, ಅದರ ಒಳಗೆ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಬಳಸಬೇಕಾದ ರೆಸಾಲ್ವರ್‌ಗಳು, ನಂತರ establish() ಒಂದು ಫೈಲ್ ಡಿಸ್ಕ್ರಿಪ್ಟರ್ ಮರಳಿಸುತ್ತದೆ, ಅದನ್ನು ಅಪ್ಲಿಕೇಶನ್ ಕಚ್ಚಾ IP ಪ್ಯಾಕೆಟ್‌ಗಳಾಗಿ ಓದುತ್ತದೆ ಮತ್ತು ಬರೆಯುತ್ತದೆ. ದೂರದ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಆ ಬಿಲ್ಡರ್‌ನಲ್ಲಿ ಎಲ್ಲೂ ಕಾಣಿಸುವುದಿಲ್ಲ.
ಇದೇ ಪ್ರಮುಖ ರಚನಾತ್ಮಕ ಸತ್ಯ. ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ tun ಇಂಟರ್‌ಫೇಸ್ ರಚಿಸಿ ಅದರ ಮೇಲೆ ನೀತಿ ಜಾರಿಗೊಳಿಸುತ್ತದೆ; ಅಪ್ಲಿಕೇಶನ್ ಬಳಕೆದಾರ ಸ್ಥಳದಲ್ಲಿ ಸಾಗಣೆಯನ್ನು ಜಾರಿಗೊಳಿಸುತ್ತದೆ, ಅಂದರೆ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಹೆಸರನ್ನು ಪರಿಹರಿಸುವುದೂ ಗೂಢಲಿಪೀಕೃತ ಸಂಪರ್ಕ ತೆರೆಯುವುದೂ ಅಪ್ಲಿಕೇಶನ್‌ನದೇ ಕೆಲಸ. ಆದ್ದರಿಂದ ಹೋಸ್ಟ್‌ನಾಮ್ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಸಾಧ್ಯ — ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಹೆಸರುಗಳನ್ನು ಬೆಂಬಲಿಸುವುದರಿಂದಲ್ಲ, ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಅನ್ನು ಎಂದಿಗೂ ನೋಡುವುದಿಲ್ಲ ಎಂಬುದರಿಂದ.
ಬಿಲ್ಡರ್‌ನ ಒಂದು ಕ್ಷೇತ್ರ ಮಾತ್ರ ವಿಳಾಸಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ: DNS ಸರ್ವರ್‌ಗಳು. ಅವು ಸಂಖ್ಯಾತ್ಮಕ ರೆಸಾಲ್ವರ್ ವಿಳಾಸಗಳಾಗಿರಬೇಕು, ಸಾಮಾನ್ಯವಾಗಿ ಆಪರೇಟರ್ ಟನೆಲ್ ಮೂಲಕ ಕೇಳಲು ಬಯಸುವವು. ಆ ಕ್ಷೇತ್ರವು ಟನೆಲ್ ಬಂದ ನಂತರ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಪ್ರಶ್ನೆಗಳನ್ನು ಎಲ್ಲಿಗೆ ಕಳುಹಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತದೆ. ಕ್ಲೈಂಟ್ ತನ್ನ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಅನ್ನು ಹೇಗೆ ಕಂಡುಕೊಳ್ಳುತ್ತದೆ ಎಂಬುದರ ಬಗ್ಗೆ ಅದು ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ, ಮತ್ತು ಈ ಎರಡನ್ನೂ ಒಂದೇ ಸೆಟ್ಟಿಂಗ್ ಎಂದು ಪರಿಗಣಿಸುವುದೇ ಗೊಂದಲದ ಆರಂಭ.
ಒಂದಲ್ಲ, ಎರಡು DNS ಪ್ರಶ್ನೆಗಳು
ಮೊದಲ ಪ್ರಶ್ನೆ: ಟನೆಲ್ ಬಂದ ನಂತರ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಪ್ರಶ್ನೆಗಳನ್ನು ಎಲ್ಲಿಗೆ ಕಳುಹಿಸುತ್ತವೆ? ಉತ್ತರ ಟನೆಲ್ ಒಳಗಿನ ರೆಸಾಲ್ವರ್ ವಿಳಾಸ, tun ಇಂಟರ್‌ಫೇಸ್ ಮೂಲಕ ತಲುಪಬಹುದಾದದ್ದು, ಮತ್ತು ರಚನೆಯಿಂದಲೇ ಸಂಖ್ಯಾತ್ಮಕ.
ಎರಡನೇ ಪ್ರಶ್ನೆ: ಆ ಟನೆಲ್ ಇರುವ ಮೊದಲು ಕ್ಲೈಂಟ್ ತನ್ನದೇ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಅನ್ನು ಹೇಗೆ ಕಂಡುಕೊಳ್ಳುತ್ತದೆ? ಆ ಹುಡುಕಾಟ ಟನೆಲ್‌ನ ಹೊರಗೆ, ಮೂಲ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ, ಕ್ಲೈಂಟ್ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ನಡೆಯುತ್ತದೆ. ಅದು ಹೆಸರನ್ನು ಬಳಸಬಹುದು, ಮತ್ತು VPN ಇಲ್ಲದೆ ಸಾಧನ ತಲುಪಬಲ್ಲ ರೆಸಾಲ್ವರ್ ಅನ್ನು ಬಳಸಬೇಕು.
| Stage | Who resolves | Path | Failure looks like |
|---|---|---|---|
| Endpoint lookup | The VPN app | Underlying network, protected socket | Never connects; no tunnel interface traffic |
| Peer authentication | Client and server | Tunnel transport | Connects then drops; certificate or key error |
| Private name lookup | Apps via the tunnel | Resolver inside the tun | Tunnel up, internal sites do not resolve |
ಮೂರು ಹಂತಗಳು, ಮೂರು ವಿಭಿನ್ನ ಲಕ್ಷಣಗಳು. «ಸಂಪರ್ಕಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ» ಎಂಬ ಒಂದೇ ದೋಷ ಸಂದೇಶ ಅವುಗಳನ್ನು ಒಟ್ಟಿಗೆ ಸೇರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಜನರು ಆ ಕ್ಷೇತ್ರವನ್ನು ಓದುವ ಮೊದಲೇ ಸಂಭವಿಸುವ ಸಮಸ್ಯೆಯನ್ನು ಸರಿಪಡಿಸಲು DNS ಸರ್ವರ್ ಕ್ಷೇತ್ರವನ್ನು ಸಂಪಾದಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ.
bootstrap ಏಕೆ ಸಿಕ್ಕಿಹಾಕಿಕೊಳ್ಳಬಹುದು
always-on ನಿರ್ಬಂಧ ಸಕ್ರಿಯವಾಗಿದ್ದರೆ VPN ಒಳಗಿಲ್ಲದ ಸಂಚಾರವು ತಿರಸ್ಕೃತವಾಗುತ್ತದೆ, VPN ಹೊಂದಿರುವ ಅಪ್ಲಿಕೇಶನ್‌ನ ಸಂಚಾರವೂ ಸೇರಿ. ಹೊರಬರುವ ದಾರಿ ಸ್ಪಷ್ಟವಾಗಿದೆ: ಅಪ್ಲಿಕೇಶನ್ ಸಾಕೆಟ್‌ನಲ್ಲಿ protect() ಕರೆಯುತ್ತದೆ, ಅದು ಅದನ್ನು ಮೂಲ ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಬಂಧಿಸುತ್ತದೆ, ಹೀಗಾಗಿ ಅದು ಟನೆಲ್ ಬಳಸದೆ ಹೊರಹೋಗಲು ಅನುಮತಿ ಪಡೆಯುತ್ತದೆ. ಪ್ರತಿ VPN ಕ್ಲೈಂಟ್ ತನ್ನ ಸಾಗಣೆಗಾಗಿ ಇದನ್ನು ಮಾಡಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ ಸರ್ವರ್ ತಲುಪಲು ಸಾಧ್ಯವಿಲ್ಲ.
ಈಗ, ಎಂಡ್‌ಪಾಯಿಂಟ್ ಹೆಸರನ್ನು ತಿಳಿದಿರುವ ಏಕೈಕ ರೆಸಾಲ್ವರ್ ಸ್ವತಃ ಟನೆಲ್ ಒಳಗಿರುವ ನಿಯೋಜನೆಯನ್ನು ಪರಿಗಣಿಸಿ. ಹೆಸರನ್ನು ಪರಿಹರಿಸಲು ಕ್ಲೈಂಟ್‌ಗೆ ಟನೆಲ್ ಬೇಕು, ಟನೆಲ್ ಕಟ್ಟಲು ಹೆಸರು ಬೇಕು. ಇದು ನಿಜವಾದ ಚಕ್ರಾಕಾರ ಅವಲಂಬನೆ, ಮತ್ತು ಯಾವ ಕ್ಲೈಂಟ್ ಕಾನ್ಫಿಗರೇಶನ್ ಇದನ್ನು ಪರಿಹರಿಸುವುದಿಲ್ಲ. ಇದು ವಿನ್ಯಾಸ ದೋಷ, ಬಗ್ ಅಲ್ಲ.
ಸಮಯ ಅದೇ ಅವಲಂಬನೆಯನ್ನು ಮೃದು ರೂಪಗಳಲ್ಲಿ ಬಯಲಿಸುತ್ತದೆ. ಬೂಟ್ ಆಗುವಾಗ, ಮೊದಲ ಅನ್‌ಲಾಕ್ ಮೊದಲು, ಸಾಧನಕ್ಕೆ ಇನ್ನೂ ಬಳಸಬಹುದಾದ ನೆಟ್‌ವರ್ಕ್ ಇಲ್ಲದಿರಬಹುದು; captive portal ನಲ್ಲಿ ನೆಟ್‌ವರ್ಕ್ ಇದೆ ಆದರೆ ಪೋರ್ಟಲ್ ಹೊರತುಪಡಿಸಿ ಎಲ್ಲವನ್ನೂ ನಿರ್ಬಂಧಿಸುತ್ತದೆ; Wi-Fi ನಿಂದ ಮೊಬೈಲ್‌ಗೆ ಬದಲಾವಣೆಯಲ್ಲಿ ಸಂರಕ್ಷಿತ ಸಾಕೆಟ್‌ನ ಮೂಲ ನೆಟ್‌ವರ್ಕ್ ಬದಲಾಗುತ್ತದೆ ಮತ್ತು ಕ್ಲೈಂಟ್ ಅದನ್ನು ಗಮನಿಸಿ ಮತ್ತೆ ಪರಿಹರಿಸಬೇಕು. ಇವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದೂ bootstrap ಘಟನೆ, ಮತ್ತು ಪ್ರತಿಯೊಂದನ್ನೂ ರಾತ್ರಿ 3 ಗಂಟೆಗೆ ಕಂಡುಕೊಳ್ಳುವ ಬದಲು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಪರೀಕ್ಷಿಸುವುದು ಯೋಗ್ಯ.
ಉತ್ತರವನ್ನು ಸ್ಥಿರಗೊಳಿಸುವುದು ಏಕೆ ಪರಿಹಾರವಲ್ಲ
ಪ್ರಲೋಭನೆಯ ತಿರುಗು ದಾರಿ ಎಂದರೆ ಹೆಸರನ್ನು ಒಮ್ಮೆ ಪರಿಹರಿಸಿ ಬಂದ ವಿಳಾಸವನ್ನು ಸಂಖ್ಯಾತ್ಮಕ ಕ್ಷೇತ್ರಕ್ಕೆ ಅಂಟಿಸುವುದು, ಅಥವಾ ಕಸ್ಟಮ್ ಬಿಲ್ಡ್‌ನಲ್ಲಿ ಹಾರ್ಡ್‌ಕೋಡ್ ಮಾಡುವುದು. ಅದು ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ತೋರುತ್ತದೆ, ಮತ್ತು ಹೆಸರನ್ನು ಸ್ನ್ಯಾಪ್‌ಶಾಟ್ ಆಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ. ಆಪರೇಟರ್ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಅನ್ನು ಸರಿಸಿದಾಗ — ವಲಸೆ, anycast ಬದಲಾವಣೆ, ಹೊಸ ಪ್ರಾದೇಶಿಕ ವಿಳಾಸ — ಕ್ಲೈಂಟ್ ಹಳೆಯದನ್ನೇ ಕರೆಯುತ್ತಲೇ ಇರುತ್ತದೆ ಮತ್ತು UI ನಲ್ಲಿ ಏನೂ ಕಾರಣವನ್ನು ವಿವರಿಸುವುದಿಲ್ಲ.
DNS ದಾಖಲೆಗಳಿಗೆ ಜೀವಿತಾವಧಿ ಇರುವುದು ಉತ್ತರಗಳು ಬದಲಾಗಬಹುದು ಎಂಬುದಕ್ಕೇ; ಕ್ಯಾಶಿಂಗ್ ಆ ಅವಧಿಯ ಆಧಾರದಲ್ಲಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾಗುತ್ತದೆ, ಶಾಶ್ವತವಾಗಿ ಅಲ್ಲ. ಉತ್ತರವನ್ನು ಸ್ಥಿರಗೊಳಿಸುವುದು ಹೆಸರನ್ನು ವಿಳಾಸಕ್ಕಿಂತ ಉತ್ತಮವಾಗಿಸುವ ಕಾರ್ಯವಿಧಾನವನ್ನು ಬಿಸಾಡುತ್ತದೆ, ಜೊತೆಗೆ ಹೆಸರು ಬಳಸಿದ್ದರ ಕಾರ್ಯಾಚರಣಾ ವೆಚ್ಚವನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ.
ಸ್ಥಿರಗೊಳಿಸುವಿಕೆ ಸಾಮಾನ್ಯವಾಗಿ ಎರಡನೇ ಕೆಟ್ಟ ಅಭ್ಯಾಸದೊಂದಿಗೆ ಬರುತ್ತದೆ: ಸಂಪರ್ಕ ಈಗ ಬೇರೆ ರೀತಿಯಲ್ಲಿ ವಿಫಲವಾಗುವುದರಿಂದ ಗುರುತಿನ ಪರಿಶೀಲನೆಯನ್ನು ಸಡಿಲಗೊಳಿಸುವುದು. ಸರ್ವರ್ ಗುರುತಿನ ಪರಿಶೀಲನೆ bootstrap ಸಮಸ್ಯೆಯ ಭಾಗವಲ್ಲ, ಮತ್ತು ಅದನ್ನು ದುರ್ಬಲಗೊಳಿಸುವುದು DNS ಅಸೌಕರ್ಯವನ್ನು ಪ್ರತಿಬಂಧದ ಅಪಾಯಕ್ಕೆ ಬದಲಿಸುತ್ತದೆ.
ಮರುಬೂಟ್ ಅನ್ನು ತಾಳುವ ವಿನ್ಯಾಸಗಳು
ಟಿಕಾಯುವ ವ್ಯವಸ್ಥೆ ಆಕರ್ಷಕವಲ್ಲ. ಸಂರಕ್ಷಿತ ಸಾಕೆಟ್‌ಗಳನ್ನು ಸರಿಯಾಗಿ ಜಾರಿಗೊಳಿಸಿ ತನ್ನ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಅನ್ನು ಮೂಲ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಪರಿಹರಿಸುವ ಕ್ಲೈಂಟ್ ಬಳಸಿ, ಮತ್ತು ಸಾರ್ವಜನಿಕವಾಗಿ ಅಥವಾ ಟನೆಲ್‌ಗೆ ಮೊದಲು ತಲುಪಬಹುದಾದ ರೆಸಾಲ್ವರ್ ಮೂಲಕ ಪರಿಹರಿಸುವ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಹೆಸರು ನೀಡಿ. ನಿರ್ಬಂಧವನ್ನು ಆನ್ ಆಗಿಡಿ; DNS ಕೆಲಸ ಮಾಡಲಿ ಎಂದು ಅದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಆಫ್ ಮಾಡುವುದು ನಿಯೋಜನೆ ಇರುವುದಕ್ಕೆ ಕಾರಣವಾದ ಗುಣವನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ.
ಎಂಡ್‌ಪಾಯಿಂಟ್ ಖಾಸಗಿಯಾಗಿ ಉಳಿಯಬೇಕಾದಲ್ಲಿ, ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಬಳಸಬಹುದಾದ ಸ್ಪಷ್ಟ bootstrap ಮಾರ್ಗವನ್ನು ಒದಗಿಸಿ — ಟನೆಲ್ ಇಲ್ಲದೆ ತಲುಪಬಹುದಾದ ರೆಸಾಲ್ವರ್, ಅಥವಾ ಆಪರೇಟರ್ ನಿರ್ವಹಿಸುವ ನಿರ್ವಹಣಾ ಸಂಪರ್ಕ — ಮತ್ತು ಆ ವಿನಾಯಿತಿಯನ್ನು ಸಣ್ಣದಾಗಿ ಇರಿಸಿ, ಬಳಕೆದಾರರ ಟಾಗಲ್‌ಗೆ ಅಲ್ಲ, ನೀತಿಗೆ ಸೇರಿದ್ದಾಗಿಸಿ. Android VpnService ದಾಖಲೆಗಳು ರಕ್ಷಣೆ ಮತ್ತು ಜೀವನಚಕ್ರದ ಬಗ್ಗೆ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಏನನ್ನು ಖಾತರಿಪಡಿಸುತ್ತದೆ ಎಂಬುದರ ಉಲ್ಲೇಖ, ಮತ್ತು VpnService.Builder ಉಲ್ಲೇಖ DNS ಕ್ಷೇತ್ರವು ಸಂಖ್ಯಾತ್ಮಕ ವಿಳಾಸಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂದು ದೃಢೀಕರಿಸುತ್ತದೆ.
ನಂತರ ಮರುಬೂಟ್ ನಂತರದ ಹೊಸ ಸಂಪರ್ಕದಲ್ಲಿ ಮೂರು ಹಂತಗಳನ್ನು ಕ್ರಮವಾಗಿ ಪರಿಶೀಲಿಸಿ: ಎಂಡ್‌ಪಾಯಿಂಟ್ ಹೆಸರು ಪರಿಹರಿಸುತ್ತದೆ, ಟನೆಲ್ ಸ್ಥಾಪನೆಯಾಗಿ ಸಹಚರ ದೃಢೀಕರಿಸುತ್ತದೆ, ಮತ್ತು ಖಾಸಗಿ ಹೆಸರು ಟನೆಲ್‌ನ ರೆಸಾಲ್ವರ್ ಮೂಲಕ ಪರಿಹರಿಸುತ್ತದೆ. ಮೊದಲ ಹಂತ ವಿಫಲವಾದರೆ ಮುಂದಿನ ಯಾವುದೂ ಕೆಲಸ ಮಾಡದು, ಮತ್ತು ಸರಿಪಡಿಸುವಿಕೆ bootstrap ಮಾರ್ಗಕ್ಕೆ ಸೇರಿದ್ದು — ಎಂದಿಗೂ ರೆಸಾಲ್ವರ್ ಕ್ಷೇತ್ರಕ್ಕಲ್ಲ.
- ಎಂಡ್‌ಪಾಯಿಂಟ್ ಪರಿಹಾರ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ, ಟನೆಲ್‌ನ ಹೊರಗೆ, ಸಂರಕ್ಷಿತ ಸಾಕೆಟ್‌ನಲ್ಲಿ ನಡೆಯುತ್ತದೆ.
- ಬಿಲ್ಡರ್‌ನ DNS ಕ್ಷೇತ್ರ ಟನೆಲ್ ಒಳಗಿನ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ, ಕ್ಲೈಂಟ್‌ನ ಸ್ವಂತ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಲ್ಲ.
- ಟನೆಲ್ ಮೂಲಕ ಮಾತ್ರ ತಲುಪಬಹುದಾದ ರೆಸಾಲ್ವರ್ ಸಿಕ್ಕಿಹಾಕಿಕೊಳ್ಳುವಿಕೆ, ನಿಧಾನ ಆರಂಭವಲ್ಲ.
- ಮರುಬೂಟ್ ನಂತರ ಎಂಡ್‌ಪಾಯಿಂಟ್, ದೃಢೀಕರಣ ಮತ್ತು ಖಾಸಗಿ ಹುಡುಕಾಟವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರೀಕ್ಷಿಸಿ.