ਇੱਕੋ ਸਬਨੈੱਟ ਦੀਆਂ ਵੈੱਬਸਾਈਟਾਂ ਗੇਟਵੇ ਦੀ ਪਾਰਦਰਸ਼ੀ ਪ੍ਰਾਕਸੀ ਨੂੰ ਬਾਈਪਾਸ ਕਰ ਸਕਦੀਆਂ ਹਨ
ਇੰਟਰਨੈੱਟ ਬੇਨਤੀਆਂ ਇਸ ਦੇ ਲਾਗ ਵਿੱਚ ਦਿਖਣ ਦੇ ਬਾਵਜੂਦ ਇੱਕੋ ਸਬਨੈੱਟ ਦਾ ਟ੍ਰੈਫਿਕ ਗੇਟਵੇ ਦੇ ਰੋਕ ਨਿਯਮ ਨੂੰ ਕਿਉਂ ਬਾਈਪਾਸ ਕਰ ਸਕਦਾ ਹੈ, ਇਹ ਸਮਝਾਉਂਦਾ ਹੈ।
ਇੰਟਰਨੈੱਟ ਬ੍ਰਾਊਜ਼ਿੰਗ ਗੇਟਵੇ ਪ੍ਰਾਕਸੀ ਦੇ ਲਾਗ ਵਿੱਚ ਦਿਖਦੀ ਹੈ। ਦਫ਼ਤਰ ਦੇ LAN ਉੱਤੇ ਵੈੱਬਸਾਈਟ ਨਹੀਂ ਦਿਖਦੀ। URL ਫਿਲਟਰ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਪਤਾ ਕਰੋ ਕਿ LAN ਬੇਨਤੀ ਗੇਟਵੇ ਤੱਕ ਪਹੁੰਚੀ ਸੀ ਜਾਂ ਨਹੀਂ।
ਸਿੱਧੇ ਜੁੜੇ IPv4 ਮੰਜ਼ਿਲ ਲਈ ਕਲਾਇੰਟ ਮੰਜ਼ਿਲ ਦਾ ਲਿੰਕ-ਲੇਅਰ ਪਤਾ ਹੱਲ ਕਰਕੇ ਸਥਾਨਕ ਹਿੱਸੇ ਵਿੱਚ ਉੱਥੇ ਭੇਜ ਸਕਦਾ ਹੈ। ਇਸ ਦਾ ਡਿਫ਼ਾਲਟ ਗੇਟਵੇ ਉਸ ਰਾਹ ਉੱਤੇ ਆਪਣੇ ਆਪ ਨਹੀਂ ਹੁੰਦਾ। ਗੇਟਵੇ ਉੱਤੇ ਪਾਰਦਰਸ਼ੀ ਰੋਕ ਨਿਯਮ ਉਹ ਪੈਕੇਟ ਰੀਡਾਇਰੈਕਟ ਨਹੀਂ ਕਰ ਸਕਦਾ ਜੋ ਗੇਟਵੇ ਨੂੰ ਕਦੇ ਨਹੀਂ ਮਿਲਦੇ।
ਉਦਾਹਰਨ ਲਈ, ਇੱਕੋ ਆਨ-ਲਿੰਕ ਸਬਨੈੱਟ ਦੇ ਦੋ ਹੋਸਟ ਸਵਿੱਚ ਰਾਹੀਂ ਟ੍ਰੈਫਿਕ ਦਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਕਰ ਸਕਦੇ ਹਨ ਜਦੋਂ ਕਿ ਪ੍ਰਾਕਸੀ ਮਸ਼ੀਨ ਕਿਸੇ ਹੋਰ ਸਵਿੱਚ ਪੋਰਟ ਨਾਲ ਜੁੜੀ ਹੁੰਦੀ ਹੈ। ਸਿਰਫ਼ ਉਸ LAN ਉੱਤੇ ਹੋਣਾ ਪ੍ਰਾਕਸੀ ਨੂੰ ਫਾਰਵਰਡਿੰਗ ਬਿੰਦੂ ਨਹੀਂ ਬਣਾਉਂਦਾ।
ਚਾਹਿਆ ਹੋਇਆ ਰਾਹ ਚੁਣੋ
ਸਪੱਸ਼ਟ ਪ੍ਰਾਕਸੀ ਸੈਟਿੰਗ ਭਾਗ ਲੈਣ ਵਾਲੀ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਬੇਨਤੀ ਪ੍ਰਾਕਸੀ ਨੂੰ ਭੇਜ ਸਕਦੀ ਹੈ ਭਾਵੇਂ ਟਾਰਗੈਟ ਵੈੱਬਸਾਈਟ ਸਥਾਨਕ ਹੋਵੇ। ਬਾਈਪਾਸ ਨਿਯਮ ਅਤੇ PAC ਫ਼ੈਸਲੇ ਵੀ ਵੇਖੋ: ਉਹ ਨਿੱਜੀ ਨਾਵਾਂ ਜਾਂ ਪਤਿਆਂ ਲਈ ਜਾਣਬੁੱਝ ਕੇ DIRECT ਚੁਣ ਸਕਦੇ ਹਨ।
ਜੇ ਰੋਕ ਲੋੜੀਂਦੀ ਹੈ, ਨੈੱਟਵਰਕ ਨੂੰ ਰੋਕ ਬਿੰਦੂ ਸੱਚਮੁੱਚ ਰਾਹ ਵਿੱਚ ਰੱਖਣਾ ਪਵੇਗਾ; Linux ਗੇਟਵੇ ਉੱਤੇ ਸਥਾਨਕ ਅਤੇ ਫਾਰਵਰਡ ਕੀਤੇ ਪੈਕੇਟ ਰਾਹ ਵੱਖ ਕਰੋ। ਰਾਊਟਡ ਸਬਨੈੱਟ ਵੱਖਰਾਵਾ ਜਾਂ ਜਾਣਬੁੱਝ ਕੇ ਇਨਲਾਈਨ ਬ੍ਰਿਜ ਢੁੱਕਵੇਂ ਡਿਜ਼ਾਈਨਾਂ ਵਿੱਚ ਇਹ ਕਰ ਸਕਦੇ ਹਨ, ਪਰ ਹਰ ਇੱਕ ਫਾਰਵਰਡਿੰਗ ਅਤੇ ਫੇਲ ਹੋਣ ਦਾ ਵਿਵਹਾਰ ਬਦਲਦਾ ਹੈ। LAN ਉੱਤੇ ਕਿਤੇ ਹੋਰ ਬ੍ਰਿਜ ਆਪਣੇ ਆਪ ਇਨਲਾਈਨ ਨਹੀਂ ਹੁੰਦਾ।
ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰੋਟੋਕਾਲ ਦੀ ਲੋੜ ਵੱਖਰੀ ਰੱਖੋ। ਟ੍ਰੈਫਿਕ ਡਿਵਾਈਸ ਪਾਰ ਕਰਨ ਤੋਂ ਬਾਅਦ ਵੀ ਸਰੋਤਾ ਨੂੰ ਰੋਕ ਮੋਡ ਦਾ ਸਮਰਥਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਪੈਕੇਟ ਹਿਲਾਉਣਾ HTTPS ਡੀਕ੍ਰਿਪਟ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਹੈ ਅਤੇ ਨਾ ਹੀ ਇਹ ਗਾਰੰਟੀ ਕਿ ਆਮ SOCKS ਪੋਰਟ ਉਹਨਾਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰ ਸਕੇਗਾ।
ਕਲਾਇੰਟ ਵੱਲੋਂ ਚੁਣਿਆ ਰਾਹ, ਸਥਾਨਕ ਹਿੱਸਾ ਅਤੇ ਅਸਲ ਫਾਰਵਰਡਿੰਗ ਡਿਵਾਈਸ ਦਰਜ ਕਰੋ। ਪ੍ਰਾਕਸੀ ਲਾਗ ਦਾ ਨਾ ਹੋਣਾ ਲਾਗਿੰਗ ਫੇਲ੍ਹ ਹੋਣਾ ਨਹੀਂ ਬਲਕਿ ਟੋਪੋਲੋਜੀ ਦਾ ਸਹੀ ਵਰਣਨ ਹੋ ਸਕਦਾ ਹੈ।