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 ਖੇਤਰ ਟਨਲ ਦੇ ਅੰਦਰਲੀਆਂ ਐਪਾਂ ਲਈ ਹੈ, ਕਲਾਇੰਟ ਦੇ ਆਪਣੇ ਐਂਡਪੁਆਇੰਟ ਲਈ ਨਹੀਂ।
- ਸਿਰਫ਼ ਟਨਲ ਰਾਹੀਂ ਪਹੁੰਚਯੋਗ ਰਿਜ਼ੋਲਵਰ ਅਟਕਾਅ ਹੈ, ਹੌਲੀ ਸ਼ੁਰੂਆਤ ਨਹੀਂ।
- ਰੀਬੂਟ ਤੋਂ ਬਾਅਦ ਐਂਡਪੁਆਇੰਟ, ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ ਨਿੱਜੀ ਖੋਜ ਵੱਖਰੇ ਤੌਰ ਤੇ ਟੈਸਟ ਕਰੋ।