Android VPN ਪੂਰਾ ਹੋਸਟਨਾਮ ਹੱਲ ਕਰਦਾ ਹੈ, ਛੋਟਾ ਨਾਮ ਨਹੀਂ

ਤੁਸੀਂfilesਟਰਮੀਨਲ ਐਮੂਲੇਟਰ ਵਿੱਚ ਲਿਖਦੇ ਹੋ ਅਤੇ ਕੁਝ ਵਾਪਸ ਨਹੀਂ ਆਉਂਦਾ; ਤੁਸੀਂfiles.corp.exampleਲਿਖਦੇ ਹੋ ਅਤੇ ਉਹੀ ਸਰਵਰ ਤੁਰੰਤ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। VPN ਪਹਿਚਾਣ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਬਦਲਿਆ, ਅਤੇ ਨਿੱਜੀ DNS ਸਰਵਰ ਕਦੇ ਖਰਾਬ ਨਹੀਂ ਹੋਇਆ। Android ਵਿੱਚ ਛੋਟਾ ਲੇਬਲ ਅਤੇ ਪੂਰਾ ਨਾਮ ਰਿਜ਼ੋਲਵਰ ਰਾਹੀਂ ਵੱਖਰੇ ਰਾਹਾਂ ਤੋਂ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਇਨ੍ਹਾਂ ਰਾਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਉਸ ਸੈਟਿੰਗ ਉੱਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਜੋ ਟਨਲ ਦੇ ਮਾਲਕ ਨੂੰ ਦੇਣੀ ਪੈਂਦੀ ਹੈ। ਤੁਹਾਡੇ ਸਾਹਮਣੇ ਫ਼ੈਸਲਾ ਇਹ ਨਹੀਂ ਕਿ ਕਿਹੜਾ DNS ਸਰਵਰ ਬਦਲਣਾ ਹੈ, ਸਗੋਂ ਇਹ ਹੈ ਕਿ ਐਪ ਜੋ ਨੈੱਟਵਰਕ ਅਸਲ ਵਿੱਚ ਵਰਤ ਰਹੀ ਹੈ ਉਸਨੂੰ ਕੌਣ ਕੰਟਰੋਲ ਕਰਦਾ ਹੈ।

ਖੋਜ ਡੋਮੇਨ ਪਤਾ ਨਹੀਂ ਹੈ। ਇਹ ਉਹਨਾਂ ਪ੍ਰਤਿਯਾਂ ਦੀ ਸੂਚੀ ਹੈ ਜੋ ਰਿਜ਼ੋਲਵਰ ਨੰਗੇ ਲੇਬਲ ਨਾਲ ਜੋੜ ਕੇ ਫਿਰ ਹਾਰ ਮੰਨਦਾ ਹੈ।

ਖੋਜ ਪ੍ਰਤਿਯ ਅਤੇ DNS ਸਰਵਰ ਵੱਖਰੇ ਖੇਤਰ ਹਨ

ਰਿਜ਼ੋਲਵਰ ਦਾ ਪਤਾ Android ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿੱਥੇ ਪੁੱਛਣਾ ਹੈ। ਖੋਜ ਪ੍ਰਤਿਯ ਦੱਸਦਾ ਹੈ ਕਿ ਜਦੋਂ ਤੁਸੀਂ ਸਿਰਫ਼ ਖੱਬਾ ਲੇਬਲ ਦਿੰਦੇ ਹੋ ਤਾਂ ਕੀ ਪੁੱਛਣਾ ਹੈ। ਦੋਵੇਂ ਇੱਕੋ ਨੈੱਟਵਰਕ ਆਬਜੈਕਟ ਉੱਤੇ ਰਹਿੰਦੇ ਹਨ, ਅਤੇ ਕੋਈ ਵੀ ਇਕੱਲਾ ਗੁੰਮ ਹੋ ਸਕਦਾ ਹੈ।

ਇਹੀ ਆਜ਼ਾਦੀ ਦੱਸਦੀ ਹੈ ਕਿ ਪੂਰਾ ਹੋਸਟਨਾਮ ਕਿਉਂ ਕੰਮ ਕਰਦਾ ਹੈ। ਪੂਰੀ ਤਰ੍ਹਾਂ ਯੋਗ ਨਾਮ ਨੂੰ ਪ੍ਰਤਿਯ ਦੀ ਲੋੜ ਨਹੀਂ, ਕਿਉਂਕਿ ਉਹ ਪਹਿਲਾਂ ਹੀ ਸਰਵਰ ਵੱਲ ਜਾਣ ਵਾਲੀ ਸਟ੍ਰਿੰਗ ਹੈ।

Android ਇਹ ਵੰਡLinkPropertiesਰਾਹੀਂ ਦਿਖਾਉਂਦਾ ਹੈ। DNS ਸਰਵਰਾਂ ਦੀ ਸੂਚੀ ਅਤੇ ਡੋਮੇਨ ਖੋਜ ਸੂਚੀ ਇੱਕੋ ਆਬਜੈਕਟ ਉੱਤੇ ਹਨ, ਅਤੇ ਪਹਿਲੀ ਪੂਰੀ ਭਰੀ ਹੋਣ ਪਰ ਵੀ ਦੂਜੀ ਆਮ ਤੌਰ ਉੱਤੇ ਖਾਲੀ ਹੁੰਦੀ ਹੈ। ਰਿਜ਼ੋਲਵਰ ਹੋਣ ਪਰ ਡੋਮੇਨ ਨਾ ਹੋਣ ਵਾਲਾ ਨੈੱਟਵਰਕ ਉਹ ਨੈੱਟਵਰਕ ਹੈ ਜਿੱਥੇ ਪ੍ਰਤਿਯ ਕਦੇ ਲਾਗੂ ਨਹੀਂ ਹੋਇਆ — ਉਹ ਸਰਵਰ ਨਹੀਂ ਜਿਸਨੇ ਛੋਟਾ ਨਾਮ ਰੱਦ ਕੀਤਾ।

ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰਭਾਵੀ ਨੈੱਟਵਰਕ ਪੜ੍ਹੋ

Wi-Fi, ਮੋਬਾਈਲ ਨੈੱਟਵਰਕ ਅਤੇ VPN ਇੰਟਰਫ਼ੇਸ ਤਿੰਨ ਵੱਖਰੇ ਨੈੱਟਵਰਕ ਹਨ, ਅਤੇ ਟਨਲ ਉੱਪਰ ਆਉਣ ਨਾਲ ਹੀ ਡਿਫ਼ਾਲਟ ਬਣ ਜਾਂਦਾ ਹੈ। ਇਸ ਲਈ ਦਫ਼ਤਰ ਦੇ Wi-Fi ਉੱਤੇ ਕੰਮ ਕਰਨ ਵਾਲਾ ਪ੍ਰਤਿਯ ਟਨਲ ਸਰਗਰਮ ਹੋਣ ਵੇਲੇ ਲਾਗੂ ਪ੍ਰਤਿਯ ਨਹੀਂ ਹੁੰਦਾ। ਐਪ ਅਸਲ ਵਿੱਚ ਜਿਸ ਨੈੱਟਵਰਕ ਉੱਤੇ ਚੁਣੀ ਹੋਈ ਹੈ ਉਹ ਵੇਖੋ, ਪਿਛਲੇ ਹਫ਼ਤੇ ਤੁਸੀਂ ਜੋ ਸੈੱਟ ਕੀਤਾ ਸੀ ਉਹ ਨਹੀਂ।

ਡਿਵਾਈਸ ਉੱਤੇ ਟਰਮੀਨਲ ਸ਼ੈੱਲ ਇੱਥੇ ਕਮਜ਼ੋਰ ਗਵਾਹ ਹੈ, ਕਿਉਂਕਿ ਇਸਦਾresolv.confਹਰ ਐਪ ਦਾ ਨਜ਼ਰੀਆ ਨਹੀਂ, ਰਿਜ਼ੋਲਵਰ ਦਾ ਇੱਕ ਨਜ਼ਰੀਆ ਹੀ ਦਰਸਾਉਂਦਾ ਹੈ।

ਬ੍ਰਾਊਜ਼ਰਾਂ ਦੀਆਂ ਪਤਾ ਪੱਟੀਆਂ ਇੱਕ ਹੋਰ ਪਰਤ ਜੋੜਦੀਆਂ ਹਨ: ਨੰਗੇ ਸ਼ਬਦ ਨੂੰ ਖੋਜ ਕੁਐਰੀ ਮੰਨਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਜਾਂ ਇਸ ਰਾਹੀਂ ਹੱਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈਬ੍ਰਾਊਜ਼ਰ ਦੀ ਆਪਣੀ ਐਨਕ੍ਰਿਪਟਿਡ-DNS ਨੀਤੀ, ਇਸ ਲਈ Chrome ਵਿੱਚ ਖੁੱਲ੍ਹਣ ਵਾਲਾ ਪੰਨਾ ਸਿਸਟਮ ਲੁੱਕਅਪ ਬਾਰੇ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ। ਪਲੇਟਫ਼ਾਰਮ ਰਿਜ਼ੋਲਵਰ ਵਰਤਣ ਵਾਲੀ ਅਤੇ ਕੀ ਵਾਪਸ ਆਇਆ ਛਾਪਣ ਵਾਲੀ ਕਿਸੇ ਚੀਜ਼ ਨਾਲ ਜਾਂਚ ਕਰੋ। ਫਿਰ ਛੋਟਾ ਰੂਪ ਅਤੇ ਪੂਰਾ ਰੂਪ ਇੱਕੋ ਸੈਸ਼ਨ ਵਿੱਚ, ਇੱਕੋ ਨੈੱਟਵਰਕ ਉੱਤੇ ਚਲਾਓ, ਅਤੇ ਨੋਟ ਕਰੋ ਕਿ ਕਿਸਨੇ ਜਵਾਬ ਦਿੱਤਾ।

ਜੇ ਤੁਸੀਂ VPN ਐਪ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਬਿਲਡਰ ਵਿੱਚ ਹੀ ਪ੍ਰਤਿਯ ਜੋੜੋ

ਜਦੋਂ ਤੁਹਾਡੀ ਐਪ ਇੰਟਰਫ਼ੇਸVpnServiceਰਾਹੀਂ ਸਥਾਪਤ ਕਰਦੀ ਹੈ,addSearchDomainਤਾਂ ਇਹ ਇਸ ਲਈ ਸਮਰਥਿਤ ਇਨਪੁਟ ਹੈ। ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਦੀ ਡੋਮੇਨ ਸਟ੍ਰਿੰਗ ਲੈਂਦਾ ਹੈcorp.example, ਅਤੇ ਇਹ ਸਰਵਰ ਪਤਾ ਭੇਜਣ ਦਾ ਬਦਲਵਾਂ ਤਰੀਕਾ ਨਹੀਂ ਹੈ।

ਇਹ ਕਾਲ ਪ੍ਰਤਿਯ ਨੂੰ ਉਸ ਨੈੱਟਵਰਕ ਨਾਲ ਬੰਨ੍ਹਦੀ ਹੈ ਜੋ ਤੁਸੀਂ ਬਣਾ ਰਹੇ ਹੋ, ਇਸ ਲਈ ਬਾਅਦ ਵਿੱਚ ਪਲਟਣ ਲਈ ਕੋਈ ਗਲੋਬਲ ਸੈਟਿੰਗ ਨਹੀਂ। ਜੇ ਐਪ ਇੰਟਰਫ਼ੇਸ ਤੋੜ ਕੇ ਦੁਬਾਰਾ ਜੁੜਨ ਵੇਲੇ ਮੁੜ ਬਣਾਉਂਦੀ ਹੈ, ਤਾਂ ਨਵੇਂ ਬਿਲਡਰ ਨੂੰ ਪ੍ਰਤਿਯ ਦੁਬਾਰਾ ਜੋੜਨਾ ਪਵੇਗਾ, ਨਹੀਂ ਤਾਂ ਬਦਲਵਾਂ ਨੈੱਟਵਰਕ ਇਸ ਤੋਂ ਬਿਨਾਂ ਹੀ ਉੱਪਰ ਆ ਜਾਵੇਗਾ।

ਇੱਥੇ ਹੀ ਬਹੁਤ ਸਾਰੇ ਡੈਸਕਟਾਪ ਪ੍ਰੋਫ਼ਾਈਲ ਆਯਾਤ ਇਹ ਖੇਤਰ ਗੁਆ ਦਿੰਦੇ ਹਨ। ਨਿਰਯਾਤਕ ਡੋਮੇਨ ਆਪਣੇ ਮਾਡਲ ਵਿੱਚ ਲਿਖਦਾ ਹੈ, Android ਫ਼ਰੰਟਐਂਡ ਸਿਰਫ਼ ਉਹਨਾਂ ਚੋਣਾਂ ਦਾ ਨਕਸ਼ਾ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਉਹ ਜਾਣਦਾ ਹੈ, ਅਤੇ ਨਤੀਜੇ ਵਜੋਂ ਬਣਿਆ ਇੰਟਰਫ਼ੇਸ ਬਾਕੀ ਹਰ ਪੱਖੋਂ ਸਹੀ ਦਿਸਦਾ ਹੈ। ਲੈਪਟਾਪ ਉੱਤੇ ਚੱਲਣ ਵਾਲਾ ਅਤੇ ਫ਼ੋਨ ਉੱਤੇ ਫੇਲ੍ਹ ਹੋਣ ਵਾਲਾ ਪ੍ਰੋਫ਼ਾਈਲ ਆਮ ਤੌਰ ਉੱਤੇ ਨਕਸ਼ੇਬੰਦੀ ਦੀ ਖਾਲੀ ਥਾਂ ਹੁੰਦਾ ਹੈ, ਪ੍ਰੋਟੋਕਾਲ ਦੀ ਸਮੱਸਿਆ ਨਹੀਂ।

ਜੇ ਤੁਸੀਂ ਸਿਰਫ਼ VPN ਵਰਤਦੇ ਹੋ, ਤਾਂ ਇਹ ਤੁਹਾਡੇ ਸੈੱਟ ਕਰਨ ਦੀ ਚੀਜ਼ ਨਹੀਂ

ਕਲਾਇੰਟ ਪਾਸੇ ਕੋਈ ਸੰਪਾਦਨ ਨਹੀਂ ਜੋ ਪ੍ਰਤਿਯ ਜੋੜੇ, ਅਤੇ ਕੋਈ ਗਲੋਬਲ ਗੁਣ ਵੀ ਨਹੀਂ ਜਿਸਨੂੰ ਬਦਲ ਕੇ ਤੁਸੀਂ ਨਕਲੀ ਬਣਾ ਸਕੋ। ਮੁੱਲ ਟਨਲ ਦਾ ਮਾਲਕ ਦਿੰਦਾ ਹੈ: ਪ੍ਰਬੰਧਿਤ ਕਲਾਇੰਟ ਦੇ ਪ੍ਰੋਫ਼ਾਈਲ ਵਿੱਚ, ਉਸਦੀ ਪਲੇਟਫ਼ਾਰਮ-ਵਾਰ ਨਕਸ਼ੇਬੰਦੀ ਵਿੱਚ, ਜਾਂ ਸਰਵਰ ਜੋ ਭੇਜਦਾ ਹੈ ਉਸ ਰਾਹੀਂ। ਦੱਸੋ ਕਿ ਤੁਸੀਂ ਕਿਸ ਪਲੇਟਫ਼ਾਰਮ ਉੱਤੇ ਹੋ ਅਤੇ ਕਿਹੜਾ ਨਾਮ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਡੈਸਕਟਾਪ ਅਤੇ ਮੋਬਾਈਲ ਫ਼ਰੰਟਐਂਡ ਠੀਕ ਇਸੇ ਖੇਤਰ ਵਿੱਚ ਵੱਖਰੇ ਪੈਂਦੇ ਹਨ।

ਡੈਸਕਟਾਪ ਪ੍ਰੋਫ਼ਾਈਲ ਦੁਬਾਰਾ ਆਯਾਤ ਕਰਨ ਨਾਲ ਮੋਬਾਈਲ ਨਕਸ਼ੇਬੰਦੀ ਬਾਰੇ ਦੁਬਾਰਾ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਹੁੰਦਾ।

ਤਿੰਨ ਸ਼ਰਤਾਂ ਤੈਅ ਕਰਦੀਆਂ ਹਨ ਕਿ ਤੁਹਾਡੇ ਵਿੱਚ ਖ਼ਰਾਬੀ ਹੈ ਜਾਂ ਕੋਈ ਉਡੀਕੀ ਸੀਮਾ। ਪਹਿਲੀ, ਕੀ ਸੰਸਥਾ ਛੋਟੇ ਲੇਬਲ ਨੂੰ ਬਿਲਕੁਲ ਸਮਰਥਿਤ ਨਾਮ ਮੰਨਦੀ ਹੈ, ਜਾਂ ਇਹ ਉਹ ਸਹੂਲਤ ਹੈ ਜੋ ਕਦੇ ਸਿਰਫ਼ ਦਫ਼ਤਰ ਦੇ Wi-Fi ਉੱਤੇ ਹੀ ਚੱਲੀ? ਦੂਜੀ, ਕੀ ਫੇਲ੍ਹ ਹੋ ਰਿਹਾ ਲੁੱਕਅਪ ਬ੍ਰਾਊਜ਼ਰ ਤੋਂ ਆ ਰਿਹਾ ਹੈ, ਜੋ ਸਿਸਟਮ ਰਿਜ਼ੋਲਵਰ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਾਈਪਾਸ ਕਰ ਸਕਦਾ ਹੈ? ਤੀਜੀ, ਕੀ ਛੋਟਾ ਨਾਮ ਟਨਲ ਰਾਹੀਂ ਪਹੁੰਚਣਾ ਚਾਹੀਦਾ ਹੈ, ਜਾਂ ਸਿਰਫ਼ LAN ਤੋਂ? ਜੇ ਆਖ਼ਰੀ ਜਵਾਬ ਸਿਰਫ਼-LAN ਹੈ, ਤਾਂ ਪ੍ਰਤਿਯ ਜੋੜਨ ਨਾਲ ਅਜਿਹਾ ਨਾਮ ਬਣੇਗਾ ਜੋ ਦਫ਼ਤਰ ਤੋਂ ਬਾਹਰ ਹੱਲ ਹੋਵੇਗਾ ਅਤੇ ਫਿਰ ਰੂਟ ਨਹੀਂ ਹੋਵੇਗਾ।

ਜਦੋਂ ਪ੍ਰਤਿਯ ਮੌਜੂਦ ਹੈ ਅਤੇ ਛੋਟੇ ਨਾਮ ਫਿਰ ਵੀ ਫੇਲ੍ਹ ਹੁੰਦੇ ਹਨ

ਜੇ ਡੋਮੇਨ ਖੋਜ ਸੂਚੀ ਪਹਿਲਾਂ ਹੀcorp.exampleਦਿਖਾਉਂਦੀ ਹੈ, ਤਾਂ ਪ੍ਰਤਿਯ ਨੂੰ ਦੋਸ਼ ਦੇਣਾ ਬੰਦ ਕਰੋ। ਵੇਖੋ ਕਿ ਰਿਜ਼ੋਲਵਰ ਵਿਸਤ੍ਰਿਤ ਨਾਮ ਲਈ ਬਿਲਕੁਲ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਕਿਉਂਕਿ ਪ੍ਰਤਿਯ ਸਿਰਫ਼ ਤੁਹਾਡਾ ਪੁੱਛਿਆ ਸਵਾਲ ਬਦਲਦਾ ਹੈ। ਇਹ ਸਰਵਰ ਨੂੰ ਕਦੇ ਵੀ ਉਸ ਜ਼ੋਨ ਲਈ ਅਧਿਕਾਰਤ ਨਹੀਂ ਬਣਾਉਂਦਾ ਜਿਸਨੂੰ ਉਹ ਹੋਸਟ ਨਹੀਂ ਕਰਦਾ।

ਫਿਰ ਰੂਟ ਵੇਖੋ। ਜੋ ਪਤਾ ਹੱਲ ਹੁੰਦਾ ਹੈ ਪਰ ਟਨਲ ਉਸਨੂੰ ਨਹੀਂ ਢੋਂਦਾ, ਉਹ ਜੁੜਨ ਵੇਲੇ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ, ਜੋ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਚੁੱਪਚਾਪ ਹਾਰ ਮੰਨਣ ਵਾਲੀ ਲੁੱਕਅਪ ਫੇਲ੍ਹਤਾ ਵਰਗਾ ਹੀ ਦਿਸਦਾ ਹੈ।

ਸਰਟੀਫ਼ਿਕੇਟ ਆਪਣੇ ਵੱਖਰੇ ਜ਼ਿਕਰ ਦੇ ਹੱਕਦਾਰ ਹਨ। HTTPS ਜਾਂਚ ਤੁਹਾਡੇ ਅਸਲ ਵਿੱਚ ਲਿਖੇ ਹੋਸਟਨਾਮ ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ, ਇਸ ਲਈ ਸਹੀ ਢੰਗ ਨਾਲ ਫੈਲਣ ਵਾਲਾ ਛੋਟਾ ਨਾਮ ਹੈਂਡਸ਼ੇਕ ਵਿੱਚ ਫਿਰ ਵੀfilesਪੇਸ਼ ਕਰਦਾ ਹੈ। ਜੋ ਸਰਟੀਫ਼ਿਕੇਟfiles.corp.exampleਲਈ ਜਾਰੀ ਹੋਇਆ ਹੈ ਉਹ ਇਸ ਲਈ ਵੈਧ ਨਹੀਂ ਹੋਵੇਗਾ, ਅਤੇ ਉਹ ਗਲਤੀ ਸਹੀ ਵਿਵਹਾਰ ਹੈ, ਤੁਹਾਡੀ ਸ਼ੁਰੂਆਤੀ DNS ਸਮੱਸਿਆ ਦਾ ਲੱਛਣ ਨਹੀਂ।

ਹੁਣ ਅੱਗੇ ਕੀ ਕਰਨਾ ਹੈ

ਕੁਝ ਵੀ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਵੰਡ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ: ਪੂਰਾ ਨਾਮ ਹੱਲ ਹੁੰਦਾ ਹੈ, ਛੋਟਾ ਨਹੀਂ, ਉਹੀ ਐਪ, ਉਹੀ ਸੈਸ਼ਨ। ਫਿਰ ਚੁਣਿਆ ਨੈੱਟਵਰਕ ਲੱਭੋ ਅਤੇ ਉਸਦੀ ਡੋਮੇਨ ਖੋਜ ਸੂਚੀ ਰਿਜ਼ੋਲਵਰ ਸੂਚੀ ਦੇ ਨਾਲ ਪੜ੍ਹੋ। ਦੋਹਾਂ ਵਿੱਚੋਂ ਜੋ ਖਾਲੀ ਹੈ, ਉਹ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਸਨੂੰ ਕਦਮ ਚੁੱਕਣੇ ਹਨ — ਤੁਸੀਂ, ਜੇ ਐਪ ਤੁਹਾਡੀ ਹੈ; ਟਨਲ ਆਪਰੇਟਰ, ਜੇ ਨਹੀਂ।

ਅਖ਼ੀਰ ਵਿੱਚ, ਜਿੱਥੇ ਸੁਵਾਹਿਤਾ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਬੁੱਕਮਾਰਕ ਅਤੇ ਕਲਾਇੰਟ ਸੰਰਚਨਾ ਵਿੱਚ ਪੂਰਾ ਸੇਵਾ ਹੋਸਟਨਾਮ ਚੁਣੋ। ਇਹ ਨੈੱਟਵਰਕ ਬਦਲਾਅ ਵਿੱਚ ਟਿਕਦਾ ਹੈ, ਮੋਬਾਈਲ ਫ਼ਰੰਟਐਂਡ ਸ਼ਾਇਦ ਲਾਗੂ ਨਾ ਕਰੇ ਅਜਿਹੀ ਨਕਸ਼ੇਬੰਦੀ ਉੱਤੇ ਨਿਰਭਰ ਨਹੀਂ, ਅਤੇ ਜਿਸ ਨਾਮ ਲਈ ਸਰਟੀਫ਼ਿਕੇਟ ਜਾਰੀ ਹੋਇਆ ਉਸ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ।