ਐਪ-ਆਧਾਰਿਤ ਬਨਾਮ ਮੰਜ਼ਿਲ-ਆਧਾਰਿਤ ਸਪਲਿਟ ਟਨਲਿੰਗ: ਕਿਹੜਾ ਚੁਣੀਏ

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

ਦੋ ਨਿਯਮ ਵੱਖ-ਵੱਖ ਪਰਤਾਂ ਤੇ ਕੰਮ ਕਰਦੇ ਹਨ

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

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

ਐਪ ਨਿਯਮ ਮੋਬਾਈਲ ਕਲਾਇੰਟ ਅਤੇ ਪ੍ਰਬੰਧਿਤ ਏਜੰਟ ਲਈ ਢੁੱਕਵੇਂ ਹਨ

Android ਚੋਣ ਸਿੱਧੀ ਦਿਖਾਉਂਦਾ ਹੈ: VpnService.Builder.addAllowedApplication() ਅਤੇ addDisallowedApplication() ਪੈਕੇਜ ਨਾਮ ਲੈਂਦੇ ਹਨ ਅਤੇ ਹਰ UID ਲਈ ਫੈਸਲਾ ਲਾਗੂ ਕਰਦੇ ਹਨ, ਜਿਵੇਂ Android ਦੀ VPN ਡਿਵੈਲਪਰ ਗਾਈਡ ਵਿੱਚ ਦੱਸਿਆ ਹੈ। iOS ਵਿੱਚ ਬੰਡਲ ਪਛਾਣਕਰਤਾ ਤੇ ਆਧਾਰਿਤ ਪ੍ਰਤੀ-ਐਪ VPN ਨਿਯਮਾਂ ਰਾਹੀਂ ਬਰਾਬਰ ਪ੍ਰਬੰਧ ਹੈ, ਜੋ ਆਮ ਤੌਰ ਤੇ ਹੱਥ ਨਾਲ ਲਿਖਣ ਦੀ ਥਾਂ MDM ਪ੍ਰੋਫਾਈਲ ਨਾਲ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।

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

ਲੋਕਾਂ ਦੁਆਰਾ ਛੱਡਿਆ ਨਤੀਜਾ: ਉਹਨਾਂ ਪਲੇਟਫਾਰਮਾਂ ਤੇ ਰਾਊਟ ਨਾਲ ਐਪ ਨਿਯਮ ਦੀ ਨਕਲ ਨਹੀਂ ਕੀਤੀ ਜਾ ਸਕਦੀ। ਐਪ ਦੇ ਸਰਵਰ ਲਈ ਹੋਸਟ ਰਾਊਟ ਸ਼ਾਮਲ ਕਰਨ ਨਾਲ ਸਭ ਦਾ ਟ੍ਰੈਫਿਕ ਉਸ ਸਰਵਰ ਵੱਲ ਟਨਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਬ੍ਰਾਊਜ਼ਰ ਅਤੇ ਅਪਡੇਟਰ ਸਮੇਤ।

ਮੰਜ਼ਿਲ ਨਿਯਮ ਸਬਨੈੱਟ ਸੂਚੀਆਂ ਅਤੇ ਸਾਈਟ ਪਹੁੰਚ ਲਈ ਢੁੱਕਵੇਂ ਹਨ

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

OpenVPN ਧੱਕੀ ਗਈ ਰਾਊਟਿੰਗ ਟੇਬਲ ਰਾਹੀਂ ਉਸੇ ਥਾਂ ਪਹੁੰਚਦਾ ਹੈ। route-nopull ਸਰਵਰ ਨੂੰ ਰਾਊਟ ਦੱਸਣ ਤੋਂ ਰੋਕਦਾ ਹੈ, ਉਸ ਤੋਂ ਬਾਅਦ ਕਲਾਇੰਟ-ਪਾਸੇ ਦਾ route 10.20.0.0 255.255.0.0 vpn_gateway ਬਿਲਕੁਲ ਦਫ਼ਤਰੀ ਪ੍ਰੀਫਿਕਸ ਕਵਰ ਕਰਦਾ ਹੈ। IPv6 ਇਹਨਾਂ ਹਰੇਕ ਕਲਾਇੰਟ ਵਿੱਚ ਵੱਖਰਾ ਬਿਆਨ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਭੁੱਲਣਾ ਸਹੀ ਦਿਸਦੇ IPv4 ਸਪਲਿਟ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਲੀਕ ਹੋਣ ਦਾ ਸਭ ਤੋਂ ਆਮ ਤਰੀਕਾ ਹੈ।

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

ਦੋਵੇਂ ਮਾਡਲ ਕਿੱਥੇ ਟੁੱਟਦੇ ਹਨ: ਸਹਾਇਕ, ਸਾਂਝੀਆਂ ਸੇਵਾਵਾਂ, ਰਿਜ਼ੋਲਵਰ

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

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

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

ਕਾਰਜ ਵਿਧੀ: ਚੁਣੋ, ਲਾਗੂ ਕਰੋ, ਪ੍ਰਮਾਣਿਤ ਕਰੋ

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

ਤੁਸੀਂ ਜੋ ਸਭ ਤੋਂ ਸੰਕੜਾ ਰੂਪ ਦੱਸ ਸਕਦੇ ਹੋ ਉਹ ਲਾਗੂ ਕਰੋ, ਫਿਰ ਕਲਾਇੰਟ ਦੇ ਸਥਿਤੀ ਆਈਕਨ ਦੀ ਥਾਂ ਰਾਊਟਿੰਗ ਟੇਬਲ ਨੂੰ ਪੁੱਛ ਕੇ ਪ੍ਰਮਾਣਿਤ ਕਰੋ:

ip route get 10.20.30.40
ip -6 route get 2001:db8:10::40
wg show wg0 allowed-ips
Get-NetRoute -DestinationPrefix 10.20.0.0/16
Find-NetRoute -RemoteIPAddress 10.20.30.40

ਪਹਿਲੀਆਂ ਦੋ ਲਾਈਨਾਂ ਅਸਲ ਮੰਜ਼ਿਲ ਵੱਲੋਂ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਇੰਟਰਫੇਸ ਦਾ ਨਾਮ ਦਿੰਦੀਆਂ ਹਨ; wg show ਸੰਰਚਿਤ ਪ੍ਰੀਫਿਕਸ ਸੂਚੀ ਛਾਪਦਾ ਹੈ; Windows ਤੇ Find-NetRoute ਪੈਕੇਟ ਭੇਜਣ ਵੇਲੇ ਸਟੈਕ ਜਿਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇਵੇਗਾ ਉਸੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਜੇ ਇੰਟਰਫੇਸ ਟਨਲ ਹੈ, ਨਿਯਮ ਮਿਲ ਗਿਆ।

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