OpenVPN ਸਰਵਰ nopool ਨਾਲ: ਸਪਸ਼ਟ ਪੂਲ ਰੇਂਜ ਦਾ ਐਲਾਨ ਕਰੋ

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

ਇਹ ਚੱਲ ਰਹੀ ਸੇਵਾ ਵਿੱਚ ਤਬਦੀਲੀ ਹੈ, ਇਸ ਲਈ ਇਸਨੂੰ ਸੰਚਾਲਨ ਕੰਮ ਮੰਨੋ: ਪਹਿਲਾਂ ਸੂਚੀ, ਫਿਰ ਆਮ ਜੀਵਨ ਚੱਕਰ ਰਾਹੀਂ ਲਾਗੂ ਕਰਨਾ, ਨਵੇਂ ਕਲਾਇੰਟ ਨਾਲ ਤਸਦੀਕ ਅਤੇ ਤਿਆਰ ਵਾਪਸੀ।

ਉਸੇ ਸਬਨੈੱਟ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਹੈ

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

grep -nE '^(topology|server|ifconfig-pool|max-clients|client-config-dir)' /etc/openvpn/server/lab.conf
ip -4 addr show tun0

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

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

nopool ਸ਼ਾਮਲ ਕਰੋ ਅਤੇ ਰੇਂਜ ਦਾ ਐਲਾਨ ਕਰੋ

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

topology subnet
server 10.70.0.0 255.255.255.0 nopool
ifconfig-pool 10.70.0.50 10.70.0.120 255.255.255.0

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

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

ਸਥਿਰ ਨਿਯੁਕਤੀਆਂ ਗਤੀਸ਼ੀਲ ਰੇਂਜ ਤੋਂ ਬਾਹਰ ਰੱਖੋ

ਕਲਾਇੰਟ-ਵਿਸ਼ੇਸ਼ ifconfig-push ਪੂਲ ਵੰਡ ਤੋਂ ਵੱਖਰੀ ਵਿਧੀ ਹੈ ਅਤੇ ਇਸਨੂੰ ਸਰਗਰਮ ਟੋਪੋਲੋਜੀ ਅਨੁਕੂਲ ਪੈਰਾਮੀਟਰ ਵਰਤਣੇ ਚਾਹੀਦੇ ਹਨ। ਸਬਨੈੱਟ ਮੋਡ ਵਿੱਚ ਇਹ ਇੱਕ ਪਤਾ ਅਤੇ ਨੈੱਟਮਾਸਕ ਹੈ; ਪੁਰਾਣੀ ਉਦਾਹਰਨ ਵਿੱਚ ਦਿਸਣ ਕਰਕੇ net30 ਜੋੜੀ ਲੈ ਆਉਣਾ ਆਮ ਗਲਤੀ ਹੈ।

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

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

ਜੀਵਨ ਚੱਕਰ ਰਾਹੀਂ ਲਾਗੂ ਕਰੋ, ਫਿਰ ਤਸਦੀਕ ਕਰੋ

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

systemctl restart openvpn-server@lab
journalctl -u openvpn-server@lab -n 30 --no-pager
# on a fresh client
ip -4 addr show tun0

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

ਉਸ ਕਲਾਇੰਟ ਨੂੰ ਦੁਬਾਰਾ ਜੋੜੋ ਜਿਸ ਕੋਲ ਪੁਰਾਣੀ ਰੇਂਜ ਦਾ ਪਤਾ ਸੀ। ਉਸਨੂੰ ਨਵੀਂ ਰੇਂਜ ਤੋਂ ਪਤਾ ਮਿਲਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਪੁਰਾਣੇ ਪਤੇ ਨਾਲ ਜੁੜੀ ਕੋਈ ਵੀ ਸੈਸ਼ਨ-ਪੱਧਰੀ ਸਥਿਤੀ ਚਲੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ। ਜੇ ਉਹ ਪੁਰਾਣਾ ਪਤਾ ਰੱਖਦਾ ਹੈ ਤਾਂ ਕੁਝ ਹੋਰ ਉਸਨੂੰ ਦੇ ਰਿਹਾ ਹੈ ਅਤੇ ਪੂਲ ਉਹ ਮਾਲਕ ਨਹੀਂ ਜੋ ਤੁਸੀਂ ਸੋਚਦੇ ਹੋ।

ਰੇਂਜ ਤਬਦੀਲੀ ਵਾਪਸ ਰੋਲ ਕਰਨਾ

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

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

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