OpenVPN route-nopull ਅਸਲ ਵਿੱਚ ਸਰਵਰ ਨੂੰ ਕੀ ਧੱਕਣ ਤੋਂ ਰੋਕਦਾ ਹੈ
route-nopull ਧੱਕੇ ਗਏ ਰੂਟ ਅਤੇ DHCP ਚੋਣਾਂ ਸੁੱਟਦਾ ਹੈ, ਹੈਂਡਸ਼ੇਕ ਨਹੀਂ। ਇਸ, pull-filter ਜਾਂ ਕੁਝ ਵੀ ਨਾ ਹੋਣ ਵਿਚਕਾਰ ਚੁਣੋ, ਫਿਰ ਰੂਟ ਆਪ ਜੋੜੋ।
ਤੁਸੀਂ ਕਲਾਇੰਟ ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ route-nopull ਰੱਖਿਆ ਤਾਂ ਜੋ ਟਨਲ ਤੁਹਾਡਾ ਡਿਫਾਲਟ ਰੂਟ ਨਾ ਨਿਗਲ ਜਾਵੇ, ਅਤੇ ਹੁਣ ਦਫ਼ਤਰ ਦਾ ਸਬਨੈੱਟ ਪਹੁੰਚ ਤੋਂ ਬਾਹਰ ਹੈ ਜਦੋਂ ਕਿ ਕਲਾਇੰਟ ਅਜੇ ਵੀ ਕਹਿੰਦਾ ਹੈ ਕਿ ਉਹ ਜੁੜਿਆ ਹੈ। ਦੋਵੇਂ ਨਿਰੀਖਣ ਸਹੀ ਹਨ, ਅਤੇ ਕੁਝ ਵੀ ਫੇਲ੍ਹ ਨਹੀਂ ਹੋਇਆ। ਇਹ ਫਲੈਗ ਕਲਾਇੰਟ ਨੂੰ ਕਹਿੰਦਾ ਹੈ ਕਿ ਸਰਵਰ ਵੱਲੋਂ ਧੱਕੇ ਜਾਂਦੇ ਰੂਟ ਅਤੇ DHCP ਐਂਟਰੀਆਂ ਛੱਡ ਦੇਵੇ, ਜੋ ਜੋੜਨ ਸਮੇਂ ਬਹੁਤਿਆਂ ਦੀ ਉਮੀਦ ਨਾਲੋਂ ਤੰਗ ਹਦਾਇਤ ਹੈ। ਜੋ ਬਚਦਾ ਹੈ ਉਹ ਕੰਮ ਕਰਦਾ ਟਨਲ ਹੈ, ਬਿਨਾਂ ਇਸ ਰਾਏ ਦੇ ਕਿ ਕਿਹੜੀਆਂ ਮੰਜ਼ਿਲਾਂ ਇਸਨੂੰ ਵਰਤਣ।
ਉਹੀ ਖੱਡ ਇਸ ਲੇਖ ਦਾ ਵਿਸ਼ਾ ਬਣਿਆ ਪੂਰਾ ਫ਼ੈਸਲਾ ਹੈ। ਜਾਂ ਤਾਂ ਸਰਵਰ ਨੈੱਟਵਰਕ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ, ਜਾਂ ਕਲਾਇੰਟ, ਅਤੇ ਫਲੈਗ ਉਹ ਕੰਮ ਤੁਹਾਡੇ ਲਈ ਕੁਝ ਵੀ ਕੀਤੇ ਬਿਨਾਂ ਕਲਾਇੰਟ ਨੂੰ ਸੌਂਪ ਦਿੰਦਾ ਹੈ।
ਜੁੜਨ ਸਮੇਂ ਫਲੈਗ ਕੀ ਬੰਦ ਕਰਦਾ ਹੈ
ਖਿੱਚਣ ਵਾਲਾ OpenVPN ਕਲਾਇੰਟ ਆਮ ਤੌਰ 'ਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਤੋਂ ਬਾਅਦ ਸਰਵਰ ਤੋਂ ਬੰਡਲ ਲੈਂਦਾ ਹੈ: ਰੂਟ, ਡਿਫਾਲਟ ਗੇਟਵੇ ਦਾ ਮੁੜ-ਨਿਰਦੇਸ਼ਨ, DNS ਸਰਵਰ ਅਤੇ ਕੁਝ ਟਿਊਨਿੰਗ ਹਦਾਇਤਾਂ। route-nopull ਲਾਗੂ ਹੋਣ 'ਤੇ ਵੀ ਕਲਾਇੰਟ ਸੈਸ਼ਨ ਸਵੀਕਾਰਦਾ ਹੈ, ਸਰਟੀਫਿਕੇਟ ਜਾਂਚਦਾ ਹੈ, ਸਾਈਫਰ ਅਤੇ keepalive 'ਤੇ ਗੱਲਬਾਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਇੰਟਰਫੇਸ ਉੱਪਰ ਚੁੱਕਦਾ ਹੈ। ਜੋ ਸੁੱਟਦਾ ਹੈ ਉਹ ਧੱਕੀਆਂ route ਲਾਈਨਾਂ ਅਤੇ ਧੱਕੀਆਂ dhcp-option ਲਾਈਨਾਂ ਦੀ ਵਰਤੋਂ ਹੈ, DNS ਸਮੇਤ।
ਉਲਝਣ ਮਰੇ ਐਪ ਦੇ ਕੋਲ ਹਰੇ ਸੂਚਕ ਤੋਂ ਆਉਂਦੀ ਹੈ। ਟਨਲ ਹੈ; ਮੰਜ਼ਿਲਾਂ ਨੂੰ ਉਸ ਟਨਲ ਨਾਲ ਮੈਪ ਕਰਨਾ ਨਹੀਂ ਹੈ। ਕਲਾਇੰਟ ਦੇ ਸਟੇਟਸ ਪੈਨਲ ਵਿੱਚ ਕੁਝ ਵੀ «ਜੁੜਿਆ ਅਤੇ ਰੂਟ ਕਰ ਰਿਹਾ» ਨੂੰ «ਜੁੜਿਆ ਪਰ ਨਿਸ਼ਕਿਰਿਆ» ਤੋਂ ਵੱਖ ਨਹੀਂ ਕਰਦਾ, ਕਿਉਂਕਿ ਟਨਲ ਦੇ ਨਜ਼ਰੀਏ ਤੋਂ ਦੋਵੇਂ ਇੱਕੋ ਹਾਲਤ ਹਨ।
ਜੀਵਤ ਟਨਲ ਫਿਰ ਵੀ ਕੁਝ ਰੂਟ ਕਿਉਂ ਨਹੀਂ ਕਰ ਸਕਦਾ
ਇੰਟਰਫੇਸ ਆਪਣੇ ਪਤੇ ਨਾਲ ਦਿਖਦਾ ਹੈ ਅਤੇ ਪੁਆਇੰਟ-ਟੂ-ਪੁਆਇੰਟ ਲਿੰਕ 'ਤੇ ਅਕਸਰ ਪੀਅਰ ਵੱਲ ਹੋਸਟ ਰੂਟ ਨਾਲੋਂ ਵਧੇਰੇ ਖਾਸ ਕੁਝ ਨਹੀਂ ਹੁੰਦਾ। ਨਿੱਜੀ ਸਬਨੈੱਟ ਤਦ ਹੀ ਪਹੁੰਚਯੋਗ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਕੋਈ ਰੂਟ ਸਹੀ ਪ੍ਰੀਫਿਕਸ ਨਾਲ ਉਸ ਇੰਟਰਫੇਸ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, ਅਤੇ ਧੱਕਣਾ ਬੰਦ ਹੋਣ 'ਤੇ ਉਹ ਰੂਟ ਕਦੇ ਨਹੀਂ ਆਉਂਦਾ। ਡਾਊਨਲੋਡ ਕੀਤਾ ਪ੍ਰੋਫਾਈਲ ਵੀ ਆਮ ਤੌਰ 'ਤੇ ਮਦਦ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਕਿਉਂਕਿ ਇਹ ਇਸ ਮੰਨਤ 'ਤੇ ਲਿਖਿਆ ਗਿਆ ਸੀ ਕਿ ਸਰਵਰ ਠੀਕ ਇਹੀ ਜਾਣਕਾਰੀ ਦੇਵੇਗਾ। ਇਸੇ ਲਈ ਇੰਟਰਫੇਸ ਸਿਹਤਮੰਦ ਦਿਖ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਸਬਨੈੱਟ ਹਨੇਰਾ ਰਹਿੰਦਾ ਹੈ।
ਇਸ ਲਈ ਪ੍ਰੋਫਾਈਲ ਪੜ੍ਹਨਾ ਬਹੁਤ ਘੱਟ ਸਾਬਤ ਕਰਦਾ ਹੈ। ਇਸ ਦੀ ਬਜਾਏ ਜੁੜੀ ਮਸ਼ੀਨ 'ਤੇ ਚੱਲ ਰਹੀ ਹਾਲਤ ਪੜ੍ਹੋ:
ip addr show tun0
ip route show dev tun0
ip route get 10.20.5.10ਦੂਜੇ ਕਮਾਂਡ ਵਿੱਚ ਸਬਨੈੱਟ ਰੂਟ ਤੋਂ ਬਿਨਾਂ ਪਤਾ ਇਸ ਸਮੱਸਿਆ ਦੀ ਨਿਸ਼ਾਨੀ ਹੈ। ਤੀਜਾ ਕਮਾਂਡ ਫਿਰ ਉਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਜੋ ਵਰਤੋਂਕਾਰਾਂ ਲਈ ਸੱਚਮੁੱਚ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਉਸ ਇੰਟਰਫੇਸ ਦੀ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ ਜੋ ਕਰਨਲ ਕਿਸੇ ਖਾਸ ਮੰਜ਼ਿਲ ਲਈ ਚੁਣੇਗਾ, ਨਾ ਕਿ ਉਸ ਸੂਚੀ ਦੀ ਜਿਸ ਦੀ ਵਰਤੋਂ ਹੋਣ ਦੀ ਤੁਸੀਂ ਆਸ ਰੱਖੀ ਸੀ। ਜੇ ਇਹ ਤੁਹਾਡੇ ਭੌਤਿਕ ਲਿੰਕ ਰਾਹੀਂ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਟਨਲ ਰਾਹ ਵਿੱਚ ਹੀ ਨਹੀਂ ਹੈ।
ਨਾਮ ਹੱਲ ਕਰਨਾ ਵੱਖਰੇ ਕਾਰਨ ਨਾਲ ਨਹੀਂ, ਸੰਬੰਧਿਤ ਕਾਰਨ ਨਾਲ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ। ਧੱਕੀਆਂ dhcp-option DNS ਐਂਟਰੀਆਂ ਉਸੇ ਫਲੈਗ ਨਾਲ ਛੱਡ ਦਿੱਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਅੰਦਰੂਨੀ ਹੋਸਟਾਂ ਦੀਆਂ ਪੁੱਛਗਿੱਛਾਂ ਸਥਾਨਕ ਨੈੱਟਵਰਕ ਵੱਲੋਂ ਦਿੱਤੇ ਕਿਸੇ ਵੀ ਰਿਜ਼ੌਲਵਰ ਕੋਲ ਜਾਂਦੀਆਂ ਹਨ। ਉਸ ਰਿਜ਼ੌਲਵਰ ਕੋਲ ਦਫ਼ਤਰ ਲਈ ਜ਼ੋਨ ਨਹੀਂ ਹੈ, ਇਸ ਲਈ ਪੁੱਛਗਿੱਛ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ ਜਾਂ ਜਨਤਕ ਜਵਾਬ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਨੁਕਸ ਸਰਵਰ ਦੀ ਸਮੱਸਿਆ ਵਰਗਾ ਦਿਖਦਾ ਹੈ ਜਦੋਂ ਕਿ ਇਹ ਕਲਾਇੰਟ ਸੰਰਚਨਾ ਦੀ ਸਮੱਸਿਆ ਹੈ। ਨਾਮ ਤੋਂ ਪਹਿਲਾਂ ਪਤਾ ਜਾਂਚਣਾ ਹੀ ਦੋਵਾਂ ਨੂੰ ਵੱਖ ਕਰਦਾ ਹੈ।
ਫਲੈਗ ਅਤੇ ਪ੍ਰੀਫਿਕਸ ਫਿਲਟਰ ਵਿਚਕਾਰ ਚੋਣ
ਦੋਵੇਂ ਵਿਕਲਪ ਇੱਕੋ ਸ਼ਿਕਾਇਤ ਦੀਆਂ ਵੱਖਰੀਆਂ ਸ਼ਕਲਾਂ ਹੱਲ ਕਰਦੇ ਹਨ, ਅਤੇ ਮਾੜੀ ਚੋਣ ਹੀ «ਜੁੜਿਆ ਪਰ ਬੇਕਾਰ» ਹਾਲਤ ਪੈਦਾ ਕਰਦੀ ਹੈ। ਇੱਕ ਧੱਕੀ ਨੀਤੀ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਦਲਦਾ ਹੈ, ਦੂਜਾ ਪ੍ਰੀਫਿਕਸ ਅਨੁਸਾਰ ਉਸ ਵਿੱਚ ਸੋਧ ਕਰਦਾ ਹੈ। ਸਾਰਣੀ ਛੋਟਾ ਸੰਸਕਰਣ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਦਾ ਪੈਰਾ ਉਹ ਹਿੱਸਾ ਕਵਰ ਕਰਦਾ ਹੈ ਜੋ ਲੋਕਾਂ ਨੂੰ ਫੜਦਾ ਹੈ।
| Setting | What the client keeps | Reasonable when |
|---|---|---|
| no option | every pushed route and DHCP entry | the server's view of the network is correct |
route-nopull | the session, none of the pushed routing or DNS | you will write the full local policy yourself |
pull-filter | everything except lines matching your prefixes | the push is nearly right and one or two lines are wrong |
pull-filter ਤਿੰਨ ਕਿਰਿਆਵਾਂ ਵਾਲਾ ਪ੍ਰੀਫਿਕਸ ਮਿਲਾਉਣ ਵਾਲਾ ਹੈ, ਇਸ ਲਈ ਇਹ ਲਾਈਨਾਂ ਦਾ ਪਰਿਵਾਰ ਸਵੀਕਾਰ ਕਰ ਸਕਦਾ ਹੈ, ਚੁੱਪਚਾਪ ਅਣਡਿੱਠਾ ਕਰ ਸਕਦਾ ਹੈ, ਜਾਂ ਪ੍ਰੀਫਿਕਸ ਦਿਖਣ 'ਤੇ ਕਨੈਕਸ਼ਨ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਰੱਦ ਕਰ ਸਕਦਾ ਹੈ। ਆਖਰੀ ਵਿਵਹਾਰ ਹੀ ਜਾਣਨ ਯੋਗ ਹੈ: ਰੱਦ ਕਰਨ ਵਾਲਾ ਨਿਯਮ ਨੀਤੀ ਦੇ ਮਤਭੇਦ ਨੂੰ ਚੁੱਪ ਛੱਡਣ ਦੀ ਬਜਾਏ ਫੇਲ੍ਹ ਹੈਂਡਸ਼ੇਕ ਬਣਾ ਦਿੰਦਾ ਹੈ। OpenVPN 2.6 ਮੈਨੂਅਲ ਸਵੀਕਾਰ ਕੀਤੇ ਪ੍ਰੀਫਿਕਸ ਅਤੇ ਹਰ ਕਿਰਿਆ ਦਾ ਸਹੀ ਅਰਥ ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ।
ਆਮ ਵਿਚਕਾਰਲਾ ਰਾਹ ਇਹ ਹੈ ਕਿ ਸਿਰਫ਼ redirect-gateway ਰੱਦ ਕਰੋ ਅਤੇ ਦਫ਼ਤਰ ਦੇ ਰੂਟ ਅਤੇ DNS ਨੂੰ ਇਰਾਦੇ ਅਨੁਸਾਰ ਆਉਣ ਦਿਓ। ਇਹ ਸਰਵਰ ਵੱਲੋਂ ਤੁਹਾਥੋਂ ਬਿਹਤਰ ਸਮਝੇ ਜਾਣ ਵਾਲੇ ਹਿੱਸਿਆਂ ਲਈ ਧੱਕਣਾ ਕੰਮ ਕਰਦਾ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਨਾਲ ਹੀ ਉਸ ਇੱਕ ਲਾਈਨ ਨੂੰ ਰੋਕਦਾ ਹੈ ਜੋ ਤੁਹਾਡਾ ਡਿਫਾਲਟ ਰੂਟ ਲੈ ਲੈਂਦੀ।
ਹੱਥ ਨਾਲ ਰੂਟ ਅਤੇ ਰਿਜ਼ੌਲਵਰ ਜੋੜਨਾ
ਜੇ ਤੁਸੀਂ ਫਲੈਗ ਰੱਖਦੇ ਹੋ, ਤਾਂ ਪ੍ਰੋਫਾਈਲ ਨੂੰ ਉਹ ਕਹਿਣਾ ਪਵੇਗਾ ਜੋ ਸਰਵਰ ਕਹਿੰਦਾ। ਕਲਾਇੰਟ-ਪਾਸੇ ਦੀਆਂ route ਹਦਾਇਤਾਂ ਕਨੈਕਸ਼ਨ ਸਥਾਪਿਤ ਹੋਣ ਤੋਂ ਬਾਅਦ ਲਾਗੂ ਹੁੰਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਉਹ ਫਲੈਗ ਦੇ ਨਾਲ ਕੰਮ ਕਰਦੀਆਂ ਹਨ, ਇਸ ਵੱਲੋਂ ਰੋਕੀਆਂ ਨਹੀਂ ਜਾਂਦੀਆਂ। ਉਹਨਾਂ ਨੂੰ ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਰੱਖੋ, ਇੰਟਰਐਕਟਿਵ ਕਮਾਂਡ ਲਾਈਨ ਵਿੱਚ ਨਹੀਂ, ਨਹੀਂ ਤਾਂ ਅਗਲਾ ਮੁੜ-ਕਨੈਕਸ਼ਨ ਕੰਮ ਕਰਦੀ ਹਾਲਤ ਦੁਬਾਰਾ ਪੈਦਾ ਨਹੀਂ ਕਰੇਗਾ।
route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53DNS ਲਾਈਨ ਔਖੀ ਥਾਂ 'ਤੇ ਹੈ: ਇਹ ਕਲਾਇੰਟ-ਪਾਸੇ ਦੀ ਹਦਾਇਤ ਹੈ, ਪਰ ਕੁਝ ਕਲਾਇੰਟ ਇਸਨੂੰ ਸਿਰਫ਼ ਪਲੇਟਫਾਰਮ ਦੇ DNS ਏਕੀਕਰਨ ਰਾਹੀਂ ਲਾਗੂ ਕਰਦੇ ਹਨ, ਜੋ ਲਿੰਕ ਬਦਲਣ 'ਤੇ ਇਸ ਉੱਤੇ ਲਿਖ ਸਕਦਾ ਹੈ। systemd ਹੋਸਟ 'ਤੇ ਰਿਜ਼ੌਲਵਰ ਸਿੱਧਾ ਟਨਲ ਇੰਟਰਫੇਸ 'ਤੇ ਸੈੱਟ ਕਰਨਾ ਕਲਾਇੰਟ ਤਰਜੀਹੀ ਮੁਕਾਬਲਾ ਜਿੱਤਣ ਦੀ ਆਸ ਕਰਨ ਨਾਲੋਂ ਵਧੇਰੇ ਅਨੁਮਾਨਯੋਗ ਹੈ:
resolvectl dns tun0 10.20.0.53
resolvectl domain tun0 ~corp.example.comਰੂਟਿੰਗ ਡੋਮੇਨ ਪਤੇ ਜਿੰਨਾ ਹੀ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਇਸ ਤੋਂ ਬਿਨਾਂ ਜਨਤਕ ਨਾਮਾਂ ਦੀਆਂ ਪੁੱਛਗਿੱਛਾਂ ਵੀ ਅੰਦਰੂਨੀ ਰਿਜ਼ੌਲਵਰ ਨੂੰ ਭੇਜੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ, ਅਤੇ ਰਿਕਰਸ਼ਨ ਤੋਂ ਇਨਕਾਰ ਕਰਨ ਵਾਲਾ ਕੋਈ ਵੀ ਅੰਦਰੂਨੀ ਰਿਜ਼ੌਲਵਰ ਨਿੱਜੀ ਜ਼ੋਨ ਚੱਲਦਾ ਰੱਖਦੇ ਹੋਏ ਬ੍ਰਾਊਜ਼ਿੰਗ ਤੋੜ ਦੇਵੇਗਾ। ਇਸ ਨਾਲ ਸਿਰਫ਼ ਉਸ ਪਿਛੇਤਰ ਹੇਠਲੇ ਨਾਮ ਟਨਲ ਰਿਜ਼ੌਲਵਰ ਵੱਲ ਰੂਟ ਹੁੰਦੇ ਹਨ ਅਤੇ ਬਾਕੀ ਸਭ ਭੌਤਿਕ ਲਿੰਕ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ।
ਨਤੀਜਾ ਜਾਂਚਣਾ: ਪਤਾ, ਨਾਮ ਅਤੇ ਬਾਹਰੀ ਰਾਹ
ਤਿੰਨ ਟੈਸਟ ਸੰਭਾਵੀ ਫੇਲ੍ਹਤਾਂ ਨੂੰ ਵੱਖ ਕਰਦੇ ਹਨ। ਪਹਿਲਾਂ IP ਰਾਹੀਂ ਨਿੱਜੀ ਪਤਾ ਲਵੋ, ਫਿਰ ਨਾਮ ਰਾਹੀਂ ਉਹੀ ਹੋਸਟ, ਫਿਰ ਆਮ ਜਨਤਕ ਸਾਈਟ। ਕੰਮ ਕਰਦਾ IP ਅਤੇ ਫੇਲ੍ਹ ਨਾਮ ਰਿਜ਼ੌਲਵਰ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ; ਫੇਲ੍ਹ IP ਅਤੇ ਕੰਮ ਕਰਦਾ ਨਾਮ ਰੂਟਿੰਗ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ; ਦੋਵੇਂ ਫੇਲ੍ਹ ਹੋਣ ਦਾ ਆਮ ਅਰਥ ਹੈ ਕਿ ਟਨਲ ਰਾਹ ਵਿੱਚ ਨਹੀਂ।
ਫਿਰ ਅੰਦਰ ਨਹੀਂ, ਬਾਹਰ ਵੱਲ ਦੇਖੋ। ਟਨਲ ਦੇ ਅੰਤ ਬਿੰਦੂ ਦੇ ਆਪਣੇ ਰੂਟ ਨੂੰ ਬਦਲਾਅ ਸਹਿਣਾ ਪਵੇਗਾ, ਅਤੇ ਕੋਈ ਵੀ ਰੋਕਣ ਵਾਲੀ ਫੇਲ੍ਹਤ ਅੰਤ ਬਿੰਦੂ ਨੂੰ ਫੜੇ ਬਿਨਾਂ ਟਨਲ ਤੱਕ ਸੀਮਿਤ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਟਨਲ ਡਿੱਗਣ ਤੋਂ ਬਾਅਦ ਵੀ ਬ੍ਰਾਊਜ਼ ਕਰਦਾ ਰਹਿਣ ਵਾਲਾ ਕਲਾਇੰਟ ਰੂਟਿੰਗ ਨਹੀਂ, ਨੀਤੀ ਦੀ ਸਮੱਸਿਆ ਹੈ, ਅਤੇ ਉਹ ਉੱਪਰ ਦਿੱਤੇ ਤਿੰਨ ਟੈਸਟਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਵਿੱਚ ਨਹੀਂ ਦਿਖੇਗਾ।
ਅੰਤਿਮ ਸੂਚੀ ਪ੍ਰੋਫਾਈਲ ਦੇ ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਲਿਖੋ: ਰੂਟ, ਰਿਜ਼ੌਲਵਰ, ਡੋਮੇਨ ਅਤੇ ਹਰ ਇੱਕ ਦੇ ਹੋਣ ਦਾ ਕਾਰਨ। ਉਹੀ ਸਾਰਣੀ ਦੁਬਾਰਾ ਪੈਦਾ ਕਰਨ ਵਾਲਾ ਮੁੜ-ਕਨੈਕਸ਼ਨ ਹੀ ਇਸ ਗੱਲ ਦਾ ਇੱਕੋ ਸਬੂਤ ਹੈ ਕਿ ਸਥਾਨਕ ਨੀਤੀ ਪੂਰੀ ਹੈ। ਜੇ ਟਨਲ ਉੱਪਰ ਹੋਣ ਅਤੇ ਤਿੰਨੇ ਟੈਸਟ ਪਾਸ ਹੋਣ 'ਤੇ ਵੀ ਐਪਾਂ ਫੇਲ੍ਹ ਹੁੰਦੀਆਂ ਹਨ, ਤਾਂ ਅੱਗੇ ਦੇਖਣ ਦੀ ਥਾਂ ਪਹਿਲਾਂ ਹੀ ਜਾਂਚੇ ਗਏ ਸਰਟੀਫਿਕੇਟ ਨਹੀਂ, ਸਗੋਂ «ਜੁੜਿਆ ਪਰ ਔਫਲਾਈਨ» ਸ਼੍ਰੇਣੀ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਹਨ।