Squid ਲੌਗਇਨ ਅਤੇ ਸਹੀ ਕਲਾਇੰਟ IP ਦੋਵੇਂ ਲਾਜ਼ਮੀ ਕਰੋ
ਦੋਵੇਂ ACL ਸ਼ਰਤਾਂ ਲਾਜ਼ਮੀ ਕਰਕੇ ਨਾਮਿਤ Squid ਪ੍ਰੌਕਸੀ ਵਰਤੋਂਕਾਰ ਨੂੰ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਸਰੋਤ ਪਤੇ ਤੱਕ ਸੀਮਿਤ ਕਰੋ।
ਸਹੀ ਪਾਸਵਰਡ ਇਸ ਨੀਤੀ ਦਾ ਸਿਰਫ ਅੱਧਾ ਹਿੱਸਾ ਹੈ: ਖਾਤੇ ਨੂੰ ਇੱਕ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਕਲਾਇੰਟ ਪਤੇ ਤੋਂ ਵੀ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। Squid ਵਿੱਚ ਦੋਵੇਂ ਜਾਂਚਾਂ ਨੂੰ ਇੱਕੋ ਐਕਸੈਸ ਨਿਯਮ ਉੱਤੇ ਰੱਖਣਾ ਉਸ ਲੋੜ ਅਤੇ ਦੋ ਵੱਖਰੇ ਪ੍ਰਵੇਸ਼ ਮਾਰਗਾਂ ਵਿਚਕਾਰ ਅੰਤਰ ਹੈ।
ਇਹ ਮੰਨ ਕੇ ਕਿ ਪ੍ਰਮਾਣੀਕਰਨ ਪਹਿਲਾਂ ਹੀ ਸੰਰਚਿਤ ਹੈ, ਜਿਵੇਂ Squid 6.13 NCSA ਸੈੱਟਅੱਪ, ਮੁੱਖ ਨੀਤੀ ਇਹ ਹੈ:
acl approved_login proxy_auth alex
acl approved_source src 192.0.2.40/32
http_access allow approved_source approved_login
http_access deny all
Squid ਜੋ ਸਰੋਤ ਅਸਲ ਵਿੱਚ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ ਉਹ ਵਰਤੋ; ਨਮੂਨਾ ਇੱਕ ਦਸਤਾਵੇਜ਼ੀ ਪਤਾ ਹੈ। ਅਸੁਰੱਖਿਅਤ ਮੰਜ਼ਿਲ ਪੋਰਟ, ਸਥਾਨਕ ਸੇਵਾਵਾਂ ਅਤੇ CONNECT ਟ੍ਰੈਫਿਕ ਲਈ ਪਹਿਲਾਂ ਦੀ ਸੁਰੱਖਿਆ ਬਰਕਰਾਰ ਰੱਖੋ। ਇਹ ਟੁਕੜਾ ਸੰਯੁਕਤ ਸ਼ਰਤ ਦਿਖਾਉਂਦਾ ਹੈ, ਪੂਰਨ ਲਿਸਨਰ ਸੰਰਚਨਾ ਨਹੀਂ।
ਇਸ ਦੇ ਉੱਪਰਲੇ ਨਿਯਮ ਜਾਂਚੋ
ਪਹਿਲਾਂ ਦੀ ਵਿਸ਼ਾਲ ਇਜਾਜ਼ਤ ਨਵੀਂ ਸ਼ਰਤ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਬੇਨਤੀ ਸਵੀਕਾਰ ਕਰ ਸਕਦੀ ਹੈ। http_access ਸੰਦਰਭ ਕ੍ਰਮਬੱਧ ਮਿਲਾਨ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ। ਸ਼ਾਮਲ ਫਾਈਲਾਂ ਸਮੇਤ ਪੂਰਾ ਕ੍ਰਮ ਪੜ੍ਹੋ।
ਵਰਤੋਂਕਾਰ ਨਾਮ ਲਈ ਇੱਕ ਇਜਾਜ਼ਤ ਅਤੇ ਸਰੋਤ ਲਈ ਦੂਜੀ ਦੋਵਾਂ ਦੀ ਮੰਗ ਨਹੀਂ ਕਰਦੀ। ਕੋਈ ਵੀ ਲਾਈਨ ਸੁਤੰਤਰ ਰੂਪ ਵਿੱਚ ਸਫਲ ਹੋ ਸਕਦੀ ਹੈ। ਉਹ ਵੱਖਰੀ ਨੀਤੀ ਹੈ।
proxy_auth ACL ਪ੍ਰਮਾਣੀਕਰਨ ਸਹਾਇਕ ਉੱਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਇਸਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨਾ ਵਰਤੋਂਕਾਰ ਬਣਾਉਣ ਜਾਂ ਪਾਸਵਰਡ ਪ੍ਰਮਾਣਿਤ ਕਰਨ ਦਾ ਤਰੀਕਾ ਨਹੀਂ ਹੈ। ਇਹ ਉਦਾਹਰਨ ਇੱਕ ਸਪੱਸ਼ਟ ਪ੍ਰੌਕਸੀ ਲਈ ਹੈ ਜਿਸ ਦੇ ਕਲਾਇੰਟ ਪ੍ਰੌਕਸੀ ਪ੍ਰਮਾਣੀਕਰਨ ਚੁਣੌਤੀਆਂ ਦਾ ਜਵਾਬ ਦੇ ਸਕਦੇ ਹਨ।
ਸਰੋਤ ਪਛਾਣ ਦੀਆਂ ਵੀ ਸੀਮਾਵਾਂ ਹਨ। ਇੱਕ NAT ਪਿੱਛੇ ਲੋਕ ਇੱਕ ਪਤਾ ਸਾਂਝਾ ਕਰ ਸਕਦੇ ਹਨ, ਅਤੇ ਘੁੰਮਦਾ ਲੈਪਟਾਪ ਪਤਾ ਬਦਲ ਸਕਦਾ ਹੈ। ਵਾਧੂ ਸ਼ਰਤ ਖਾਤੇ ਦੀ ਵਰਤੋਂਯੋਗ ਨੈੱਟਵਰਕ ਸਥਿਤੀ ਨੂੰ ਤੰਗ ਕਰਦੀ ਹੈ; ਇਹ ਭੌਤਿਕ ਕੰਪਿਊਟਰ ਦੀ ਭਰੋਸੇਯੋਗ ਪਛਾਣ ਨਹੀਂ ਕਰਦੀ। ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਇਹ ਸੀਮਾ ਤੁਸੀਂ ਸ਼ੁਰੂ ਵਿੱਚ ਸ਼ਰਤ ਜੋੜਨ ਦੇ ਕਾਰਨ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੈ।