Windows 'ਤੇ VPN ਸਥਾਨਕ LAN ਨੂੰ ਰੋਕਦਾ ਹੈ: ਰੂਟ ਜਾਂ ਕਲਾਇੰਟ ਨੀਤੀ?
Windows 'ਤੇ ਸਥਾਨਕ LAN ਪਹੁੰਚ ਦੋ ਵੱਖਰੇ ਕਾਰਨਾਂ ਨਾਲ ਟੁੱਟਦੀ ਹੈ: ਗੁੰਮ ਰੂਟ, ਜਾਂ ਸਬਨੈੱਟ ਛੱਡ ਦੇਣ ਵਾਲੀ ਗੇਟਵੇ ਨੀਤੀ। ਤਿੰਨ ਜਾਂਚਾਂ ਦੱਸਦੀਆਂ ਹਨ ਕਿਹੜੀ।
ਤੁਹਾਡੇ ਆਪਣੇ ਡੈਸਕ 'ਤੇ ਰੱਖਿਆ ਪ੍ਰਿੰਟਰ, NAS ਜਾਂ ਡਿਵੈਲਪਮੈਂਟ ਬਾਕਸ ਕੰਮ ਵਾਲਾ VPN ਜੁੜਨ ਦੇ ਪਲ ਹੀ ਜਵਾਬ ਦੇਣਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ। ਕਦੇ ਇੱਕ ਰੂਟ ਕਮਾਂਡ ਇਸਨੂੰ ਸਕਿੰਟਾਂ ਵਿੱਚ ਠੀਕ ਕਰ ਦਿੰਦੀ ਹੈ; ਕਦੇ ਉਹੀ ਰੂਟ ਸਹੀ ਹੁੰਦਾ ਹੈ ਅਤੇ ਪੈਕੇਟ ਫਿਰ ਵੀ ਗਾਇਬ ਹੋ ਜਾਂਦੇ ਹਨ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਮਿਲਦੇ-ਜੁਲਦੇ ਲੱਛਣਾਂ ਵਾਲੀ ਹੋਰ ਸਮੱਸਿਆ ਵੇਖ ਰਹੇ ਹੋ। ਫੈਸਲਾ ਤਿੰਨ ਸਵਾਲਾਂ 'ਤੇ ਆਉਂਦਾ ਹੈ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਗਲਤ ਕ੍ਰਮ ਵਿੱਚ ਪੁੱਛਣਾ ਹੀ ਉਹ ਕਾਰਨ ਹੈ ਜਿਸ ਕਰਕੇ ਲੋਕ ਪੂਰੀ ਸ਼ਾਮ ਰੂਟ ਹਟਾ ਕੇ ਦੁਬਾਰਾ ਜੋੜਨ ਵਿੱਚ ਲੰਘਾਉਂਦੇ ਹਨ।
ਕਿਸੇ ਵੀ ਕਮਾਂਡ ਤੋਂ ਪਹਿਲਾਂ ਤਿੰਨ ਸਵਾਲ
ਪਹਿਲਾ: ਸਥਾਨਕ ਪ੍ਰੀਫਿਕਸ ਲਈ ਐਂਟਰੀ ਹੈ, ਅਤੇ ਕੀ ਉਹ ਭੌਤਿਕ ਅਡੈਪਟਰ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀ ਹੈ? ਦੂਜਾ: ਜੁੜਦੇ ਸਮੇਂ ਕਲਾਇੰਟ ਨੂੰ ਗੇਟਵੇ ਤੋਂ ਸਥਾਨਕ ਨੈੱਟਵਰਕ ਦੀ ਇਜਾਜ਼ਤ ਜਾਂ ਨਾਂਹ ਮਿਲਦੀ ਹੈ? ਤੀਜਾ: ਤੁਹਾਨੂੰ ਸਿਰਫ਼ LAN ਵੱਲ ਬਾਹਰ ਜਾਣ ਦੀ ਪਹੁੰਚ ਚਾਹੀਦੀ ਹੈ, ਜਾਂ ਇੰਟਰਨੈੱਟ ਦੀ ਕੋਈ ਚੀਜ਼ ਵੀ ਤੁਹਾਡੀ ਮਸ਼ੀਨ 'ਤੇ ਚੱਲ ਰਹੀ ਸੇਵਾ ਤੱਕ ਪਹੁੰਚਣੀ ਚਾਹੀਦੀ ਹੈ?
ਪਹਿਲਾ ਸਵਾਲ ਰਾਊਟਿੰਗ ਖਰਾਬੀ ਨੂੰ ਫਿਲਟਰਿੰਗ ਖਰਾਬੀ ਤੋਂ ਵੱਖ ਕਰਦਾ ਹੈ। ਦੂਜਾ ਦੱਸਦਾ ਹੈ ਕਿ ਰੂਟ ਸੁਧਾਰ ਨੂੰ ਕੰਮ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਹੈ ਜਾਂ ਨਹੀਂ। ਤੀਜਾ ਸੁਧਾਰ ਬਦਲਦਾ ਹੈ: ਰੂਟ ਬਾਹਰ ਜਾਣ ਵਾਲੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਠੀਕ ਕਰਦਾ ਹੈ, ਜਦਕਿ ਪਹੁੰਚ ਤੋਂ ਬਾਹਰ ਆਉਣ ਵਾਲੀ ਸੇਵਾ ਆਮ ਤੌਰ 'ਤੇ ਲਿਸਨਰ ਬਾਈਂਡਿੰਗ ਅਤੇ ਵਾਪਸੀ ਮਾਰਗ ਦੀ ਸਮੱਸਿਆ ਹੁੰਦੀ ਹੈ, ਜਿਸਨੂੰ ਰੂਟ ਹੋਰ ਵਿਗਾੜਦਾ ਹੈ।
| What you see | What it points at |
|---|---|
| No local prefix in the table | Missing route |
| Correct prefix, no reply | Client filter or gateway policy |
| Works by IP, fails by name | Resolver changed by the tunnel |
| Inbound service dies, outbound fine | Return path or listener binding |
ਸਵਾਲ ਇੱਕ: ਰੂਟ, ਫਿਲਟਰ ਜਾਂ ਨਾਮ
ਕੁਝ ਵੀ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਟੇਬਲ ਪੜ੍ਹੋ। ਇੰਟਰਫੇਸ ਇੰਡੈਕਸ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਕਿਉਂਕਿ ਹੇਠਾਂ ਦੀ ਹਰ ਰੂਟ ਕਮਾਂਡ ਉਸੇ ਨਾਲ ਬੰਨ੍ਹੀ ਹੋਈ ਹੈ:
route print -4
Get-NetRoute -DestinationPrefix 192.168.1.0/24 | Format-Table InterfaceIndex,NextHop,RouteMetricਸਿੱਧਾ ਜੁੜਿਆ ਸਬਨੈੱਟ ਟਨਲ ਚਾਲੂ ਹੋਣ 'ਤੇ ਵੀ ਆਮ ਤੌਰ 'ਤੇ ਆਨ-ਲਿੰਕ ਰੂਟ ਰੱਖਦਾ ਹੈ, ਇਸ ਲਈ ਐਂਟਰੀ ਹੋ ਸਕਦੀ ਹੈ ਅਤੇ ਟ੍ਰੈਫਿਕ ਫਿਰ ਵੀ ਫੇਲ੍ਹ ਹੋ ਸਕਦਾ ਹੈ। ਇਹ ਸੁਮੇਲ ਰਾਊਟਿੰਗ ਤੋਂ ਬਾਅਦ ਚੱਲਣ ਵਾਲੇ ਫਿਲਟਰ ਦੀ ਸਹੀ ਨਿਸ਼ਾਨੀ ਹੈ, ਅਤੇ ਇਹੀ ਉਹ ਸਥਿਤੀ ਹੈ ਜਿੱਥੇ ਦੂਜਾ, ਵਧੇਰੇ ਖਾਸ ਰੂਟ ਕੁਝ ਵੀ ਨਹੀਂ ਬਦਲਦਾ।
ਪਤੇ ਅਨੁਸਾਰ ਅਤੇ ਨਾਮ ਅਨੁਸਾਰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਜਾਂਚੋ। ਜੇ ping 192.168.1.50 ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਅਤੇ net view 192.168.1.50 ਨਹੀਂ ਦਿੰਦਾ, ਤਾਂ ਰਾਊਟਿੰਗ ਟੇਬਲ ਕਦੇ ਸਮੱਸਿਆ ਨਹੀਂ ਸੀ: ਟਨਲ ਨੇ ਰਿਜ਼ੌਲਵਰ ਬਦਲ ਦਿੱਤਾ ਅਤੇ ਸਥਾਨਕ ਨਾਮ ਹੁਣ ਹੱਲ ਨਹੀਂ ਹੁੰਦਾ। ਇਸ ਲਈ ਰੂਟ ਜੋੜਨਾ ਵਿਅਰਥ ਕੰਮ ਹੈ।
ਸਵਾਲ ਦੋ: ਕੀ ਗੇਟਵੇ ਸਥਾਨਕ LAN ਪਹੁੰਚ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ?
ਵਪਾਰਕ ਕਲਾਇੰਟ ਰੂਟਾਂ ਤੋਂ ਵੱਧ ਇੰਸਟਾਲ ਕਰਦਾ ਹੈ। ਇਹ ਜੁੜਦੇ ਸਮੇਂ ਨੀਤੀ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਸ ਨੀਤੀ ਵਿੱਚ ਸਥਾਨਕ ਨੈੱਟਵਰਕ ਦੀ ਸਪਸ਼ਟ ਇਜਾਜ਼ਤ ਹੋ ਸਕਦੀ ਹੈ। Cisco IPsec ਤੈਨਾਤੀਆਂ ਵਿੱਚ ਗਰੁੱਪ ਨੀਤੀ split-tunneling ਸੈਟਿੰਗ ਅਤੇ ਸਥਾਨਕ LAN ਪਹੁੰਚ ਲਈ ਵੱਖਰਾ ਝੰਡਾ ਰੱਖਦੀ ਹੈ; ਕਲਾਇੰਟ ਦਾ ਚੈੱਕਬਾਕਸ ਇੱਕ ਬੇਨਤੀ ਹੈ ਜਿਸਨੂੰ ਗੇਟਵੇ ਠੁਕਰਾ ਸਕਦਾ ਹੈ। AnyConnect ਵਿੱਚ ਪ੍ਰੋਫਾਈਲ split ਦੀਆਂ ਸ਼ਾਮਲ ਅਤੇ ਬਾਹਰ ਕੱਢਣ ਵਾਲੀਆਂ ਸੂਚੀਆਂ ਅਤੇ ਉਹੀ ਇਜਾਜ਼ਤ ਨਿਯੰਤਰਿਤ ਕਰਦਾ ਹੈ। Windows RRAS 'ਤੇ ਸਮਾਨ ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਡਿਫਾਲਟ ਗੇਟਵੇ ਵਿਕਲਪ ਅਤੇ ਸਰਵਰ ਵੱਲੋਂ ਦਿੱਤੇ ਸਥਿਰ ਰੂਟ ਹਨ।
ਜਦੋਂ ਝੰਡਾ ਬੰਦ ਹੁੰਦਾ ਹੈ, ਦਸਤਾਵੇਜ਼ੀ ਵਿਵਹਾਰ ਇਹ ਹੈ ਕਿ ਕਲਾਇੰਟ ਸਿੱਧੇ ਜੁੜੇ ਸਬਨੈੱਟ ਵੱਲ ਟ੍ਰੈਫਿਕ ਰੋਕਦਾ ਹੈ, ਭਾਵੇਂ ਵੈਧ, ਵਧੇਰੇ ਖਾਸ ਰੂਟ ਮੌਜੂਦ ਹੋਵੇ। ਇਸੇ ਲਈ ਕਲਾਇੰਟ ਦੀ ਮਲਕੀਅਤ ਵਾਲੇ ਨਾ ਹੋਣ ਵਾਲੇ ਰੂਟ ਵੀ ਜੋੜਨ ਤੋਂ ਕੁਝ ਸਕਿੰਟ ਬਾਅਦ ਗਾਇਬ ਹੋ ਸਕਦੇ ਹਨ: ਕਲਾਇੰਟ ਨੂੰ ਕਿਹਾ ਗਿਆ ਹਾਲਤ ਦੁਬਾਰਾ ਬਣਾ ਰਿਹਾ ਹੈ, ਤੁਹਾਡੇ ਨਾਲ ਨਹੀਂ ਲੜ ਰਿਹਾ।
ਕਲਾਇੰਟ ਲੌਗ ਜੁੜਦੇ ਸਮੇਂ ਫੈਸਲਾ ਦਰਜ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਸਨੂੰ ਪੜ੍ਹਨਾ ਮਸ਼ੀਨ 'ਤੇ ਕਿਸੇ ਵੀ ਪ੍ਰਯੋਗ ਤੋਂ ਤੇਜ਼ ਹੈ। ਜੇ ਲੌਗ ਕਹਿੰਦਾ ਹੈ ਕਿ ਸਥਾਨਕ ਪਹੁੰਚ ਰੋਕੀ ਗਈ ਹੈ, ਤਾਂ ਰੁਕੋ: ਕੋਈ ਵੀ ਕਮਾਂਡ-ਲਾਈਨ ਸੁਧਾਰ ਇਸਨੂੰ ਨਹੀਂ ਜਿੱਤ ਸਕਦਾ, ਅਤੇ ਬਚੇ ਹੋਏ ਰਸਤੇ ਨੀਤੀ ਬਦਲਣਾ, ਟਨਲ ਰਾਹੀਂ ਸਰੋਤ ਤੱਕ ਪਹੁੰਚਣਾ, ਜਾਂ ਕਲਾਇੰਟ ਨੂੰ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਵਿੱਚ ਰੱਖ ਕੇ ਹੋਸਟ ਨੂੰ ਸਥਾਨਕ ਨੈੱਟਵਰਕ 'ਤੇ ਛੱਡਣਾ ਹਨ।
ਸਵਾਲ ਤਿੰਨ: ਤੁਹਾਨੂੰ ਕਿਹੜੀ ਦਿਸ਼ਾ ਚਾਹੀਦੀ ਹੈ?
ਨੇੜਲੇ ਡਿਵਾਈਸ ਵੱਲ ਬਾਹਰ ਜਾਣ ਵਾਲਾ ਟ੍ਰੈਫਿਕ ਰਾਊਟਿੰਗ ਦਾ ਸਵਾਲ ਹੈ। LAN ਪ੍ਰੀਫਿਕਸ ਨੂੰ ਸਥਾਨਕ ਗੇਟਵੇ ਵੱਲ ਟਨਲ ਦੇ ਡਿਫਾਲਟ ਰੂਟ ਨੂੰ ਹਰਾਉਣ ਲਈ ਕਾਫ਼ੀ ਘੱਟ ਮੈਟ੍ਰਿਕ ਨਾਲ ਭੇਜੋ:
route add 192.168.1.0 mask 255.255.255.0 192.168.1.1 metric 1 if 12
route add 192.168.1.50 mask 255.255.255.255 192.168.1.1 -pਦੂਜਾ ਰੂਪ ਇੱਕ ਡਿਵਾਈਸ ਨੂੰ ਪਿੰਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਜਦੋਂ ਇੱਕ ਪਤਾ ਹੀ ਪੂਰੀ ਲੋੜ ਹੋਵੇ ਤਾਂ ਤੁਸੀਂ ਇਹੀ ਚਾਹੁੰਦੇ ਹੋ। netsh ਸਮਾਨ ਉਹੀ ਫੈਸਲਾ ਇੰਡੈਕਸ ਦੀ ਬਜਾਏ ਇੰਟਰਫੇਸ ਨਾਮ ਨਾਲ ਦਰਜ ਕਰਦਾ ਹੈ:
netsh interface ipv4 add route prefix=192.168.1.0/24 interface=12 nexthop=192.168.1.1 store=persistentਪਤਾ ਅਤੇ ਮਾਸਕ ਨਾ ਮਿਲਣ 'ਤੇ ਰੂਟ ਕਮਾਂਡਾਂ ਪੈਰਾਮੀਟਰ ਗਲਤ ਹੈ ਨਾਲ ਫੇਲ੍ਹ ਹੁੰਦੀਆਂ ਹਨ, ਜਿਵੇਂ /24 ਮਾਸਕ ਵਾਲਾ ਹੋਸਟ ਪਤਾ। ਸਬਨੈੱਟ ਰੂਟ ਲਈ ਨੈੱਟਵਰਕ ਪਤਾ ਅਤੇ ਇੱਕਲੇ ਹੋਸਟ ਲਈ ਹੋਸਟ ਮਾਸਕ ਵਰਤੋ।
ਅੰਦਰ ਆਉਣ ਵਾਲਾ ਵੱਖਰਾ ਹੈ। ਉਸੇ ਮਸ਼ੀਨ ਦਾ VNC ਜਾਂ SSH ਸਰਵਰ ਪਹੁੰਚ ਤੋਂ ਬਾਹਰ ਹੋ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਅੰਦਰ ਆਉਣ ਵਾਲੇ ਕਨੈਕਸ਼ਨ ਦੇ ਜਵਾਬ VPN ਗੇਟਵੇ ਰਾਹੀਂ ਬਾਹਰ ਚਲੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਕਦੇ ਵਾਪਸ ਨਹੀਂ ਆਉਂਦੇ। ਰੂਟ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਜਾਂਚੋ ਕਿ ਸੇਵਾ ਕਿਸ 'ਤੇ ਸੁਣਦੀ ਹੈ:
netstat -ano | findstr :5900ਇੱਕ ਖਾਸ ਪਤੇ ਨਾਲ ਬੱਝਿਆ ਲਿਸਨਰ ਦੂਜੇ ਇੰਟਰਫੇਸ 'ਤੇ ਜਵਾਬ ਨਹੀਂ ਦੇਵੇਗਾ। ਇਸਨੂੰ ਸਾਰੇ ਇੰਟਰਫੇਸਾਂ ਨਾਲ ਬੰਨ੍ਹਣਾ ਜਾਣਬੁੱਝ ਕੇ ਲਿਆ ਫੈਸਲਾ ਹੈ, ਜੋ ਤੁਸੀਂ ਜਿਸ ਨੈੱਟਵਰਕ 'ਤੇ ਭਰੋਸਾ ਕਰਦੇ ਹੋ ਉਸ ਤੱਕ ਸੀਮਤ ਫਾਇਰਵਾਲ ਨਿਯਮ ਨਾਲ ਲਿਆ ਜਾਂਦਾ ਹੈ। ਉਸ ਤੋਂ ਬਾਅਦ ਹੀ ਰੂਟ ਸੁਧਾਰ ਵਾਪਸੀ ਮਾਰਗ ਬਹਾਲ ਕਰਦਾ ਹੈ।
ਢੁੱਕਵਾਂ ਸਭ ਤੋਂ ਛੋਟਾ ਬਦਲਾਅ ਲਾਗੂ ਕਰੋ
ਦੂਜਾ ਆਮ ਕਦਮ IPv4 ਉੱਨਤ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਿੱਚ “ਰਿਮੋਟ ਨੈੱਟਵਰਕ 'ਤੇ ਡਿਫਾਲਟ ਗੇਟਵੇ ਵਰਤੋ” ਦਾ ਟਿੱਕ ਹਟਾਉਣਾ ਹੈ। ਇਹ ਇੰਟਰਨੈੱਟ ਟ੍ਰੈਫਿਕ ਸਥਾਨਕ ਰੱਖਦਾ ਹੈ, ਪਰ ਇੱਕੋ ਸਮੇਂ ਦੋ ਕੰਮ ਕਰਦਾ ਹੈ: VPN ਡਿਫਾਲਟ ਰਾਹ ਨਹੀਂ ਰਹਿੰਦਾ, ਅਤੇ ਕਲਾਇੰਟ ਰਿਮੋਟ ਨੈੱਟਵਰਕ ਲਈ ਰੂਟ, multicast ਸਮੇਤ, ਲੈਣਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ। ਟਿੱਕ ਹਟਾਓ ਅਤੇ ਰਿਮੋਟ LAN ਗਾਇਬ ਹੋ ਜਾਂਦਾ ਹੈ, ਜਦ ਤੱਕ ਸਰਵਰ ਹਰ ਕਲਾਇੰਟ ਨੂੰ ਲੋੜੀਂਦੇ ਖਾਸ ਰਿਮੋਟ ਪ੍ਰੀਫਿਕਸ ਨਹੀਂ ਧੱਕਦਾ।
ਇਹ ਅਸਮਾਨਤਾ ਕੰਮ ਦਾ ਕ੍ਰਮ ਤੈਅ ਕਰਦੀ ਹੈ। ਜੇ ਰਿਮੋਟ ਪਾਸਾ ਪੂਰੀ ਤਰ੍ਹਾਂ ਪਹੁੰਚਯੋਗ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਸਰਵਰ ਤੋਂ ਰਿਮੋਟ ਸਬਨੈੱਟ ਧੱਕੋ ਅਤੇ ਸਥਾਨਕ ਡਿਫਾਲਟ ਨੂੰ ਛੱਡ ਦਿਓ। ਜੇ ਸਰਵਰ ਨਹੀਂ ਬਦਲ ਸਕਦੇ, ਤਾਂ ਟਨਲ ਵੱਲੋਂ ਦਿੱਤੇ ਪਤੇ ਰਾਹੀਂ ਰਿਮੋਟ ਪ੍ਰੀਫਿਕਸ 'ਤੇ ਪੱਕਾ ਰੂਟ ਜੋੜੋ, ਅਤੇ route print ਨਾਲ ਜਾਂਚੋ ਕਿ ਪ੍ਰੀਫਿਕਸ VPN ਇੰਟਰਫੇਸ ਵੱਲ ਅਤੇ ਡਿਫਾਲਟ ਅਜੇ ਵੀ ਭੌਤਿਕ ਗੇਟਵੇ ਵੱਲ ਹੈ।
ਫਿਰ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਸੁਧਾਰ ਦੁਬਾਰਾ ਜੁੜਨ 'ਤੇ ਵੀ ਟਿਕਦਾ ਹੈ, ਕਿਉਂਕਿ ਪੱਕੇ ਨਾ ਹੋਣ ਵਾਲੇ ਰੂਟ ਅਡੈਪਟਰ ਨਾਲ ਮਰ ਜਾਂਦੇ ਹਨ ਅਤੇ ਹਰ ਕਨੈਕਸ਼ਨ ਤੋਂ ਬਾਅਦ ਚੱਲਣ ਵਾਲੀ ਸਕ੍ਰਿਪਟ ਉਹਨਾਂ ਲਈ ਇਮਾਨਦਾਰ ਥਾਂ ਹੈ। ਉਸੇ ਸੈਸ਼ਨ ਵਿੱਚ ਇੱਕ ਸਥਾਨਕ ਡਿਵਾਈਸ ਅਤੇ ਇੱਕ ਰਿਮੋਟ ਸਰੋਤ ਜਾਂਚੋ, ਡਿਸਕਨੈਕਟ ਕਰੋ, ਦੁਬਾਰਾ ਜੁੜੋ ਅਤੇ ਫਿਰ ਜਾਂਚੋ। ਜੇ ਰੂਟ ਸਹੀ ਦਿਸਦਾ ਹੋਣ 'ਤੇ ਵੀ ਸਥਾਨਕ ਡਿਵਾਈਸ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਸਵਾਲ ਦੋ ਵੱਲ ਮੁੜੋ: ਕਲਾਇੰਟ ਫਿਲਟਰ ਕਰ ਰਿਹਾ ਹੈ, ਅਤੇ ਜਵਾਬ ਨੀਤੀ ਬਦਲਾਅ ਹੈ, ਦੂਜਾ ਮੁਕਾਬਲੇਬਾਜ਼ ਰੂਟ ਨਹੀਂ।