Port-Share ਕਿਉਂ ਹਰ ਵੈੱਬਸਾਈਟ ਆਗੰਤੁਕ ਨੂੰ localhost ਵਰਗਾ ਦਿਖਾਉਂਦਾ ਹੈ

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

ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਜਾਂਚਾਂ ਕੇਬਲ ਤੋਂ ਅੰਦਰ ਵੱਲ ਜਾਂਦੀਆਂ ਹਨ। ਉਸ ਪਹਿਲੀ ਜਾਂਚ 'ਤੇ ਰੁਕੋ ਜੋ ਤੁਹਾਡੇ ਦੇਖੇ ਮੁੱਲ ਦੀ ਵਿਆਖਿਆ ਕਰਦੀ ਹੈ, ਕਿਉਂਕਿ ਹਰ ਅਗਲਾ ਕਦਮ ਮੰਨਦਾ ਹੈ ਕਿ ਪਿਛਲੇ ਕਦਮ ਪਹਿਲਾਂ ਹੀ ਸਹੀ ਹਨ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਫਰੰਟ-ਐਂਡ ਸੰਰਚਨਾ ਦਾ ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਦੀ ਮੰਗ ਨਹੀਂ ਕਰਦੀ।

ਲੌਗ ਲਾਈਨ ਨਹੀਂ, ਦੋਵੇਂ ਕਨੈਕਸ਼ਨਾਂ ਦਾ ਪਿੱਛਾ ਕਰੋ

Port-Share ਇੱਕ TCP ਸਰੋਤੇ 'ਤੇ ਦੋ ਪ੍ਰੋਟੋਕੋਲ ਮਲਟੀਪਲੈਕਸ ਕਰਦਾ ਹੈ। OpenVPN ਆ ਰਹੇ ਕਨੈਕਸ਼ਨ ਦੇ ਪਹਿਲੇ ਬਾਈਟ ਜਾਂਚਦਾ ਹੈ, ਜਦੋਂ ਇਹ ਆਪਣੇ ਪ੍ਰੋਟੋਕੋਲ ਵਰਗਾ ਦਿਸਦਾ ਹੈ ਤਾਂ ਇਸਨੂੰ ਰੱਖ ਲੈਂਦਾ ਹੈ, ਅਤੇ ਬਾਕੀ ਸਭ ਕੁਝ ਦੂਜੀ ਮੰਜ਼ਿਲ 'ਤੇ ਭੇਜ ਦਿੰਦਾ ਹੈ। ਉਹ ਮੰਜ਼ਿਲ ਆਮ ਤੌਰ 'ਤੇ ਉਸੇ ਹੋਸਟ ਦਾ ਵੈੱਬ ਸਰਵਰ ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ ਵੈੱਬ ਸਰਵਰ ਦੇ ਸਵੀਕਾਰ ਕੀਤੇ ਸਾਕਟ ਦਾ ਸਾਥੀ OpenVPN ਪ੍ਰਕਿਰਿਆ ਹੁੰਦਾ ਹੈ।

ss -ltnp 'sport = :443'
ss -tnp 'dport = :8080'

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

ਇਹੀ ਉਹ ਜਾਂਚ ਹੈ ਜੋ ਬਾਕੀ ਸਭ ਤੈਅ ਕਰਦੀ ਹੈ। ਜੇ ਬੈਕਐਂਡ ਦਾ ਸਾਥੀ ਬ੍ਰਾਊਜ਼ਰ ਦਾ ਪਤਾ ਹੈ, ਤਾਂ ਪੋਰਟ ਸਾਂਝਾ ਕਰਨਾ ਤੁਹਾਡੀ ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ ਅਤੇ ਲੌਗ ਫਾਰਮੈਟ ਹੈ।

ਟਰਾਂਸਪੋਰਟ ਫਾਰਵਰਡਿੰਗ ਹੈਡਰ ਇੰਜੈਕਸ਼ਨ ਨਹੀਂ ਹੈ

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

ਮੂਲ ਪਤਾ ਦੋ ਵਿਧੀਆਂ ਲਿਜਾ ਸਕਦੀਆਂ ਹਨ, ਅਤੇ ਦੋਵਾਂ ਨੂੰ ਦੋਵੇਂ ਸਿਰਿਆਂ 'ਤੇ ਸਹਿਮਤੀ ਚਾਹੀਦੀ ਹੈ। PROXY ਪ੍ਰੋਟੋਕੋਲ ਕਨੈਕਸ਼ਨ ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਛੋਟਾ ਹੈਡਰ ਜੋੜਦਾ ਹੈ, ਅਤੇ ਬੈਕਐਂਡ ਨੂੰ ਇਸਦੀ ਉਮੀਦ ਲਈ ਸੰਰਚਿਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ; ਜੋ ਬੈਕਐਂਡ ਇਸਦੀ ਉਮੀਦ ਨਹੀਂ ਕਰਦਾ ਉਹ ਉਹਨਾਂ ਬਾਈਟਾਂ ਨੂੰ ਬੇਨਤੀ ਦੀ ਸ਼ੁਰੂਆਤ ਮੰਨ ਕੇ ਉਲਝਣ ਭਰੇ ਢੰਗ ਨਾਲ ਅਸਫਲ ਹੋਵੇਗਾ। X-Forwarded-For ਵਰਗੇ ਭਰੋਸੇਯੋਗ ਪ੍ਰੌਕਸੀ ਹੈਡਰ ਤਦ ਕੰਮ ਕਰਦੇ ਹਨ ਜਦੋਂ HTTP ਸਮਝਣ ਵਾਲਾ ਪ੍ਰੌਕਸੀ ਉਹਨਾਂ ਨੂੰ ਸੈੱਟ ਕਰਦਾ ਹੈ ਅਤੇ ਬੈਕਐਂਡ ਨੂੰ ਦੱਸਿਆ ਜਾਂਦਾ ਹੈ ਕਿ ਕਿਹੜੇ ਸਾਥੀ ਉਹਨਾਂ ਦਾ ਦਾਅਵਾ ਕਰ ਸਕਦੇ ਹਨ।

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

curl -sS -H 'X-Forwarded-For: 127.0.0.1' https://site.example.com/health
grep -F '127.0.0.1' /var/log/nginx/access.log | tail -n 3

ਵਿਕਲਪਿਕ ਸਰੋਤ-ਮੈਪਿੰਗ ਡਾਇਰੈਕਟਰੀ

ਪੋਰਟ ਸਾਂਝਾ ਕਰਨ ਵਿੱਚ ਵਿਕਲਪਿਕ ਡਾਇਰੈਕਟਰੀ ਆਰਗਿਊਮੈਂਟ ਹੈ ਜੋ ਉਹਨਾਂ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਮੂਲ ਸਰੋਤ ਪਤੇ ਅਤੇ ਫਾਰਵਰਡਿੰਗ ਕਨੈਕਸ਼ਨ ਵਿਚਕਾਰ ਮੈਪਿੰਗ ਦਰਜ ਕਰਦਾ ਹੈ ਜਿੱਥੇ ਇਹ ਵਿਸ਼ੇਸ਼ਤਾ ਲਾਗੂ ਕੀਤੀ ਗਈ ਹੈ। ਵੈੱਬ ਪਾਸੇ ਤੋਂ ਉਸ ਮੈਪਿੰਗ ਦੀ ਸਲਾਹ ਲੈਣ ਦੀ ਉਮੀਦ ਹੈ; ਇਹ ਹੈਡਰ ਨਹੀਂ ਹੈ, ਅਤੇ ਇਹ ਬੇਨਤੀ ਵਿੱਚ ਨਹੀਂ ਪਾਇਆ ਜਾਂਦਾ।

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

ਜੇ ਤੁਸੀਂ ਇਹ ਰਾਹ ਚੁਣਦੇ ਹੋ, ਤਾਂ ਇਸਨੂੰ ਦੋ ਅੱਧਾਂ ਦਾ ਏਕੀਕਰਣ ਮੰਨੋ: ਫਾਰਵਰਡਰ ਵੱਲੋਂ ਲਿਖੀ ਮੈਪਿੰਗ ਅਤੇ ਬੈਕਐਂਡ ਵੱਲੋਂ ਕੀਤੀ ਖੋਜ। ਦੋਵੇਂ ਜਾਂਚੋ, ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਡਾਇਰੈਕਟਰੀ ਰੀਸਟਾਰਟ ਤੋਂ ਬਾਅਦ ਵੀ ਰਹਿੰਦੀ ਹੈ ਅਤੇ ਰੁਝੇ ਸਰੋਤੇ 'ਤੇ ਬੇਹੱਦ ਨਹੀਂ ਵਧਦੀ।

ਤੈਅ ਕਰੋ ਕਿ ਕਿਹੜਾ ਹਿੱਸਾ ਪਤੇ ਦੀ ਗਾਰੰਟੀ ਦਿੰਦਾ ਹੈ

ਸੰਰਚਨਾ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਉਸ ਹਿੱਸੇ ਦਾ ਨਾਮ ਲਓ ਜਿਸਨੂੰ ਕਲਾਇੰਟ ਪਤਾ ਦਾਅਵਾ ਕਰਨ ਦੀ ਆਗਿਆ ਹੈ ਅਤੇ ਉਹਨਾਂ ਹਿੱਸਿਆਂ ਦਾ ਜਿਨ੍ਹਾਂ ਨੂੰ ਇਸ 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਦੀ ਆਗਿਆ ਹੈ। ਇੱਕ ਲਿਖਿਆ ਜਵਾਬ ਆਮ ਵਹਿਣ ਨੂੰ ਰੋਕਦਾ ਹੈ, ਜਿੱਥੇ ਤਿੰਨ ਵੱਖਰੀਆਂ ਪਰਤਾਂ ਹਰ ਇੱਕ ਵੱਖਰੇ ਸਰੋਤ 'ਤੇ ਭਰੋਸਾ ਕਰਦੀ ਹੈ।

ਤਿੰਨ ਡਿਜ਼ਾਈਨ ਬਹੁਤੀਆਂ ਲੋੜਾਂ ਪੂਰੀਆਂ ਕਰਦੇ ਹਨ। ਜਨਤਕ ਸਰੋਤਾ ਅਤੇ ਵੈੱਬ ਸਰੋਤਾ ਵੱਖਰੇ ਰੱਖੋ, ਤਾਂ ਜੋ ਵੈੱਬ ਸਰਵਰ ਅਸਲ ਸਾਥੀ ਦੇਖੇ ਅਤੇ ਐਟ੍ਰਿਬਿਊਸ਼ਨ ਦੀ ਕੋਈ ਸਮੱਸਿਆ ਨਾ ਰਹੇ। ਸਾਹਮਣੇ HTTP ਸਮਝਣ ਵਾਲਾ ਰਿਵਰਸ ਪ੍ਰੌਕਸੀ ਰੱਖੋ, ਬੇਨਤੀ ਉੱਥੇ ਹੀ ਖਤਮ ਜਾਂ ਪਾਰਸ ਕਰੋ, ਅਤੇ ਸਿਰਫ਼ ਉਸੇ ਪ੍ਰੌਕਸੀ 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਵਾਲੇ ਬੈਕਐਂਡ ਲਈ ਫਾਰਵਰਡ ਕੀਤਾ ਹੈਡਰ ਸੈੱਟ ਕਰਨ ਦਿਓ। ਜਾਂ ਪੋਰਟ ਸਾਂਝਾ ਕਰਨਾ ਰੱਖੋ ਅਤੇ ਮੰਨ ਲਓ ਕਿ ਲੌਗ ਹੌਪ ਦਿਖਾਉਂਦੇ ਹਨ, ਐਕਸੈਸ ਨਿਯਮ ਪਤੇ ਵਿਰੁੱਧ ਨਹੀਂ ਸਗੋਂ ਐਪਲੀਕੇਸ਼ਨ ਪਛਾਣ ਵਿਰੁੱਧ ਲਿਖੇ ਜਾਣਗੇ।

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

ਨਿਯਮ ਦੀ ਪਰਖ ਕਰੋ, ਪੰਨੇ ਦੀ ਨਹੀਂ

ਲੋਡ ਹੁੰਦਾ ਪੰਨਾ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਫਾਰਵਰਡਿੰਗ ਮਾਰਗ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਐਟ੍ਰਿਬਿਊਸ਼ਨ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ। ਪਤੇ ਦੇ ਵਰਤੋਂਕਾਰ ਦੀ ਪਰਖ ਕਰੋ: ਐਕਸੈਸ ਨਿਯਮ, ਦਰ ਸੀਮਾ, ਆਡਿਟ ਐਂਟਰੀ, ਭੂਗੋਲਿਕ ਖੋਜ।

curl -sS -o /dev/null -w '%{http_code}\n' https://site.example.com/
tail -n 5 /var/log/nginx/access.log
grep -c '' /var/log/nginx/access.log

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

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