ਇੱਕ ਚੌੜਾ VPN ਰੂਟ ਕੁਝ ਜਨਤਕ ਸਾਈਟਾਂ ਨੂੰ ਕਿਉਂ ਤੋੜਦਾ ਹੈ

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

ਫੇਲ ਹੋਣ ਵਾਲਾ ਨਾਮ ਹੱਲ ਕਰੋ, ਫਿਰ ਬ੍ਰਾਊਜ਼ਰ ਦੀ ਥਾਂ ਰੂਟਿੰਗ ਸਾਰਣੀ ਵੇਖੋ।

ਸਾਈਟ ਦਾ ਨਾਮ ਨਹੀਂ, ਪਤਾ ਤੁਲਨਾ ਕਰੋ

ਉਹ ਪਤਾ ਲੱਭੋ ਜੋ ਕਲਾਇੰਟ ਨੇ ਅਸਲ ਵਿੱਚ ਅਜ਼ਮਾਇਆ, ਫਿਰ ਜਾਂਚੋ ਕਿ ਕਿਹੜਾ ਰੂਟ ਉਸ ਨਾਲ ਮਿਲਦਾ ਹੈ। 45.61.20.10 ਦੇ ਅੰਦਰ ਮੰਜ਼ਿਲ 45.0.0.0/8 ਦੇ ਹੇਠਾਂ ਆਉਂਦੀ ਹੈ ਜੇ ਉਹ ਪ੍ਰੀਫਿਕਸ ਮੌਜੂਦ ਹੈ, ਭਾਵੇਂ ਸਾਈਟ ਦਾ ਖੁਦ ਟਨਲ ਨਾਲ ਕੋਈ ਸਬੰਧ ਨਾ ਹੋਵੇ। ਫੇਲ ਪਤੇ ਦੀ ਸਥਾਪਿਤ ਪ੍ਰੀਫਿਕਸ ਨਾਲ ਤੁਲਨਾ ਕਰਨਾ ਘਟਾਉ ਦੀ ਸਮੱਸਿਆ ਹੈ, ਅੰਦਾਜ਼ਾ ਨਹੀਂ।

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

Resolve-DnsName www.example.org
Get-NetRoute -AddressFamily IPv4 | Select-Object DestinationPrefix,InterfaceIndex,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 45.61.20.10
Get-VpnConnection | Format-List Name,SplitTunneling,Routes

ਸਭ ਤੋਂ ਖਾਸ ਮਿਲਦਾ ਪ੍ਰੀਫਿਕਸ ਪੜ੍ਹੋ, ਜਾਣੀ-ਪਛਾਣੀ ਲੱਗਦੀ ਪਹਿਲੀ ਲਾਈਨ ਨਹੀਂ। ਸਾਰਣੀ ਵਿੱਚ ਮੌਜੂਦ ਰੂਟ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ ਕਿ ਇਸਨੇ ਖੋਜ ਜਿੱਤੀ; ਸਭ ਤੋਂ ਲੰਮਾ ਮੇਲ ਇਹ ਕਰਦਾ ਹੈ। ਦੋ ਪ੍ਰੀਫਿਕਸ ਇੱਕ ਪਤੇ ਨਾਲ ਮਿਲ ਸਕਦੇ ਹਨ, ਅਤੇ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਹੀ ਪੈਕੇਟ ਲੈਂਦਾ ਹੈ। ਹਾਰਨ ਵਾਲਾ ਸਾਰਣੀ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਸੂਚੀ ਵਿੱਚ ਓਨਾ ਹੀ ਅਸਲੀ ਦਿਸਦਾ ਹੈ।

ਪ੍ਰੀਫਿਕਸ, ਉਸਦਾ ਇੰਟਰਫੇਸ ਅਤੇ ਹੱਲ ਹੋਇਆ ਪਤਾ ਲਿਖੋ। ਉਹ ਤਿੰਨ ਮੁੱਲ ਹੀ ਪੂਰਾ ਨਿਦਾਨ ਹਨ।

ਪਤਾ ਲਗਾਓ ਕਿ ਰੂਟ ਕਿਸਨੇ ਸਥਾਪਿਤ ਕੀਤਾ

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

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

ਮੂਲ ਵਰਗ-ਆਧਾਰਿਤ ਵਿਵਹਾਰ ਧਿਆਨ ਨਾਲ ਪੜ੍ਹੋ

ਮੂਲ Windows ਪ੍ਰੋਫਾਈਲਾਂ ਵਿੱਚ ਇੱਕ ਦਸਤਾਵੇਜ਼ੀ ਸੈਟਿੰਗ ਹੈ, NativeProfile/DisableClassBasedDefaultRoute, ਜੋ ਇੰਟਰਫੇਸ ਪਤੇ ਤੋਂ ਅਨੁਮਾਨਿਤ ਸਵੈਚਾਲਿਤ ਰੂਟ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਦੀ ਹੈ। 45 ਨਾਲ ਸ਼ੁਰੂ ਹੋਣ ਵਾਲਾ ਪ੍ਰੋਫਾਈਲ ਪਤਾ ਉਸ ਵਿਵਹਾਰ ਹੇਠ 45.0.0.0/8 ਐਂਟਰੀ ਬਣਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਇੱਕ ਜਨਤਕ ਪਤਾ ਪੂਰੀ ਵਰਗ-A ਰੇਂਜ ਫੜ ਲੈਂਦਾ ਹੈ।

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

ਜੇ ਅਨੁਮਾਨ ਹੀ ਸਾਬਤ ਕਾਰਨ ਹੈ, ਤਾਂ ਪ੍ਰੋਫਾਈਲ ਨੂੰ ਇਸਦੇ ਪ੍ਰਬੰਧਨ ਮਾਲਕ ਰਾਹੀਂ ਠੀਕ ਕਰੋ ਅਤੇ ਇੱਛਤ ਨਿੱਜੀ ਪ੍ਰੀਫਿਕਸ ਸਪਸ਼ਟ ਰੂਪ ਵਿੱਚ ਦਿਓ। ਜੇ ਸਕ੍ਰਿਪਟ ਨੇ ਐਂਟਰੀ ਜੋੜੀ ਹੈ, ਤਾਂ ਸਕ੍ਰਿਪਟ ਠੀਕ ਕਰੋ। ਇੱਕ ਅਸਪਸ਼ਟ ਚੌੜੇ ਰੂਟ ਨੂੰ ਦੂਜੇ ਨਾਲ ਬਦਲਣਾ ਲੱਛਣ ਬਦਲਦਾ ਹੈ, ਸਵਾਲ ਦਾ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦਾ।

ਸਰੋਤ ਠੀਕ ਕਰੋ, ਫਿਰ ਦੋਵੇਂ ਮਾਰਗ ਦੁਬਾਰਾ ਜਾਂਚੋ

ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਦੁਬਾਰਾ ਕਨੈਕਟ ਕਰੋ ਅਤੇ ਫੇਲ ਹੋਣ ਵਾਲੀ ਜਨਤਕ ਸਾਈਟ ਤੇ ਟਨਲ ਵਰਤਣ ਵਾਲੇ ਸਰੋਤ ਲਈ ਖੋਜ ਦੁਹਰਾਓ। ਪਹਿਲਾ ਹੁਣ ਭੌਤਿਕ ਇੰਟਰਫੇਸ ਉੱਤੇ ਹੱਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਦੂਜਾ ਅਜੇ ਵੀ VPN ਚੁਣਨਾ ਚਾਹੀਦਾ ਹੈ। ਪਹਿਲੀ ਸਫਲਤਾ ਉੱਤੇ ਨਾ ਰੁਕੋ; ਜੋ ਸੁਧਾਰ ਨਿੱਜੀ ਪਹੁੰਚ ਵੀ ਤੋੜਦਾ ਹੈ ਉਸਨੇ ਇੱਕ ਖਰਾਬੀ ਨੂੰ ਦੂਜੇ ਨਾਲ ਬਦਲ ਦਿੱਤਾ ਹੈ।

ਉਸੇ ਸਮੇਂ ਸਰਵਰ ਦੀ ਪਤਾ ਯੋਜਨਾ ਦੀ ਸਮੀਖਿਆ ਕਰੋ। ਜਨਤਕ ਥਾਂ ਨਾਲ ਓਵਰਲੈਪ ਹੁੰਦਾ ਪੂਲ ਇਸ ਕਿਸਮ ਦੀ ਸਮੱਸਿਆ ਵਾਰ-ਵਾਰ ਪੈਦਾ ਕਰਦਾ ਹੈ। ਆਪਰੇਟਰ ਵੱਲੋਂ ਜਾਣ-ਬੁੱਝ ਕੇ ਚੁਣੀ ਰੇਂਜ ਸਵੈਚਾਲਿਤ ਮੁੜ-ਨੰਬਰੀ ਦੀ ਥਾਂ ਕਿਸੇ ਹੋਰ ਗੱਲਬਾਤ ਦੀ ਹੱਕਦਾਰ ਹੈ।

MTU ਵਧਾਉਣ ਜਾਂ DNS ਖਾਲੀ ਕਰਨ ਨਾਲ ਉਹ ਪ੍ਰੀਫਿਕਸ ਠੀਕ ਨਹੀਂ ਹੋਵੇਗਾ ਜੋ ਅਜੇ ਵੀ ਉਸ ਪਤੇ ਨੂੰ ਟਨਲ ਵਿੱਚ ਭੇਜਦਾ ਹੈ। ਪਹਿਲਾਂ ਚੋਣ ਦੀ ਜਾਂਚ ਕਰੋ, ਫਿਰ ਮਾਰਗ ਦੀ।