Squid ਦੇ myportname ਅਤੇ src ਨੂੰ ਵੱਖਰੇ ACL ਨਾਲ ਜੋੜਨਾ

ਸੰਰਚਨਾ ਪਹਿਲੀ ਨਜ਼ਰ ਵਿੱਚ ਵਾਜਬ ਲੱਗਦੀ ਹੈ:

acl team_a myportname 3128 src 198.51.100.0/24

ਪਰ ACL ਪਰਿਭਾਸ਼ਾ ਦੀ ਇੱਕ ਹੀ ਕਿਸਮ ਹੁੰਦੀ ਹੈ। ਇੱਥੇ myportname ਕਿਸਮ ਹੈ; src ਸ਼ਬਦ ਜੋੜਨ ਨਾਲ ਦੂਜਾ ਟੈਸਟ ਸ਼ੁਰੂ ਨਹੀਂ ਹੁੰਦਾ। ਬਾਕੀ ਸ਼ਬਦ ਪਹਿਲੀ ਕਿਸਮ ਦੀ ਮੁੱਲ-ਸੂਚੀ ਵਿੱਚ ਆਉਂਦੇ ਹਨ। ਉਹ ਲਾਈਨ “ਇਹ listener ਅਤੇ ਇਹ ਕਲਾਇੰਟ ਨੈੱਟਵਰਕ” ਨਹੀਂ ਦੱਸਦੀ।

ਹਰ ਸ਼ਰਤ ਨੂੰ ਨਾਮ ਦਿਓ

ਸੁਣਨ ਵਾਲੇ socket ਲਈ ਨਾਮ ਅਤੇ ਸਰੋਤ ਲਈ ਵੱਖਰਾ ACL ਵਰਤੋ। ਇਹ ਹਿੱਸਾ ਦਸਤਾਵੇਜ਼ੀ ਪਤੇ ਵਰਤਦਾ ਹੈ, ਜਿਨ੍ਹਾਂ ਨੂੰ ਤैਨਾਤੀ ਲਈ ਢੁਕਵੇਂ ਪਤਿਆਂ ਨਾਲ ਬਦਲਣਾ ਚਾਹੀਦਾ ਹੈ:

http_port 192.0.2.10:3128 name=team_a_port
acl team_a_port myportname team_a_port
acl team_a_clients src 198.51.100.0/24

http_access allow team_a_port team_a_clients
http_access deny all

ਗੈਰ-ਸੁਰੱਖਿਅਤ ਮੰਜ਼ਿਲ ਪੋਰਟਾਂ, ਸੀਮਤ CONNECT ਟਾਰਗਟਾਂ ਅਤੇ ਪ੍ਰਬੰਧਨ ਪਹੁੰਚ ਲਈ ਮੌਜੂਦਾ ਸੁਰੱਖਿਆ ਤੋਂ ਬਾਅਦ allow ਨਿਯਮ ਰੱਖੋ। ਹਿੱਸਾ ਕਲਾਇੰਟ/listener ਸ਼ਰਤ ਦਿਖਾਉਂਦਾ ਹੈ; ਇਹ ਉਹਨਾਂ ਸੁਰੱਖਿਆਵਾਂ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈਂਦਾ।

ਇੱਕ http_access ਲਾਈਨ ਦੀਆਂ ਸ਼ਰਤਾਂ AND ਨਾਲ ਜੁੜਦੀਆਂ ਹਨ। ਦੋ ਵੱਖਰੀਆਂ allow ਲਾਈਨਾਂ ਹਰ ਸ਼ਰਤ ਨੂੰ ਸੁਤੰਤਰ ਤੌਰ ’ਤੇ ਪਾਸ ਕਰਦੀਆਂ, ਜਿਸ ਨਾਲ ਨੀਤੀ ਬਹੁਤ ਬਦਲ ਜਾਂਦੀ। ਇੱਕ ACL ਵਿੱਚ ਕਈ ਮੁੱਲ ਆਮ ਤੌਰ ’ਤੇ ਉਸ ਇੱਕ ਟੈਸਟ ਲਈ ਬਦਲ ਦਿੰਦੇ ਹਨ।

ਬਾਹਰ ਜਾਣ ਦਾ ਰਾਹ ਵੱਖਰਾ ਚੁਣੋ

ਮੇਲ ਖਾਂਦਾ listener tcp_outgoing_address ਰਾਹੀਂ ਵੀ ਸਥਾਨਕ ਸਰੋਤ ਪਤਾ ਚੁਣਨ ਲਈ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਇਹ routing ਚੋਣ ਹੈ, ਪਰਾਕਸੀ ਵਰਤਣ ਦੀ ਮਨਜ਼ੂਰੀ ਨਹੀਂ। outgoing-address ਨਿਯਮ ਰੱਦ ਕੀਤੀ ਬੇਨਤੀ ਨੂੰ http_access ਰਾਹੀਂ ਨਹੀਂ ਲੰਘਾ ਸਕਦਾ।

ਜੇ ਬਹੁ-ਪਤਾ ਸੰਰਚਨਾ ਅੱਪਗ੍ਰੇਡ ਤੋਂ ਬਾਅਦ ਕੰਮ ਕਰਨਾ ਬੰਦ ਕਰ ਦੇਵੇ, ਤਾਂ ਸਬੂਤ ਵੱਖ ਕਰੋ: parse ਗਲਤੀ ਸੰਰਚਨਾ ਸਿੰਟੈਕਸ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀ ਹੈ; access denial ਨਿਯਮ ਮਿਲਾਨ ਵੱਲ; ਗਲਤ exit ਵਾਲੀ ਮਨਜ਼ੂਰ ਬੇਨਤੀ outgoing selection ਜਾਂ ਬਾਅਦ ਦੇ NAT ਵੱਲ। ਤਿੰਨੇ ਇਕੱਠੇ ਬਦਲਣ ਨਾਲ ਛੋਟੀ ACL ਗਲਤੀ ਲੱਭਣੀ ਬਹੁਤ ਔਖੀ ਹੋ ਜਾਂਦੀ ਹੈ।