Tinyproxy ਵਿੱਚ Listen, Bind ਅਤੇ BindSame: ਕਿਹੜਾ ਪਤਾ ਜਿੱਤਦਾ ਹੈ
Listen ਉਹ ਪਤਾ ਚੁਣਦਾ ਹੈ ਜੋ ਗਾਹਕਾਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, Bind ਬਾਹਰ ਜਾਣ ਵਾਲੇ ਕਨੈਕਸ਼ਨਾਂ ਦਾ ਸਰੋਤ ਚੁਣਦਾ ਹੈ। ਦੋਵੇਂ ਵਿੱਚੋਂ ਕੋਈ ਰੂਟ ਨਹੀਂ ਲਾਉਂਦਾ, ਇਸ ਲਈ ਮਾਰਗ ਦੀ ਵੱਖਰੀ ਜਾਂਚ ਕਰੋ।
ਪਰਾਕਸੀ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਬੇਨਤੀ ਪੂਰੀ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਫਿਰ ਵੀ ਮੰਜ਼ਿਲ ਹਾਲੇ ਵੀ ਲੈਨ ਪਤਾ ਦਰਜ ਕਰਦੀ ਹੈ। ਪਰਾਕਸੀ ਲਾਗ ਵਿੱਚ ਕੁਝ ਵੀ ਗਲਤ ਨਹੀਂ ਦਿਸਦਾ, ਅਤੇ ਜੋ ਲਾਈਨ ਤੁਸੀਂ ਬਦਲੀ ਉਹੀ ਲਾਈਨ ਹੈ ਜਿਸ ਨੂੰ ਬਦਲਣ ਲਈ ਦਸਤਾਵੇਜ਼ ਨੇ ਕਿਹਾ ਸੀ। ਜਿਸ ਹੋਸਟ ਕੋਲ ਲੈਨ ਪਤਾ ਅਤੇ ਟਨਲ ਪਤਾ ਦੋਵੇਂ ਹਨ, ਉੱਥੇ ਤਿੰਨ ਨਿਰਦੇਸ਼ ਤੈਅ ਕਰਦੇ ਹਨ ਕਿ ਕਿਹੜਾ ਪਤਾ ਕਿੱਥੇ ਦਿਸੇਗਾ, ਅਤੇ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਬਾਹਰ ਜਾਣ ਵਾਲੇ ਪਾਸੇ ਨਾਲ ਸਬੰਧਤ ਹੈ। ਗਲਤ ਕ੍ਰਮ ਵਿੱਚ ਪੜ੍ਹੋ ਤਾਂ ਬਿਨਾਂ ਕਾਰਨ ਰੂਟਿੰਗ ਟੇਬਲ ਵਿੱਚ ਪਹੁੰਚ ਜਾਓਗੇ।
ਲੱਛਣ: ਮੰਜ਼ਿਲ ਲੈਨ ਪਤਾ ਦੇਖਦੀ ਹੈ
ਇੱਕ ਗਾਹਕ ਲੈਨ ਪਤੇ ’ਤੇ ਪਰਾਕਸੀ ਨਾਲ ਜੁੜਦਾ ਹੈ, ਅਤੇ ਪਰਾਕਸੀ ਮੰਜ਼ਿਲ ਵੱਲ ਆਪਣਾ ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹਦਾ ਹੈ। ਉਹ ਦੂਜਾ ਕਨੈਕਸ਼ਨ ਕਰਨਲ ਦੇ ਨਿਯਮਾਂ ਅਨੁਸਾਰ ਸਰੋਤ ਪਤਾ ਚੁਣਦਾ ਹੈ, ਅਤੇ ਡਿਫ਼ਾਲਟ ਰੂਪ ਵਿੱਚ ਉਹੀ ਹੁੰਦਾ ਹੈ ਜੋ ਰੂਟ ਖੋਜ ਚੁਣਦੀ ਹੈ। ਇਸ ਲਈ ਹਰ ਬਾਈਟ ਪਰਾਕਸੀ ਵਿੱਚੋਂ ਗੁਜ਼ਰਨ ਦੇ ਬਾਵਜੂਦ ਮੰਜ਼ਿਲ ਹੋਸਟ ਦਾ ਮੁੱਢਲਾ ਪਤਾ ਦਰਜ ਕਰਦੀ ਹੈ। ਫਾਰਵਰਡਿੰਗ ਦੇ ਲਿਹਾਜ਼ ਨਾਲ ਕੁਝ ਟੁੱਟਿਆ ਨਹੀਂ, ਅਤੇ ਇਸੇ ਲਈ ਪਰਾਕਸੀ ਲਾਗ ਕੋਲ ਇਸ ਬਾਰੇ ਕਹਿਣ ਲਈ ਕੁਝ ਨਹੀਂ।
ਉਸ ਖ਼ਰਾਬੀ ਦੀ ਸ਼ੀਸ਼ੇ ਵਾਲੀ ਤਸਵੀਰ ਪਛਾਣਨੀ ਸੌਖੀ ਹੈ: ਬਾਹਰ ਜਾਣ ਵਾਲੇ ਸਰੋਤ ਨੂੰ ਟਨਲ ਪਤੇ ’ਤੇ ਪਿੰਨ ਕਰੋ ਅਤੇ ਲੈਨ ਗਾਹਕ ਸਰੋਤੇ ਤੱਕ ਪਹੁੰਚਣਾ ਹੀ ਬੰਦ ਕਰ ਦੇਣਗੇ। ਉਹ ਸੰਸਕਰਣ ਆਪਣੀ ਘੋਸ਼ਣਾ ਆਪ ਕਰਦਾ ਹੈ, ਜਦਕਿ ਪਹਿਲਾ ਕੰਮ ਕਰ ਰਹੀ ਬੇਨਤੀ ਪਿੱਛੇ ਲੁਕਦਾ ਹੈ। ਦੋਵੇਂ ਇੱਕ ਨਿਰਦੇਸ਼ ਨੂੰ ਇੰਝ ਸਮਝਣ ਤੋਂ ਆਉਂਦੇ ਹਨ ਜਿਵੇਂ ਉਹ ਦੋਵੇਂ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੋਵੇ।
ਤਿੰਨ ਨਿਰਦੇਸ਼, ਤਿੰਨ ਵੱਖਰੇ ਪਤੇ
Listen ਉਸ ਸਥਾਨਕ ਪਤੇ ਦਾ ਨਾਂ ਲੈਂਦਾ ਹੈ ਜੋ ਪਰਾਕਸੀ ਗਾਹਕਾਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ। Bind ਬਾਹਰ ਵੱਲ ਪਰਾਕਸੀ ਜੋ ਕਨੈਕਸ਼ਨ ਬਣਾਉਂਦਾ ਹੈ ਉਨ੍ਹਾਂ ਲਈ ਸਰੋਤ ਪਤਾ ਦਿੰਦਾ ਹੈ, ਅਤੇ BindSame ਉਸ ਨੂੰ ਕਹਿੰਦਾ ਹੈ ਕਿ ਹੁਣੇ ਸਵੀਕਾਰ ਕੀਤੇ ਕਨੈਕਸ਼ਨ ਦਾ ਸਥਾਨਕ ਪਤਾ ਦੁਬਾਰਾ ਵਰਤੇ। ਇਹ ਤਿੰਨ ਵੱਖਰੇ ਸਵਾਲ ਹਨ, ਅਤੇ ਇੱਕ ਲਾਈਨ ਸਿਰਫ਼ ਇੱਕ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ। ਇਨ੍ਹਾਂ ਨੂੰ ਮਿਲਾਉਣਾ ਹੀ ਆਮ ਕਾਰਨ ਹੈ ਕਿ ਬਦਲਾਅ ਕੁਝ ਨਾ ਕਰਦਾ ਲੱਗਦਾ ਹੈ।
| What you observe | Check first |
|---|---|
| A client cannot connect at all | Listen: the local address the listener binds |
| The request works but the far side logs the LAN address | Bind: the outgoing source is not being applied |
| A configured Bind appears to have no effect | BindSame yes: the accepted local address overrides the Bind list |
| The lookup names the LAN interface | The route, not the proxy: the source cannot reach that destination |
ਸਥਾਪਿਤ ਸੰਸਕਰਣ ਨਾਲ ਆਉਣ ਵਾਲੀ ਟਿੱਪਣੀ ਵਾਲੀ ਸੰਰਚਨਾ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ ਡਿਫ਼ਾਲਟ ਮੁੱਲ ਅਤੇ ਸਵੀਕਾਰਯੋਗ ਸਿੰਟੈਕਸ ਸੰਸਕਰਣਾਂ ਵਿਚਕਾਰ ਬਦਲਦੇ ਹਨ। ਪਰੋਜੈਕਟ ਦੀ ਨਮੂਨਾ ਸੰਰਚਨਾ ਹਰ ਨਿਰਦੇਸ਼ ਨੂੰ ਦੂਜਿਆਂ ਦੇ ਕੋਲ ਦਸਤਾਵੇਜ਼ਬੱਧ ਕਰਦੀ ਹੈ। ਉਸ ਫ਼ਾਈਲ ਦੀ ਡਿਸਕ ’ਤੇ ਪਈ ਫ਼ਾਈਲ ਨਾਲ ਤੁਲਨਾ ਕਰੋ, ਕਿਸੇ ਹੋਰ ਵੰਡ ਲਈ ਲਿਖੀ ਗਾਈਡ ਨਾਲ ਨਹੀਂ।
ਸਰੋਤਾ ਅਤੇ ਬਾਹਰ ਜਾਣ ਵਾਲਾ ਸਰੋਤ ਵੱਖਰੇ ਤੌਰ ’ਤੇ ਸੈੱਟ ਕਰੋ
ਅਜਿਹਾ ਹੋਸਟ ਲਵੋ ਜਿਸ ਦਾ ਲੈਨ ਪਤਾ 192.168.50.10 ਅਤੇ ਟਨਲ ਪਤਾ 10.90.0.3 ਹੈ। ਜੇ ਲੈਨ ਗਾਹਕਾਂ ਨੂੰ ਪਰਾਕਸੀ ਤੱਕ ਪਹੁੰਚਣਾ ਹੈ ਅਤੇ ਉਨ੍ਹਾਂ ਦੀਆਂ ਬੇਨਤੀਆਂ ਟਨਲ ਵਿੱਚੋਂ ਬਾਹਰ ਜਾਣੀਆਂ ਹਨ, ਤਾਂ ਇਹ ਦੋ ਸੁਤੰਤਰ ਫ਼ੈਸਲੇ ਹਨ ਅਤੇ ਦੋਵੇਂ ਲਿਖਣੇ ਪੈਣਗੇ। ਹੇਠਲਾ ਹਿੱਸਾ ਠੀਕ ਇਹੀ ਕਹਿੰਦਾ ਹੈ, ਇਸ ਤੋਂ ਵੱਧ ਕੁਝ ਨਹੀਂ।
Listen 192.168.50.10
Bind 10.90.0.3
BindSame noਇਹ ਪੂਰੀ ਸੰਰਚਨਾ ਨਹੀਂ, ਇਸ ਲਈ ਮਨਜ਼ੂਰ ਪੋਰਟ, ਪਰਮਾਣਿਕਤਾ, ਗਾਹਕ ਪਹੁੰਚ ਨਿਯੰਤਰਣ ਅਤੇ ਮੰਜ਼ਿਲ ਸੀਮਾਵਾਂ ਰੱਖੋ। ਦੋਵੇਂ ਪਤੇ Tinyproxy ਦੇ ਨੈੱਟਵਰਕ ਨਾਮ-ਥਾਂ ਦੇ ਅੰਦਰ ਇਸ ਹੋਸਟ ਦੇ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਕਿਉਂਕਿ ਜਿਸ Bind ਮੁੱਲ ਦਾ ਪ੍ਰਕਿਰਿਆ ਮਾਲਕ ਨਹੀਂ ਹੋ ਸਕਦੀ ਉਹ ਸ਼ੁਰੂ ਵੇਲੇ ਨਹੀਂ, ਕਨੈਕਟ ਵੇਲੇ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ। BindSame yes ਦੂਜੀ ਨੀਤੀ ਦੱਸਦਾ ਹੈ, ਜਿੱਥੇ ਸਵੀਕਾਰ ਕੀਤੇ ਕਨੈਕਸ਼ਨ ਦਾ ਸਥਾਨਕ ਪਤਾ ਹੀ ਬਾਹਰ ਜਾਣ ਵਾਲਾ ਸਰੋਤ ਬਣਦਾ ਹੈ। ਮੌਜੂਦਾ ਸੰਸਕਰਣਾਂ ਵਿੱਚ ਉਸ ਸ਼ਾਖਾ ਨੂੰ Bind ਸੂਚੀ ਉੱਤੇ ਤਰਜੀਹ ਹੈ, ਅਤੇ ਇਸੇ ਤਰ੍ਹਾਂ ਸੰਰਚਿਤ ਸਰੋਤ ਬਿਨਾਂ ਕਿਸੇ ਗਲਤੀ ਦੇ ਗ਼ਾਇਬ ਹੋ ਜਾਂਦਾ ਹੈ।
ਸਰੋਤ ਜੋ ਮਾਰਗ ਸੰਕੇਤ ਕਰਦਾ ਹੈ ਉਸ ਦੀ ਜਾਂਚ ਕਰੋ
ਸਰੋਤ ਪਤਾ ਚੁਣਨ ਨਾਲ ਮਾਰਗ ਨਹੀਂ ਬਣਦਾ, ਇਸ ਲਈ ਕਰਨਲ ਨੂੰ ਪੁੱਛੋ ਕਿ ਉਹ ਉਸ ਸਰੋਤ ਅਤੇ ਉਸ ਮੰਜ਼ਿਲ ਨਾਲ ਕੀ ਕਰੇਗਾ। ਜੋ ਖੋਜ ਟਨਲ ਇੰਟਰਫ਼ੇਸ ਦਾ ਨਾਂ ਲੈਂਦੀ ਹੈ ਉਹ ਘੱਟੋ-ਘੱਟ ਸਬੂਤ ਹੈ, ਅਤੇ ਜੋ ਲੈਨ ਇੰਟਰਫ਼ੇਸ ਦਾ ਨਾਂ ਲੈਂਦੀ ਹੈ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸਰੋਤ ਲਿਖੇ ਅਨੁਸਾਰ ਕੰਮ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਖੋਜ ਪ੍ਰਸੰਗਿਕ ਹੈ: ਇਹ ਉਸ ਨਾਮ-ਥਾਂ ਲਈ ਲਾਗੂ ਨੀਤੀ ਨਿਯਮਾਂ ਅਤੇ ਟੇਬਲ ਦਾ ਮੁਲਾਂਕਣ ਕਰਦੀ ਹੈ। ਇਹ ਕਨੈਕਸ਼ਨ ਨਹੀਂ ਹੈ, ਅਤੇ ਇਹ ਨਹੀਂ ਦੱਸਦੀ ਕਿ ਹੇਠਲਾ NAT ਸੇਵਾ ਨੂੰ ਕੀ ਪੇਸ਼ ਕਰੇਗਾ।
ip -4 route get 203.0.113.25 from 10.90.0.3ਉਦਾਹਰਨ ਵਿੱਚ ਦਸਤਾਵੇਜ਼ੀ ਪਤਾ ਵਰਤੋ ਅਤੇ ਜਿਸ ਸੇਵਾ ਦੀ ਜਾਂਚ ਦੀ ਤੁਹਾਨੂੰ ਇਜਾਜ਼ਤ ਹੈ ਉਹ ਰੱਖੋ। ਜਦੋਂ ਪਰਾਕਸੀ ਕੰਟੇਨਰ ਵਿੱਚ ਚੱਲਦਾ ਹੈ ਤਾਂ ਖੋਜ ਪਰਾਕਸੀ ਦੇ ਨਾਮ-ਥਾਂ ਦੇ ਅੰਦਰ ਚਲਾਓ, ਕਿਉਂਕਿ ਹੋਸਟ ਦੇ ਨਿਯਮ ਉਹ ਨਿਯਮ ਨਹੀਂ ਜੋ ਪ੍ਰਕਿਰਿਆ ਦੇਖਦੀ ਹੈ। ਜੇ ਚਾਹਿਆ ਟਨਲ ਮਾਰਗ ਨਹੀਂ ਹੈ ਤਾਂ ਪਰਾਕਸੀ ਹੋਸਟ ’ਤੇ ਮੰਜ਼ਿਲ-ਖ਼ਾਸ ਨਿਯਮ ਜੋੜਨ ਦੀ ਥਾਂ ਨੈੱਟਵਰਕ ਮਾਲਕ ਨੂੰ ਉਹ ਠੀਕ ਕਰਨ ਦਿਓ। ਖੋਜ ਸਫਲ ਹੋਣ ਲਈ ਹੋਸਟ ਰੂਟ ਸਾਫ਼ ਨਾ ਕਰੋ ਅਤੇ ਸਰਵਰ ਵੱਲੋਂ ਭੇਜੇ ਰੂਟ ਬੰਦ ਨਾ ਕਰੋ, ਭਾਵੇਂ ਪੁਰਾਣੀ ਗਾਈਡ ਨੇ ਇਸੇ ਤਰ੍ਹਾਂ ਕੀਤਾ ਹੋਵੇ, ਕਿਉਂਕਿ ਅਜਿਹੇ ਬਦਲਾਅ ਇੱਕ ਪਰਾਕਸੀ ਮਾਰਗ ਠੀਕ ਕਰਨ ਲਈ ਪੂਰੇ ਹੋਸਟ ਦਾ ਮਨਜ਼ੂਰ VPN ਵਿਵਹਾਰ ਹਿਲਾ ਦਿੰਦੇ ਹਨ।
ਮੰਜ਼ਿਲ ’ਤੇ ਸਰੋਤ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ
ਸਰੋਤ ਉੱਥੇ ਪੜ੍ਹੋ ਜਿੱਥੇ ਬੇਨਤੀ ਪਹੁੰਚਦੀ ਹੈ, ਨਾ ਕਿ ਜਿੱਥੋਂ ਨਿਕਲਦੀ ਹੈ। ਮੰਜ਼ਿਲ ਦੀ ਐਪਲੀਕੇਸ਼ਨ ਲਾਗ, ਜਾਂ ਉਸ ਦੇ ਸਾਹਮਣੇ ਵਾਲਾ ਐਜ਼ ਉਪਕਰਣ, ਉਹ ਪਤਾ ਦਰਜ ਕਰਦੀ ਹੈ ਜੋ ਉਸ ਨੇ ਸੱਚਮੁੱਚ ਦੇਖਿਆ, ਜਦਕਿ ਪਰਾਕਸੀ ਸਿਰਫ਼ ਆਪਣਾ ਇਰਾਦਾ ਦੱਸ ਸਕਦਾ ਹੈ। ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਚਾਹੇ ਸਰੋਤੇ ਰਾਹੀਂ ਇੱਕ ਨਵੀਂ ਬੇਨਤੀ ਕਰੋ, ਕਿਉਂਕਿ ਕੈਸ਼ ਵਿੱਚ ਪਿਆ ਕਨੈਕਸ਼ਨ ਨਵੀਂ ਬੰਨ੍ਹਤ ਬਾਰੇ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ। ਫਿਰ ਦਰਜ ਪਤੇ ਦੀ ਤੁਲਨਾ ਤੁਹਾਡੇ ਸੈੱਟ ਕੀਤੇ ਪਤੇ ਨਾਲ ਕਰੋ।
ss -ltnp | grep tinyproxy
curl -x http://192.168.50.10:8888 https://example.com -o /dev/null -sScurl ਸਿਰਫ਼ ਟ੍ਰੈਫ਼ਿਕ ਪੈਦਾ ਕਰਨ ਵਾਲਾ ਹੈ; ਜਾਂਚ ਯੋਗ ਪਤਾ ਉਹ ਹੈ ਜੋ ਦੂਰਲੇ ਪਾਸੇ ਦਰਜ ਕੀਤਾ, ਨਾ ਕਿ ਉਹ ਸਾਥੀ ਜਿਸ ਨਾਲ curl ਸੰਜੋਗਵੱਸ਼ ਜੁੜਿਆ। ਜੇ ਦੋਵੇਂ ਨਾ ਮਿਲਣ ਤਾਂ ਤੈਅ ਕਰੋ ਕਿ ਫ਼ਰਕ ਸਰੋਤ-ਚੋਣ ਤੋਂ ਆ ਰਿਹਾ ਹੈ ਜਾਂ ਅੱਗੇ ਦੇ ਰੂਪਾਂਤਰਣ ਤੋਂ, ਕਿਉਂਕਿ ਉਹ ਵੱਖਰੀਆਂ ਥਾਵਾਂ ’ਤੇ ਠੀਕ ਹੁੰਦੇ ਹਨ। ਪਤਾ ਬਦਲਾਅ ਅਤੇ ਪਰਾਕਸੀ ਮੁੜ-ਸ਼ੁਰੂਆਤ ਇਕੱਠੇ ਯੋਜਨਾ ਬਣਾਓ, ਕਿਉਂਕਿ ਟਨਲ ਕੋਲ ਹੁਣ ਨਾ ਰਹੇ ਪਤੇ ਨੂੰ ਬੰਨ੍ਹਣਾ ਮੁੜ-ਜੁੜਨ ਤੋਂ ਬਾਅਦ ਚੁੱਪਚਾਪ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ। DNS ਅਤੇ IPv6 ਵਿਵਹਾਰ ਵੀ ਵੱਖਰੇ ਤੌਰ ’ਤੇ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ, ਕਿਉਂਕਿ ਉੱਪਰਲਾ IPv4 ਹਿੱਸਾ ਦੋਵਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਬਾਰੇ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ।