ਤੁਸੀਂ ਆਪਣਾ ਸਥਾਨਕ ਡਿਫ਼ਾਲਟ ਰੂਟ ਰੱਖਣ ਲਈ ਇੱਕ ਲਾਈਨ ਜੋੜਦੇ ਹੋ, ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਸੁਰੰਗ ਹੁਣ ਅੰਦਰੂਨੀ DNS ਸਰਵਰ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦੀ। ਉਹ ਲਾਈਨ pull-filter ignore "route" ਸੀ, ਜਿਸਦਾ ਅਰਥ "ਇਸ ਰੂਟ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰੋ" ਨਹੀਂ ਹੈ। ਇਸਦਾ ਅਰਥ "ਹਰ ਧੱਕੇ ਗਏ ਵਿਕਲਪ ਨੂੰ ਸੁੱਟ ਦਿਓ ਜਿਸਦਾ ਟੈਕਸਟ ਉਨ੍ਹਾਂ ਪੰਜ ਅੱਖਰਾਂ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ", ਅਤੇ ਆਮ ਸਰਵਰ ਉੱਤੇ ਇਸ ਵਿੱਚ ਰੂਟਾਂ ਦੇ ਨਾਲ route-gateway, route-metric ਅਤੇ route-ipv6 ਵੀ ਸ਼ਾਮਲ ਹਨ। ਹੇਠਾਂ ਦਿੱਤੀ ਜਾਂਚ-ਸੂਚੀ ਉਹੀ ਹੈ ਜੋ ਮੈਂ ਕਿਸੇ ਹੋਰ ਦੀ ਵਰਤੋਂ ਵਾਲੀ ਪ੍ਰੋਫ਼ਾਈਲ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਚਲਾਉਂਦਾ ਹਾਂ।

ਫ਼ਿਲਟਰ ਸਿਰਫ਼ ਧੱਕੇ ਗਏ ਵਿਕਲਪਾਂ ਉੱਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ

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

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

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

sudo openvpn --config /etc/openvpn/corp.ovpn --verb 4
sudo grep -n 'pull-filter' /etc/openvpn/corp.ovpn

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

ਮੇਲ ਇੱਕ ਅਗੇਤਰ ਹੈ, ਇਸ ਲਈ ਸਪੇਸ ਹੀ ਪੂਰੀ ਖੇਡ ਹਨ

ਤੁਲਨਾ ਲੜੀ ਦਾ ਅਗੇਤਰ ਹੈ, ਪਾਰਸ ਕੀਤਾ ਵਿਕਲਪ ਨਾਮ ਨਹੀਂ। ਇਸ ਲਈ "route" route-gateway 10.8.0.1, route-ipv6 2001:db8::/32 ਅਤੇ route-metric 100 ਨਾਲ ਮਿਲਦਾ ਹੈ। ਅੰਤ ਵਿੱਚ ਇੱਕ ਸਪੇਸ ਜੋੜਨ ਨਾਲ ਇਹ ਸੰਭਾਵੀ ਪਰਿਵਾਰ ਤੱਕ ਸੁੰਗੜ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਪੂਰਾ ਅਗੇਤਰ ਇਸਨੂੰ ਹੋਰ ਸੁੰਗੜ ਕੇ ਖ਼ਾਸ ਮੰਤਵ ਤੱਕ ਲੈ ਜਾਂਦਾ ਹੈ।

Filter textWhat it actually matchesTypical outcome
"route"Every option beginning with those lettersRoutes, gateway, metric and IPv6 routes all dropped
"route "Route entries only, not the hyphenated siblingsThe routes go, the rest survives
"route 10.60."A single destination rangeThe narrowest rule, and the easiest to audit
"dhcp-option DNS"Pushed DNS settingsResolver stays local, internal names stop resolving

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

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

ਤਿੰਨ ਕਿਰਿਆਵਾਂ, ਤਿੰਨ ਵੱਖਰੇ ਨਤੀਜੇ

accept, ignore ਅਤੇ reject ਇੱਕੋ ਵਿਚਾਰ ਦੀਆਂ ਤਿੰਨ ਸ਼ਬਦ-ਜੋੜ ਨਹੀਂ ਹਨ। ਇਹ ਮੇਲ ਨਾਲ ਕਲਾਇੰਟ ਕੀ ਕਰਦਾ ਹੈ ਅਤੇ ਕਿਸੇ ਨੂੰ ਪਤਾ ਲੱਗਦਾ ਹੈ ਜਾਂ ਨਹੀਂ—ਇਸ ਵਿੱਚ ਵੱਖਰੇ ਹਨ।

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

ਤੁਸੀਂ ਕੋਈ ਵੀ ਕਿਰਿਆ ਵਰਤੋ, ਫ਼ਿਲਟਰ ਉਸੇ ਕ੍ਰਮ ਵਿੱਚ ਲਾਗੂ ਹੁੰਦੇ ਹਨ ਜਿਸ ਵਿੱਚ ਉਹ ਦਿਖਦੇ ਹਨ, ਇਸ ਲਈ ਦੋ ਓਵਰਲੈਪ ਹੁੰਦੇ ਨਿਯਮ ਕ੍ਰਮ-ਨਿਰਭਰ ਨਤੀਜਾ ਦਿੰਦੇ ਹਨ ਜਿਸਦੀ ਸਮੀਖਿਆ ਕਰਨਾ ਬਹੁਤ ਔਖਾ ਹੈ। ਹਰ ਮੰਤਵ ਲਈ ਇੱਕ ਨਿਯਮ ਰੱਖੋ ਅਤੇ ਹਰੇਕ ਵਿੱਚ ਸਭ ਤੋਂ ਖ਼ਾਸ ਟੈਕਸਟ ਰੱਖੋ। ਜੇ ਇਜਾਜ਼ਤ-ਸੂਚੀ ਚਾਹੀਦੀ ਹੈ, ਤਾਂ ਉਹੀ ਜੋੜਨ ਵਾਲੇ ignore ਨਿਯਮਾਂ ਦੇ ਢੇਰ ਦੀ ਥਾਂ ਕੁਝ accept ਨਿਯਮਾਂ ਨੂੰ ਤਰਜੀਹ ਦਿਓ। ਫਿਰ ਸਮੀਖਿਅਕ ਫ਼ਾਈਲ ਨੂੰ ਉੱਪਰ ਤੋਂ ਹੇਠਾਂ ਪੜ੍ਹ ਕੇ ਨਤੀਜੇ ਦਾ ਅੰਦਾਜ਼ਾ ਲਾ ਸਕਦੇ ਹਨ, ਅਤੇ ਇਹੀ ਇੱਕੋ ਇੱਕ ਪਰਖ ਹੈ ਜੋ ਪੈਮਾਨਾ ਬਣਦੀ ਹੈ।

ਲਾਗੂ ਹੋਏ ਰੂਟ ਅਤੇ ਰਿਜ਼ਾਲਵਰ ਵੇਖੋ, ਪ੍ਰੋਫ਼ਾਈਲ ਨਹੀਂ

ਫ਼ਾਈਲ ਵਿੱਚ ਸਹੀ ਦਿਖਦਾ ਫ਼ਿਲਟਰ ਵੀ ਤੁਹਾਨੂੰ ਅਜਿਹੀ ਸੁਰੰਗ ਨਾਲ ਛੱਡ ਸਕਦਾ ਹੈ ਜੋ ਕੁਝ ਵੀ ਲਾਹੇਵੰਦ ਰੂਟ ਨਹੀਂ ਕਰਦੀ। ਚੱਲ ਰਹੇ ਸਿਸਟਮ ਉੱਤੇ ਅਸਰ ਜਾਂਚੋ, ਜਿੱਥੇ ਧੱਕੇ ਗਏ ਵਿਕਲਪ ਪਹਿਲਾਂ ਹੀ ਲਾਗੂ ਜਾਂ ਸੁੱਟੇ ਜਾ ਚੁੱਕੇ ਹਨ:

ip route show default
ip route show | grep -c 'proto static'
resolvectl status | grep -A4 'Link.*tun0'
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://intranet.example.internal/

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

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

ਛੋਟ ਅਤੇ ਉਸਦਾ ਮਾਲਕ ਦਰਜ ਕਰੋ

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

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

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

ਸੰਬੰਧਿਤ ਲੇਖ