Squid ਰਾਹੀਂ ਇੱਕ VPN ਐਂਡਪੁਆਇੰਟ: ਇੱਕ ਤੰਗ CONNECT ਛੋਟ

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

Squid ਕਿਸੇ CONNECT ਬੇਨਤੀ ਦਾ ਫੈਸਲਾ ਕਿਵੇਂ ਕਰਦਾ ਹੈ

CONNECT ਬੇਨਤੀ ਇੱਕ ਹੋਸਟ ਅਤੇ ਪੋਰਟ ਦਾ ਨਾਮ ਦਿੰਦੀ ਹੈ, ਅਤੇ Squid http_access ਲਾਈਨਾਂ ਨੂੰ ਕ੍ਰਮ ਵਿੱਚ ਲੰਘਦਾ ਹੈ ਜਦ ਤੱਕ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨਹੀਂ ਮਿਲਦੀ। ਮਿਲਦਾ ਇਨਕਾਰ ਮੁਲਾਂਕਣ ਨੂੰ ਤੁਰੰਤ ਖ਼ਤਮ ਕਰ ਦਿੰਦਾ ਹੈ ਅਤੇ ਕਲਾਇੰਟ ਨੂੰ ਪ੍ਰੌਕਸੀ ਤੋਂ 403 ਮਿਲਦਾ ਹੈ। ਇਸੇ ਲਈ ਨਿਯਮ ਦੀ ਥਾਂ ਉਸ ਦੇ ਸ਼ਬਦਾਂ ਨਾਲੋਂ ਵੱਧ ਮਾਇਨੇ ਰੱਖਦੀ ਹੈ। ਉਹੀ ਲਾਈਨ ਇੱਕ ਪੜਾਅ ਉੱਪਰ ਸਰਕਾਉਣ ਨਾਲ ਨਤੀਜਾ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਦਲ ਸਕਦਾ ਹੈ।

ਰਵਾਇਤੀ ਗਾਰਡ Safe_ports ਤੋਂ ਬਾਹਰ ਦੀ ਹਰ ਚੀਜ਼ ਇਨਕਾਰ ਕਰਦੇ ਹਨ ਅਤੇ SSL_ports ਤੋਂ ਬਾਹਰ CONNECT ਇਨਕਾਰ ਕਰਦੇ ਹਨ। ਉਹ ਨਾਮ ਤੁਹਾਡੀ ਆਪਣੀ ਸੰਰਚਨਾ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ACL ਹਨ, ਇਸ ਲਈ ਉਨ੍ਹਾਂ ਦੀ ਸਮੱਗਰੀ ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਨਹੀਂ, ਤੁਹਾਡੀ ਹੈ। ਕੋਈ ਵੰਡ Safe_ports ਵਜੋਂ ਪੋਰਟਾਂ ਦੀ ਵਿਸ਼ਾਲ ਸ਼੍ਰੇਣੀ ਦੀ ਇਜਾਜ਼ਤ ਦੇ ਕੇ CONNECT ਨੂੰ ਵੱਖਰੇ ਤੌਰ ’ਤੇ ਸੀਮਿਤ ਕਰ ਸਕਦੀ ਹੈ। ਇਹ ਮੰਨਣ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਕੋਈ ਪੋਰਟ ਡਿਜ਼ਾਈਨ ਕਰਕੇ ਬੰਦ ਹੈ, ਜੀਵਤ ਮੁੱਲ ਪੜ੍ਹੋ।

ਪੱਕਾ ਕਰੋ ਕਿ ਪ੍ਰੌਕਸੀ ਹੀ ਉਹ ਹਿੱਸਾ ਹੈ ਜੋ ਬੇਨਤੀ ਇਨਕਾਰ ਕਰ ਰਿਹਾ ਹੈ। Squid ਵੱਲੋਂ ਬਣਾਇਆ 403 VPN ਸਰਵਰ ਦੀ TLS ਚੇਤਾਵਨੀ ਵਰਗਾ ਬਿਲਕੁਲ ਨਹੀਂ ਲੱਗਦਾ, ਅਤੇ ਦੋਵਾਂ ਨੂੰ ਇੱਕ ਸਮੱਸਿਆ ਵਿੱਚ ਮਿਲਾ ਦੇਣ ਨਾਲ ਪਹਿਲਾ ਘੰਟਾ ਲੱਗ ਜਾਂਦਾ ਹੈ। ਬੇਨਤੀ ਲਈ ਪਹੁੰਚ ਲੌਗ ਦੀ ਲਾਈਨ ਵੇਖੋ, ਕਿਉਂਕਿ ਇਹ ਕਾਰਵਾਈ ਅਤੇ ਉਹ ਨਿਯਮ ਦੋਵੇਂ ਦਰਜ ਕਰਦੀ ਹੈ ਜਿਸ ਨੇ ਇਹ ਪੈਦਾ ਕੀਤਾ।

ਤਿੰਨ ਵੱਖਰੇ ACL ਦੀ ਥਾਂ ਇੱਕ ਸੰਯੁਕਤ ਮਿਲਾਨ ਬਣਾਓ

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

ਹੇਠਾਂ ਦਿੱਤਾ ਰੂਪ ਦਸਤਾਵੇਜ਼ੀ ਸ਼੍ਰੇਣੀਆਂ ਵਰਤਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਸਮੀਖਿਆ ਕੀਤੇ ਮੁੱਲਾਂ ਨਾਲ ਬਦਲਣਾ ਪਵੇਗਾ। Squid ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਨਾਮ ਆਪਣੇ ਲਈ ਰਾਖਵਾਂ ਨਹੀਂ ਰੱਖਦਾ, ਇਸ ਲਈ ਉਹ ਚੁਣਨਾ ਅਤੇ ਇਕਸਾਰ ਰੱਖਣਾ ਤੁਹਾਡਾ ਕੰਮ ਹੈ। ਇਹ ਵਿਧੀ all-of ਸਮੂਹ ਦਾ ਸਮਰਥਨ ਕਰਨ ਵਾਲੀ ਦਸਤਾਵੇਜ਼ੀ ਸੰਰਚਨਾ ਵਾਲੇ Squid 6 ਅਤੇ 7 ਤੱਕ ਸੀਮਿਤ ਹੈ। ਮੌਜੂਦਾ ਸੰਦਰਭ ਉਹ ਨਿਰਦੇਸ਼ Squid 8 ਵਿੱਚ ਅਣਉਪਲਬਧ ਦੱਸਦਾ ਹੈ, ਇਸ ਲਈ ਇਸ ਨੂੰ ਸਥਾਨਾਂਤਰਣ ਮਾਰਗ ਨਹੀਂ ਸਗੋਂ ਸੰਸਕਰਣ-ਬੱਧ ਵਿਧੀ ਮੰਨੋ, ਅਤੇ ਲਾਗੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੇ ਹੀ ਸੰਸਕਰਣ ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਨਿਰਦੇਸ਼ ਜਾਂਚੋ।

acl pvpn_src src 192.0.2.128/25
acl pvpn_dst dst 198.51.100.77/32
acl pvpn_port port 1194
acl pvpn_ok all-of CONNECT pvpn_port pvpn_dst pvpn_src

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

ਪੋਰਟ ਗਾਰਡ ਹਟਾਏ ਬਿਨਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਮੋੜੋ

ਆਪਣੀਆਂ ਮੌਜੂਦਾ ਥਾਵਾਂ ’ਤੇ ਦੋ ਰਵਾਇਤੀ ਗਾਰਡ ਲਾਈਨਾਂ ਇੰਝ ਦਿਸਦੀਆਂ ਹਨ। ਇਹ ਆਮ ਤੌਰ ’ਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਤੋਂ ਬਾਅਦ ਅਤੇ ਹਰ ਚੀਜ਼ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣ ਵਾਲੀਆਂ ਨੀਤੀ ਲਾਈਨਾਂ ਤੋਂ ਪਹਿਲਾਂ ਹੁੰਦੀਆਂ ਹਨ।

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

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

http_access deny CONNECT !SSL_ports !pvpn_ok
http_access deny !Safe_ports !pvpn_ok

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

ਛੋਟ ਕਿੱਥੇ ਨਹੀਂ ਰੱਖਣੀ ਚਾਹੀਦੀ

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

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

ਵਿਚਾਰ ਕਰੋ ਕਿ ਐਂਡਪੁਆਇੰਟ ਆਖ਼ਿਰ TCP ਹੈ ਜਾਂ ਨਹੀਂ। CONNECT ਛੋਟ TCP ਧਾਰਾਵਾਂ ਚੁੱਕਦੀ ਹੈ, ਅਤੇ UDP ਵਰਤਣ ਵਾਲੀ OpenVPN ਪਰੋਫ਼ਾਈਲ ਇਸ ਰਾਹੀਂ ਪਹੁੰਚਯੋਗ ਨਹੀਂ ਬਣੇਗੀ। ਪਰੋਫ਼ਾਈਲ ਨੂੰ TCP ਵਿੱਚ ਸਿਰਫ਼ ਤਦ ਬਦਲੋ ਜੇ ਸਰਵਰ ਇੰਝ ਸੁਣਦਾ ਹੈ ਅਤੇ ਆਪਰੇਟਰ ਵਿਵਹਾਰ ਦਾ ਫ਼ਰਕ ਮੰਨਦਾ ਹੈ।

ਪਾਰਸਰ ਅਤੇ ਅਸਲ ਬੇਨਤੀ ਨਾਲ ਹੱਦ ਜਾਂਚੋ

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

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

squid -k parse
squid -k reconfigure
curl -v -p -x http://proxy.lab.internal:3128 https://vpn.lab.internal:1194/ --max-time 5

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