OpenVPN ਦਾ UDP ਜਵਾਬ ਗਲਤ ਪਤੇ ਤੋਂ ਕਿਉਂ ਨਿਕਲਦਾ ਹੈ
ਕਈ ਸਥਾਨਕ ਪਤਿਆਂ ਵਾਲਾ UDP ਸਰਵਰ ਕਲਾਇੰਟ ਨੂੰ ਉਸ ਪਤੇ ਤੋਂ ਵੱਖਰੇ ਪਤੇ ਤੋਂ ਜਵਾਬ ਦੇ ਸਕਦਾ ਹੈ ਜਿਸ ਨਾਲ ਉਸਨੇ ਸੰਪਰਕ ਕੀਤਾ। multihome ਸਮਰਥਿਤ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਸਰੋਤ ਠੀਕ ਕਰਦਾ ਹੈ।
OpenVPN ਕਲਾਇੰਟ ਇੱਕ ਪਤੇ 'ਤੇ ਡਾਇਲ ਕਰਦਾ ਹੈ, ਸਰਵਰ ਦੂਜੇ ਪਤੇ ਤੋਂ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਟਨਲ ਕਦੇ ਨਹੀਂ ਉੱਠਦਾ। ਸਰਵਰ ਲਾਗ ਪੈਕਟ ਆਉਂਦਾ ਦਿਖਾਉਂਦੀ ਹੈ ਅਤੇ ਕੈਪਚਰ ਜਵਾਬ ਜਾਂਦਾ ਦਿਖਾਉਂਦਾ ਹੈ, ਇਸ ਲਈ ਗਲਤੀ ਕਲਾਇੰਟ 'ਤੇ ਪਾਈ ਜਾਂਦੀ ਹੈ। ਕਈ ਇੰਟਰਫੇਸ ਵਾਲੇ ਹੋਸਟ 'ਤੇ, ਜਾਂ ਇੱਕ ਇੰਟਰਫੇਸ 'ਤੇ ਕਈ ਪਤਿਆਂ ਵੇਲੇ, ਦੋਵੇਂ ਧਿਰਾਂ ਇਸ ਗੱਲ 'ਤੇ ਸਹਿਮਤ ਨਹੀਂ ਹੁੰਦੀਆਂ ਕਿ ਕਿਹੜਾ ਪਤਾ ਵਰਤਿਆ ਜਾ ਰਿਹਾ ਹੈ। ਜਵਾਬ IP ਪਰਤ 'ਤੇ ਜਾਇਜ਼ ਹੈ, ਪਰ ਬਹੁਤ ਸਾਰੇ ਕਲਾਇੰਟ ਅਜਿਹਾ ਡੇਟਾਗ੍ਰਾਮ ਛੱਡ ਦਿੰਦੇ ਹਨ ਜਿਸਦਾ ਸਰੋਤ ਉਹ ਪਤਾ ਨਹੀਂ ਜੋ ਉਨ੍ਹਾਂ ਨੇ ਸੰਪਰਕ ਕੀਤਾ ਸੀ।
ਸਰੋਤ ਬਦਲਣ 'ਤੇ ਕਲਾਇੰਟ ਕੀ ਦੇਖਦਾ ਹੈ
ਜੋ UDP ਸਾਕਟ ਕਿਸੇ ਖਾਸ ਸਥਾਨਕ ਪਤੇ ਨਾਲ ਬੱਝਾ ਨਹੀਂ, ਉਸਦਾ ਕੋਈ ਸਥਿਰ ਸਰੋਤ ਨਹੀਂ ਹੁੰਦਾ, ਇਸ ਲਈ ਕਰਨਲ ਭੇਜਣ ਵੇਲੇ ਇੱਕ ਚੁਣਦਾ ਹੈ। ਇਹ ਚੋਣ ਕਲਾਇੰਟ ਦੇ ਪਤੇ ਵੱਲ ਰੂਟ ਖੋਜ ਤੋਂ ਆਉਂਦੀ ਹੈ, ਅਤੇ ਸਰੋਤ ਉਸ ਇੰਟਰਫੇਸ ਦਾ ਪਤਾ ਬਣ ਜਾਂਦਾ ਹੈ ਜੋ ਖੋਜ ਚੁਣਦੀ ਹੈ। ਇੱਕ ਇੰਟਰਫੇਸ ਵਾਲੀ ਮਸ਼ੀਨ 'ਤੇ ਚੋਣ ਅਦਿੱਖ ਹੁੰਦੀ ਹੈ; ਪ੍ਰਬੰਧਨ ਪਤਾ, ਜਨਤਕ ਪਤਾ ਅਤੇ ਉਸੇ ਨੈੱਟਵਰਕ ਕਾਰਡ 'ਤੇ ਦੂਜਾ ਪਤਾ ਵਾਲੇ ਹੋਸਟ 'ਤੇ ਇਹ ਰੂਟ ਮੈਟ੍ਰਿਕ ਅਤੇ ਨੀਤੀ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ। ਨੀਤੀ-ਆਧਾਰਿਤ ਰੂਟਿੰਗ ਬੇਮੇਲ ਨੂੰ ਘਟਾਉਣ ਦੀ ਥਾਂ ਵਧਾਉਂਦੀ ਹੈ, ਕਿਉਂਕਿ ਨਿਯਮ ਅਜਿਹਾ ਅੱਪਲਿੰਕ ਚੁਣ ਸਕਦਾ ਹੈ ਜਿੱਥੇ ਕਲਾਇੰਟ ਕਦੇ ਨਹੀਂ ਪਹੁੰਚਿਆ। ਇੱਕ ਪ੍ਰਦਾਤਾ ਤੋਂ ਸਿੱਖਿਆ ਡਿਫਾਲਟ ਰੂਟ ਅਤੇ ਦੂਜੇ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲਾ ਸਰੋਤ ਨਿਯਮ ਇਸਨੂੰ ਪੈਦਾ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਹਨ।
ਜੋ ਕਲਾਇੰਟ ਜਵਾਬ ਫਿਲਟਰ ਕਰਦੇ ਹਨ, ਅਤੇ ਜੋ ਕਨੈਕਸ਼ਨ ਟ੍ਰੈਕਿੰਗ ਸਹੀ ਚੌਕੜੀ ਅਤੇ ਸਰੋਤ ਦੀ ਉਮੀਦ ਕਰਦੀ ਹੈ, ਉਹ ਲਾਭਦਾਇਕ ਸੁਨੇਹੇ ਬਿਨਾਂ ਜਵਾਬ ਸੁੱਟ ਦੇਣਗੇ। ਫਿਰ ਟਨਲ ਇੰਝ ਸਮਾਂ ਖਤਮ ਕਰਦਾ ਹੈ ਜਿਵੇਂ ਕੁਝ ਆਇਆ ਹੀ ਨਾ ਹੋਵੇ, ਅਤੇ ਇਸੇ ਲਈ ਇਸਨੂੰ ਕਲਾਇੰਟ ਪਾਸੇ ਦੀ ਫਾਇਰਵਾਲ ਸਮੱਸਿਆ ਸਮਝ ਲਿਆ ਜਾਂਦਾ ਹੈ। ਸਿਰਫ਼ ਸਰਵਰ 'ਤੇ ਲਿਆ ਕੈਪਚਰ ਗਲਤੀ ਨੂੰ ਸਮਝਾਉਣ ਦੀ ਥਾਂ ਉਸਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ, ਕਿਉਂਕਿ ਜਵਾਬ ਸੱਚਮੁੱਚ ਨਿਕਲਦਾ ਹੈ। ਹੋਰ ਕੁਝ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਜਵਾਬ ਦੇ ਸਰੋਤ ਦੀ ਤੁਲਨਾ ਉਸ ਪਤੇ ਨਾਲ ਕਰੋ ਜਿਸ 'ਤੇ ਕਲਾਇੰਟ ਨੇ ਡਾਇਲ ਕੀਤਾ।
multihome ਚੋਣ ਅਸਲ ਵਿੱਚ ਕੀ ਕਰਦੀ ਹੈ
ਇਹ ਹਦਾਇਤ ਕਨਫਿਗਰੇਸ਼ਨ ਫਾਈਲ ਵਿੱਚ multihome ਵਜੋਂ ਅਤੇ ਕਮਾਂਡ ਲਾਈਨ 'ਤੇ --multihome ਵਜੋਂ ਲਿਖੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਇਹ UDP ਸਰਵਰ ਨੂੰ ਉਸ ਪਤੇ ਤੋਂ ਜਵਾਬ ਦੇਣ ਲਈ ਮਜਬੂਰ ਕਰਦੀ ਹੈ ਜਿੱਥੇ ਕਲਾਇੰਟ ਦਾ ਪੈਕਟ ਪਹੁੰਚਿਆ। ਕਰਨਲ ਪ੍ਰਾਪਤੀ ਵੇਲੇ ਮੂਲ ਮੰਜ਼ਿਲ ਪਤਾ ਵਾਧੂ ਡੇਟਾ ਵਜੋਂ ਦਿੰਦਾ ਹੈ, ਅਤੇ OpenVPN ਉਸ ਮੁੱਲ ਨੂੰ ਜਵਾਬ ਦੇ ਸਰੋਤ ਵਜੋਂ ਵਰਤਦਾ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ ਵਾਈਲਡਕਾਰਡ ਪਤੇ 'ਤੇ ਸੁਣਦਾ ਸਰਵਰ, IPv4 ਲਈ local 0.0.0.0 ਜਾਂ ਉਸਦਾ IPv6 ਬਰਾਬਰ, ਇੰਝ ਵਿਵਹਾਰ ਕਰਦਾ ਹੈ ਜਿਵੇਂ ਹਰ ਕਲਾਇੰਟ ਕਿਸੇ ਸਮਰਪਿਤ ਸਰੋਤਾ ਤੱਕ ਪਹੁੰਚਿਆ ਹੋਵੇ। ਜਨਤਕ ਪਤੇ ਰਾਹੀਂ ਆਏ ਕਲਾਇੰਟ ਜਨਤਕ ਪਤੇ ਤੋਂ ਜਵਾਬ ਪਾਉਂਦੇ ਹਨ, ਅਤੇ ਅੰਦਰੂਨੀ ਪਤੇ ਵਾਲੇ ਕਲਾਇੰਟ ਉਸੇ ਪਤੇ ਤੋਂ ਪਾਉਂਦੇ ਹਨ। ਪੈਕਟ ਦੇ ਰਾਹ ਵਿੱਚ ਹੋਰ ਕੁਝ ਨਹੀਂ ਹਿਲਦਾ: ਰੂਟ, ਫਿਲਟਰ ਨਿਯਮ ਅਤੇ ਟਨਲ ਕਨਫਿਗਰੇਸ਼ਨ ਜਿਵੇਂ ਸਨ ਤਿਵੇਂ ਹੀ ਰਹਿੰਦੇ ਹਨ।
ਇਹੀ ਆਖਰੀ ਗੁਣ ਇਸ ਚੋਣ ਨੂੰ ਹੋਰ ਤਰੀਕੇ ਨਾਲ ਚੱਲਦੇ ਸਰਵਰ ਵਿੱਚ ਜੋੜਨ ਲਈ ਸੁਰੱਖਿਅਤ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ ਇਹੀ ਕਾਰਨ ਹੈ ਕਿ ਇਹ ਸਿਰਫ਼ ਇੱਕ ਪਤੇ ਦੀ ਆਗਿਆ ਦੇਣ ਵਾਲੇ ਫਿਲਟਰ ਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰ ਸਕਦੀ। ਪੈਕਟ ਨੂੰ ਅਜੇ ਵੀ ਉਸੇ ਰਾਹ 'ਤੇ ਸਵੀਕਾਰ ਹੋਣਾ ਪੈਂਦਾ ਹੈ ਜਿਸ 'ਤੇ ਇਹ ਜਾਂਦਾ ਹੈ, ਇਸ ਲਈ ਸਰੋਤ ਸੁਧਾਰ ਜਵਾਬ ਦੀ ਸ਼ੁਰੂਆਤ ਹੀ ਬਦਲਦਾ ਹੈ, ਹੋਰ ਕੁਝ ਨਹੀਂ। ਇਹ ਸਿਰਫ਼ UDP ਲਈ ਵੀ ਹੈ: TCP ਸਰੋਤਾ ਨੂੰ ਇਹ ਸਮੱਸਿਆ ਉਸੇ ਰੂਪ ਵਿੱਚ ਨਹੀਂ ਹੁੰਦੀ, ਕਿਉਂਕਿ ਕਨੈਕਸ਼ਨ ਜਵਾਬ ਦੇ ਸਰੋਤ ਪਤੇ ਨਾਲ ਨਹੀਂ, ਚੌਕੜੀ ਨਾਲ ਪਛਾਣਿਆ ਜਾਂਦਾ ਹੈ।
ਕਦੋਂ ਸਥਿਰ ਸਥਾਨਕ ਪਤਾ ਗਲਤ ਡਿਫਾਲਟ ਹੁੰਦਾ ਹੈ
ਚੋਣ ਵੱਲ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਜਾਂਚੋ ਕਿ ਸਰਵਰ ਇੱਕ ਖਾਸ ਸਥਾਨਕ ਪਤਾ ਬੰਨ੍ਹਦਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਕਿਉਂਕਿ ਬੱਝਾ ਸਰੋਤਾ ਹਮੇਸ਼ਾ ਉਸੇ ਪਤੇ ਤੋਂ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਇਹ ਇੱਕ ਇੰਟਰਫੇਸ ਵਾਲੀ ਤੈਨਾਤੀ ਲਈ ਸਹੀ ਹੈ ਅਤੇ ਜਿਵੇਂ ਹੀ ਕਲਾਇੰਟ ਕਾਨੂੰਨੀ ਤੌਰ 'ਤੇ ਇੱਕ ਤੋਂ ਵੱਧ ਪਤਾ ਵਰਤਦੇ ਹਨ, ਗਲਤ ਹੋ ਜਾਂਦਾ ਹੈ। ਜੇ ਬੰਧਨ ਜਾਣਬੁੱਝ ਕੇ ਸੀ, ਤਾਂ ਫੈਸਲਾ ਕਰੋ ਕਿ ਸਰਵਰ ਨੂੰ ਵਾਧੂ ਪਤਿਆਂ 'ਤੇ ਟ੍ਰੈਫਿਕ ਸਵੀਕਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਬੰਧਨ ਹਟਾਉਣ ਨਾਲ ਐਕਸਪੋਜ਼ਰ ਵਧਦਾ ਹੈ, ਇਸ ਲਈ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਇੰਟਰਫੇਸ ਅਤੇ ਸਰੋਤ ਨੈੱਟਵਰਕ ਸੇਵਾ ਅਤੇ ਫਿਲਟਰ ਨੂੰ ਲਾਗੂ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ, ਸਿਰਫ਼ ਬੰਧਨ ਪਤਾ ਨਹੀਂ।
OpenVPN ਸੰਦਰਭ ਇਸ ਚੋਣ ਨੂੰ UDP ਸਰਵਰਾਂ ਤੱਕ ਸੀਮਤ ਰੱਖਦਾ ਹੈ, ਪੈਕਟ ਦੇ ਰਾਹ ਵਿੱਚ ਵਾਧੂ ਪ੍ਰੋਸੈਸਿੰਗ ਦਾ ਜ਼ਿਕਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਦਰਜ ਕਰਦਾ ਹੈ ਕਿ ਕਿਹੜੇ ਪਲੇਟਫਾਰਮ ਇਸਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ। ਇਸਦੇ ਆਧਾਰ 'ਤੇ ਯੋਜਨਾ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਸਥਾਪਿਤ ਸੰਸਕਰਣ 'ਤੇ ਇਸਦੀ ਪੁਸ਼ਟੀ ਕਰੋ। ਜਿੱਥੇ ਸਮਰਥਨ ਨਹੀਂ ਹੈ, ਉੱਥੇ ਖਾਸ ਪਤਾ ਬੰਨ੍ਹਣਾ ਜਾਂ ਵਾਪਸੀ ਰੂਟ ਠੀਕ ਕਰਨਾ ਬਦਲ ਹੈ, ਅਤੇ ਦੋਵੇਂ ਪਹਿਲੀ ਨਜ਼ਰ ਵਿੱਚ ਦਿਸਣ ਨਾਲੋਂ ਤੰਗ ਬਦਲਾਅ ਹਨ। ਵਾਈਲਡਕਾਰਡ 'ਤੇ ਸੁਣਨ ਦੇ ਜਵਾਬਾਂ ਤੋਂ ਅੱਗੇ ਵੀ ਨਤੀਜੇ ਹਨ: ਸਾਰੇ ਪਤਿਆਂ 'ਤੇ ਸਰਵਰ ਹੋਸਟ ਨਾਲ ਜੁੜੇ ਹਰ ਨੈੱਟਵਰਕ ਤੋਂ ਪਹੁੰਚਯੋਗ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਇਹ ਸ਼ਾਇਦ ਉਹ ਐਕਸਪੋਜ਼ਰ ਨਾ ਹੋਵੇ ਜੋ ਕਿਸੇ ਦਾ ਇਰਾਦਾ ਸੀ।
ਜਵਾਬ ਦੇ ਸਰੋਤ ਨੂੰ ਬਾਹਰੋਂ ਸਾਬਤ ਕਰੋ
ਸਰਵਰ ਤੋਂ ਬਾਹਰੋਂ ਟੈਸਟ ਕਰੋ, ਅਤੇ ਕੁਝ ਵੀ ਕੈਪਚਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਸਹੀ ਪਤਾ ਅਤੇ ਆਵਾਜਾਈ ਦਰਜ ਕਰੋ ਜੋ ਕਲਾਇੰਟ ਨੇ ਵਰਤੀ। ਹੇਠਾਂ ਤਿੰਨ ਜਾਂਚਾਂ ਤਿੰਨ ਵੱਖਰੇ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦੀਆਂ ਹਨ, ਅਤੇ ਕ੍ਰਮ ਮਹੱਤਵਪੂਰਨ ਹੈ।
tcpdump -ni any udp port 1194
ss -lunp 'sport = :1194'
ip route get 203.0.113.10 from 198.51.100.20
ਕੈਪਚਰ ਜਵਾਬ 'ਤੇ ਸਰੋਤ ਪਤਾ ਦਿਖਾਉਂਦਾ ਹੈ, ਅਤੇ ਪੂਰਾ ਲੇਖ ਇਸ ਤੱਥ 'ਤੇ ਟਿਕਿਆ ਹੈ। ਸਾਕਟ ਸੂਚੀ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਸਰਵਰ ਨੇ ਅਸਲ ਵਿੱਚ ਕੀ ਬੰਨ੍ਹਿਆ, ਕਿਉਂਕਿ ਵਾਈਲਡਕਾਰਡ ਸਰੋਤਾ ਅਤੇ ਖਾਸ ਸਰੋਤਾ ਕਨਫਿਗਰੇਸ਼ਨ ਫਾਈਲ ਵਿੱਚ ਇੱਕੋ ਜਿਹੇ ਦਿਸਦੇ ਹਨ ਅਤੇ ਨੈੱਟਵਰਕ 'ਤੇ ਵੱਖਰਾ ਵਿਵਹਾਰ ਕਰਦੇ ਹਨ। ਰੂਟ ਖੋਜ ਉਹ ਸਰੋਤ ਦਿਖਾਉਂਦੀ ਹੈ ਜੋ ਕਰਨਲ ਉਸ ਪ੍ਰਵਾਹ ਲਈ ਚੁਣਦਾ, ਅਤੇ ਇਹ ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਕੈਪਚਰ ਦੀ ਵਿਆਖਿਆ ਕਰਦੀ ਹੈ। ਤਿੰਨੇ IPv4 ਅਤੇ IPv6 ਲਈ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਦੁਹਰਾਓ, ਕਿਉਂਕਿ ਇਹ ਵੱਖਰੇ ਸਰੋਤੇ ਅਤੇ ਵੱਖਰੀਆਂ ਖੋਜਾਂ ਹਨ, ਅਤੇ ਇੱਕ ਪਰਿਵਾਰ ਲਈ ਵਾਈਲਡਕਾਰਡ ਐਂਟਰੀ ਦੂਜੇ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦੀ।
ਰੂਟਿੰਗ, ਖੋਜ ਅਤੇ ਫਿਲਟਰਿੰਗ ਵੱਖਰੇ ਰਹਿੰਦੇ ਹਨ
ਜਵਾਬ ਦੇ ਸਰੋਤ ਨੂੰ ਬਚਾਉਣਾ ਬਾਹਰ ਜਾਣ ਵਾਲਾ ਰੂਟ ਸਥਾਪਿਤ ਨਹੀਂ ਕਰਦਾ, ਗਤੀਸ਼ੀਲ DNS ਨੂੰ ਅੱਪਡੇਟ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਇੱਕ ਪਤਾ ਪਰਿਵਾਰ ਨੂੰ ਦੂਜੇ ਨੂੰ ਸਵੀਕਾਰਨ ਲਈ ਮਜਬੂਰ ਨਹੀਂ ਕਰਦਾ। ਕਈ ਅੱਪਲਿੰਕ ਵਾਲੇ ਸਰਵਰ 'ਤੇ ਹਰ ਸਰੋਤ ਲਈ ਵਾਪਸੀ ਰਾਹ ਜਾਣਬੁੱਝ ਕੇ ਤੈਅ ਕਰਨਾ ਪੈਂਦਾ ਹੈ, ਨਹੀਂ ਤਾਂ ਜਵਾਬ ਉਸ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਨਿਕਲਦੇ ਹਨ ਜਿਸਨੂੰ ਕਲਾਇੰਟ ਦੇ ਫਿਲਟਰ ਨੇ ਕਦੇ ਮਨਜ਼ੂਰ ਨਹੀਂ ਕੀਤਾ। ਇਸੇ ਤਰ੍ਹਾਂ, ਪ੍ਰੀਫਿਕਸ ਬਦਲਣ ਤੋਂ ਬਾਅਦ ਨਵਾਂ ਪਤਾ ਕਲਾਇੰਟਾਂ ਤੱਕ ਪਹੁੰਚਣਾ ਚਾਹੀਦਾ ਹੈ ਖੋਜ ਅਤੇ ਸਮਰਥਿਤ ਮੁੜ-ਕਨੈਕਟ ਪ੍ਰਵਾਹ ਰਾਹੀਂ, ਪੁਰਾਣੀ ਰਿਕਾਰਡ ਰਾਹੀਂ ਨਹੀਂ।
ਸਰਵਰ ਪਛਾਣ ਜਾਂਚਾਂ ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਪੁਸ਼ਟੀ ਨੂੰ ਜਿਵੇਂ ਹਨ ਤਿਵੇਂ ਹੀ ਰਹਿਣ ਦਿਓ, ਕਿਉਂਕਿ ਬਦਲਿਆ ਪਤਾ ਬਿਨਾਂ ਪੁਸ਼ਟੀ ਵਾਲੇ ਸਾਥੀ ਨੂੰ ਸਵੀਕਾਰਨ ਦਾ ਜਾਇਜ਼ ਨਹੀਂ ਬਣਦਾ। ਜੇ ਜਵਾਬ ਹੁਣ ਇੱਛਤ ਸਰੋਤ ਤੋਂ ਨਿਕਲਦਾ ਹੈ ਅਤੇ ਟਨਲ ਫਿਰ ਵੀ ਫੇਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਸਰੋਤ ਦੀ ਸਮੱਸਿਆ ਹੱਲ ਹੋਈ ਮੰਨੋ ਅਤੇ ਅੱਗੇ ਵਧੋ। ਅੱਗੇ ਦਿਸਣ ਵਾਲੀ ਗਲਤੀ ਰੂਟਿੰਗ, ਫਿਲਟਰਿੰਗ ਜਾਂ ਪ੍ਰਮਾਣਿਕਤਾ ਦੀ ਹੈ, ਅਤੇ ਸਰੋਤਾ ਦੁਬਾਰਾ ਬਦਲਣ ਨਾਲ ਉੱਥੇ ਨਹੀਂ ਪਹੁੰਚਾਂਗੇ। ਕਲਾਇੰਟ ਦੁਆਰਾ ਡਾਇਲ ਕੀਤੇ ਪਤੇ ਦੇ ਕੋਲ ਟਿਕਟ ਵਿੱਚ ਜਵਾਬ ਦਾ ਸਰੋਤ ਲਿਖੋ, ਤਾਂ ਜੋ ਅਗਲਾ ਵਿਅਕਤੀ ਉਹੀ ਤੱਥ ਇੱਕ ਹੀ ਹੁਕਮ ਨਾਲ ਜਾਂਚ ਸਕੇ।