ਅਗਲੀ ਮੁੜ-ਕਨੈਕਟ ਵਿੱਚ ਪੂਲ ਕਿਹੜਾ ਪਤਾ ਦੇਵੇਗਾ?
ਪੂਲ ਦੇ ਪਤੇ ਇੱਕ ਅਜਿਹਾ ਕ੍ਰਮ ਅਪਣਾਉਂਦੇ ਹਨ ਜੋ ਬੇਤਰਤੀਬ ਨਹੀਂ: ਪਹਿਲਾਂ ਯਾਦ ਰੱਖਿਆ ਪਤਾ, ਫਿਰ ਸਭ ਤੋਂ ਲੰਮਾ ਸਮਾਂ ਨਾ ਵਰਤਿਆ ਖ਼ਾਲੀ ਪਤਾ। ਨਿਯਮ ਤੈਅ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਪੜ੍ਹੋ।
ਜੋ ਨਿਯਮ ਕੱਲ੍ਹ ਮੇਲ ਖਾਂਦਾ ਸੀ ਅੱਜ ਨਹੀਂ ਖਾਂਦਾ, ਕਿਉਂਕਿ ਕਲਾਇੰਟ ਕਿਸੇ ਹੋਰ ਟਨਲ ਪਤੇ ’ਤੇ ਵਾਪਸ ਆਇਆ। ਪਰ ਵੰਡਣ ਵਾਲਾ ਬੇਤਰਤੀਬ ਨਹੀਂ ਹੈ, ਅਤੇ ਉਸ ਦਾ ਕ੍ਰਮ ਜਾਣਨਾ ਉਸ ਹੈਰਾਨੀ ਨੂੰ ਪਹਿਲਾਂ ਤੋਂ ਜਾਣਨ ਯੋਗ ਘਟਨਾ ਬਣਾ ਦਿੰਦਾ ਹੈ। ਉਹ ਉਸੇ ਕਲਾਇੰਟ ਦਾ ਪਹਿਲਾਂ ਵਾਲਾ ਪਤਾ ਤਰਜੀਹ ਦਿੰਦਾ ਹੈ, ਸਭ ਤੋਂ ਲੰਮਾ ਸਮਾਂ ਨਿਸ਼ਕਿਰਿਆ ਖ਼ਾਲੀ ਪਤੇ ’ਤੇ ਵਾਪਸ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਜੇ ਤੁਸੀਂ ਉਸ ਨੂੰ ਯਾਦ ਰੱਖਣ ਦੀ ਥਾਂ ਨਾ ਦਿਓ ਤਾਂ ਸਭ ਭੁੱਲ ਜਾਂਦਾ ਹੈ। ਕਿਰਾਏ ’ਤੇ ਆਧਾਰਿਤ ਨਿਯਮ ਉਸ ਦਿਨ ਤੱਕ ਮੇਲ ਖਾਂਦੇ ਰਹਿੰਦੇ ਹਨ ਜਦੋਂ ਉਹ ਚੁੱਪਚਾਪ ਇਹ ਕਰਨਾ ਛੱਡ ਦਿੰਦੇ ਹਨ।
ਉਹ ਕ੍ਰਮ ਜਿਸ ਦੀ ਵੰਡਣ ਵਾਲਾ ਪਾਲਣਾ ਕਰਦਾ ਹੈ
ਪ੍ਰਤੀ common name ਇੱਕ ਸੈਸ਼ਨ ਹੋਣ ’ਤੇ ਵੰਡਣ ਵਾਲਾ ਪਹਿਲਾਂ ਉਹ ਪਤਾ ਲੱਭਦਾ ਹੈ ਜੋ ਉਸੇ ਕਲਾਇੰਟ ਨੇ ਪਹਿਲਾਂ ਵਰਤਿਆ ਸੀ ਅਤੇ ਜੋ ਹੁਣ ਖ਼ਾਲੀ ਹੈ। ਜੇ ਉਹ ਪਤਾ ਨਹੀਂ ਹੈ ਤਾਂ ਉਹ ਸਭ ਤੋਂ ਲੰਮਾ ਸਮਾਂ ਨਿਸ਼ਕਿਰਿਆ ਰਿਹਾ ਖ਼ਾਲੀ ਪਤਾ ਲੈਂਦਾ ਹੈ। ਜਦੋਂ ਉਸੇ ਨਾਮ ਲਈ ਇੱਕੋ ਸਮੇਂ ਸੈਸ਼ਨ ਚਾਲੂ ਹੋਣ, ਪਿਛਲੇ ਪਤੇ ਦੀ ਤਰਜੀਹ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦੀ ਅਤੇ ਉਸ ਦੀ ਥਾਂ ਪਹਿਲਾ ਖ਼ਾਲੀ ਪਤਾ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਕਿਉਂਕਿ ਸੈਸ਼ਨਾਂ ਨੂੰ ਵੱਖਰੇ ਬਰਾਬਰ ਨੋਡ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ।
| Situation | Address chosen | Practical effect |
|---|---|---|
| Reconnect, old address still free | The remembered address | Rules appear stable for days |
| Old address taken by another client | Least recently used free address | A working rule silently stops matching |
| Concurrent sessions, same name | First free address, per session | One identity can hold several leases |
ਇਸ ਤੋਂ ਤੁਰੰਤ ਦੋ ਨਤੀਜੇ ਨਿਕਲਦੇ ਹਨ। ਤੇਜ਼ੀ ਨਾਲ ਮੁੜ ਜੁੜਨ ਵਾਲਾ ਕਲਾਇੰਟ ਆਮ ਤੌਰ ’ਤੇ ਆਪਣਾ ਪਤਾ ਬਣਾਈ ਰੱਖਦਾ ਹੈ, ਇਸੇ ਲਈ ਕੋਈ ਵੀ ਤੰਤਰ ਨੂੰ ਬਦਲਣ ਤੱਕ ਨਹੀਂ ਦੇਖਦਾ। ਅਤੇ ਉਸ ਛੋਟੀ ਖਿੜਕੀ ਵਿੱਚ ਜੁੜਨ ਵਾਲਾ ਦੂਜਾ ਯੰਤਰ ਪਤਾ ਉਦੋਂ ਲੈ ਸਕਦਾ ਹੈ ਜਦੋਂ ਉਹ ਥੋੜ੍ਹਾ ਸਮਾਂ ਖ਼ਾਲੀ ਹੋਵੇ, ਜਿਸ ਤੋਂ ਬਾਅਦ ਪਹਿਲੇ ਕਲਾਇੰਟ ਨੂੰ ਕੁਝ ਹੋਰ ਮਿਲਦਾ ਹੈ ਅਤੇ ਪੁਰਾਣੇ ਨੰਬਰ ’ਤੇ ਆਧਾਰਿਤ ਹਰ ਨਿਯਮ ਗ਼ਲਤ ਹੋ ਜਾਂਦਾ ਹੈ। ਦੋਵਾਂ ਘਟਨਾਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਖ਼ਰਾਬੀ ਵਰਗੀ ਲੌਗ ਲਾਈਨ ਨਹੀਂ ਬਣਾਉਂਦੀ।
ਕਿਰਾਇਆ ਸਥਿਰ ਕਿਉਂ ਦਿਸਦਾ ਹੈ ਅਤੇ ਫਿਰ ਖਿਸਕਦਾ ਹੈ
ਇੱਥੇ ਸਥਿਰਤਾ ਮੁੜ-ਕਨੈਕਟਾਂ ਦੀ ਉਭਰਦੀ ਖ਼ਾਸੀਅਤ ਹੈ ਜੋ ਕਿਸੇ ਹੋਰ ਵੱਲੋਂ ਪਤਾ ਮੰਗਣ ਤੋਂ ਪਹਿਲਾਂ ਆਉਂਦੇ ਹਨ। ਇਹ ਵਾਅਦਾ ਨਹੀਂ, ਅਤੇ ਜਦੋਂ ਤੱਕ ਕਲਾਇੰਟ ਡਿਸਕਨੈਕਟ ਹੈ ਇਹ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦਾ। ਪਤਾ ਬਦਲਣ ਦੀ ਯੋਜਨਾ ਬਣਾਓ, ਇਸ ਤੋਂ ਹੈਰਾਨ ਹੋਣ ਦੀ ਥਾਂ। ਯੰਤਰਾਂ ਦੀ ਗਿਣਤੀ ਤੋਂ ਬਹੁਤੀ ਵੱਡੀ ਨਾ ਹੋਣ ਵਾਲੀ ਪੂਲ ਟਕਰਾਵਾਂ ਨੂੰ ਆਮ ਬਣਾ ਦਿੰਦੀ ਹੈ, ਕਿਉਂਕਿ ਸਭ ਤੋਂ ਲੰਮਾ ਸਮਾਂ ਨਾ ਵਰਤੇ ਪਤੇ ’ਤੇ ਵਾਪਸ ਜਾਣ ਕੋਲ ਚੁਣਨ ਨੂੰ ਲਗਭਗ ਕੁਝ ਨਹੀਂ ਹੁੰਦਾ।
ਸਿਖਰ ਦੀ ਇੱਕੋ-ਸਮਤਾ ਉਹ ਗਿਣਤੀ ਹੈ ਜਿਸ ’ਤੇ ਮਾਪ ਤੈਅ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਵਰਤੋਂਕਾਰਾਂ ਦੀ ਗਿਣਤੀ ਨਹੀਂ। ਕੋਈ ਜੋ ਇੱਕੋ ਸਮੇਂ ਦੋ ਯੰਤਰਾਂ ਤੋਂ ਜਾਂਚ ਕਰਦਾ ਹੈ, ਜਾਂ ਕਲਾਇੰਟ ਜੋ ਪੁਰਾਣੇ ਸੈਸ਼ਨ ਦੇ ਖ਼ਤਮ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਮੁੜ ਜੁੜਦਾ ਹੈ, ਕੁਝ ਸਮੇਂ ਲਈ ਦੋ ਕਿਰਾਏ ਰੱਖਦਾ ਹੈ। ਸਿਰਫ਼ ਵਿਅਕਤੀਆਂ ਦੀ ਗਿਣਤੀ ’ਤੇ ਆਧਾਰਿਤ ਪੂਲ ਉਹੀ ਅਦਲਾ-ਬਦਲੀ ਪੈਦਾ ਕਰੇਗੀ ਜਿਸ ਦਾ ਦੋਸ਼ ਲੋਕ ਸਰਵਰ ’ਤੇ ਪਾਉਂਦੇ ਹਨ।
ਸਥਿਰਤਾ ਫਾਈਲ ਯਾਦ ਰੱਖਦੀ ਹੈ, ਰਾਖਵਾਂ ਨਹੀਂ ਕਰਦੀ
ਜੋ ਪਤਾ ਸੇਵਾ ਦੇ ਮੁੜ-ਸ਼ੁਰੂ ਤੋਂ ਬਚਦਾ ਹੈ, ਉਸ ਨੂੰ ਸਥਿਰਤਾ ਫਾਈਲ ਚਾਹੀਦੀ ਹੈ। ਇਹ ਬੰਦ ਕਰਨ ਵੇਲੇ ਕਲਾਇੰਟ ਦਾ ਨਾਮ ਤੇ ਪਤਾ ਸੰਭਾਲਦੀ ਹੈ ਅਤੇ ਸੇਵਾ ਸ਼ੁਰੂ ਹੋਣ ’ਤੇ ਉਹ ਮੁੜ ਪੜ੍ਹਦੀ ਹੈ, ਇਸੇ ਲਈ ਯੋਜਨਾਬੱਧ ਮੁੜ-ਸ਼ੁਰੂ ਹੁਣ ਤੁਹਾਡੇ ਲਿਖੇ ਸਾਰੇ ਨਿਯਮ ਨਹੀਂ ਵਿਗਾੜਦਾ।
ifconfig-pool-persist /etc/openvpn/ipp.txt
server 10.8.0.0 255.255.255.0ਇਹ ਜੋ ਨਹੀਂ ਕਰਦੀ ਉਹ ਹੈ ਕਲਾਇੰਟ ਦੀ ਗੈਰ-ਹਾਜ਼ਰੀ ਵਿੱਚ ਪਤਾ ਰੋਕ ਕੇ ਰੱਖਣਾ। ਉਸ ਅੰਤਰਾਲ ਵਿੱਚ ਵੰਡਣ ਵਾਲਾ ਨੰਬਰ ਕਿਸੇ ਹੋਰ ਨੂੰ ਦੇਣ ਲਈ ਆਜ਼ਾਦ ਹੈ, ਅਤੇ ਫਾਈਲ ਫਿਰ ਅਜਿਹੀ ਪੁਰਾਣੀ ਤਰਜੀਹ ਦਰਜ ਕਰਦੀ ਹੈ ਜਿਸ ਨੂੰ ਅਗਲਾ ਕਨੈਕਸ਼ਨ ਪੂਰਾ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਇਸ ਨੂੰ ਮੁੜ-ਸ਼ੁਰੂ ਦੇ ਵਿਵਹਾਰ ਨੂੰ ਸੁਧਾਰਨ ਵਾਲੇ ਸੰਕੇਤ ਵਜੋਂ ਲਓ, ਸਥਿਰ ਪਤਾ-ਪ੍ਰਬੰਧ ਵਜੋਂ ਨਹੀਂ।
ਜਦੋਂ ਤੁਸੀਂ ਫਾਈਲ ਵਿੱਚ ਹੋ ਤਾਂ ਪੂਲ ਨੂੰ ਹਰ ਰੂਟ ਕੀਤੇ ਸਬਨੈੱਟ ਦੇ ਮੁਕਾਬਲੇ ਜਾਂਚੋ। ਇੱਕ-ਦੂਜੇ ’ਤੇ ਚੜ੍ਹਦੀ ਰੇਂਜ ਅਜਿਹੇ ਪਤੇ ਵੰਡਦੀ ਹੈ ਜਿਨ੍ਹਾਂ ਤੱਕ ਸਰਵਰ ਰੂਟ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਅਤੇ ਲੱਛਣ ਇਹ ਹੈ ਕਿ ਕਲਾਇੰਟ ਜੁੜਦਾ ਹੈ, ਪਤਾ ਲੈਂਦਾ ਹੈ ਅਤੇ ਕਿਤੇ ਨਹੀਂ ਪਹੁੰਚਦਾ।
ਪਤੇ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਸਥਿਰ ਕਰਨਾ
ਜਦੋਂ ਫਾਇਰਵਾਲ ਨਿਯਮ ਜਾਂ DNS ਰਿਕਾਰਡ ਨੂੰ ਸੱਚਮੁੱਚ ਸਥਿਰ ਪਤਾ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਉਮੀਦ ਕਰਨ ਦੀ ਥਾਂ ਉਹ ਅਲਾਟ ਕਰੋ। ਪ੍ਰਤੀ ਕਲਾਇੰਟ ਕਨਫ਼ਿਗਰੇਸ਼ਨ ਐਂਟਰੀ ਸਿੱਧਾ ਪਤਾ ਅਤੇ ਮਾਸਕ ਭੇਜ ਸਕਦੀ ਹੈ, ਅਤੇ ਉਹ ਐਂਟਰੀ ਅਸਰਦਾਰ ਕਲਾਇੰਟ ਨਾਮ ’ਤੇ ਕੁੰਜੀਬੱਧ ਹੈ।
# client-config-dir entry for "laptop-acme"
ifconfig-push 10.8.0.50 255.255.255.0ਸਥਿਰ ਪਤੇ ਗਤੀਸ਼ੀਲ ਪੂਲ ਤੋਂ ਬਾਹਰ ਰੱਖੋ ਤਾਂ ਜੋ ਵੰਡਣ ਵਾਲਾ ਕਦੇ ਵੀ ਉਹੀ ਨੰਬਰ ਕਿਸੇ ਹੋਰ ਸੈਸ਼ਨ ਨੂੰ ਨਾ ਦੇਵੇ। ਫਿਰ ਟਨਲ ਦੀ ਬਣਾਵਟ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਇਹ ਬਦਲਦੀ ਹੈ ਕਿ ਹਰ ਕਲਾਇੰਟ ਕਿੰਨੇ ਪੂਲ ਪਤੇ ਖ਼ਰਚ ਕਰਦਾ ਹੈ: ਪੁਰਾਣਾ ਬਿੰਦੂ-ਤੋਂ-ਬਿੰਦੂ ਖਾਕਾ ਪ੍ਰਤੀ ਕਲਾਇੰਟ ਇੱਕ ਛੋਟਾ ਬਲਾਕ ਖ਼ਰਚ ਕਰਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਸਬਨੈੱਟ ਖਾਕਾ ਹਰ ਇੱਕ ’ਤੇ ਇੱਕ ਪਤਾ ਵਰਤਦਾ ਹੈ। ਜੋ ਪੂਲ ਇੱਕ ਬਣਾਵਟ ਵਿੱਚ ਖੁੱਲ੍ਹਾ ਦਿਸਦਾ ਹੈ ਉਹ ਦੂਜੀ ਵਿੱਚ ਖ਼ਤਮ ਹੋ ਸਕਦਾ ਹੈ।
ਨਤੀਜਾ ਕਲਾਇੰਟ ’ਤੇ ਪੁਸ਼ਟੀ ਕਰੋ, ਸਰਵਰ ਦੇ ਹਿਸਾਬ ’ਤੇ ਭਰੋਸਾ ਕਰਨ ਦੀ ਥਾਂ। ਜਦੋਂ ਸੈਸ਼ਨ ਵਾਪਸ ਆਵੇ ਤਾਂ ਇੰਟਰਫ਼ੇਸ ਦਾ ਪਤਾ ਅਤੇ ਭੇਜਿਆ ਰੂਟ ਵੇਖੋ, ਕਿਉਂਕਿ ਸਰਵਰ ਦਾ ਲੌਗ ਮੰਗਿਆ ਪਤਾ ਦੱਸ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਇੰਟਰਫ਼ੇਸ ਆਪ ਕੋਈ ਹੋਰ ਰੱਖਦਾ ਹੋਵੇ।
ਦੂਰ ਦਾ ਪਤਾ ਵੱਖਰਾ ਸਵਾਲ ਹੈ
ਕਲਾਇੰਟ ਦੀ remote ਲਾਈਨ ਵਿੱਚ ਪਤਾ ਕਿਸੇ ਵੀ ਟਨਲ ਦੇ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਪਹੁੰਚਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਉੱਥੇ ਪੂਲ ਦਾ ਪਤਾ ਰੱਖਣਾ, ਜਿਵੇਂ ਸਰਵਰ ਦਾ ਆਪਣਾ ਟਨਲ ਅੰਤਿਮ ਬਿੰਦੂ, ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਕਲਾਇੰਟ ਉਸ ਟਨਲ ਰਾਹੀਂ ਅੰਤਿਮ ਬਿੰਦੂ ਤੱਕ ਪਹੁੰਚਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ ਜੋ ਉਸ ਨੇ ਹਾਲੇ ਬਣਾਈ ਨਹੀਂ, ਅਤੇ ਨਤੀਜਾ ਛੋਟੇ ਰਾਹ ਦੀ ਥਾਂ ਲੂਪ ਜਾਂ ਚੁੱਪ ਉਡੀਕ ਹੁੰਦਾ ਹੈ।
ਉਹ ਜਨਤਕ ਅੰਤਿਮ ਬਿੰਦੂ ਵਰਤੋ ਜੋ ਆਪਰੇਟਰ ਨੇ ਦਿੱਤਾ, ਅਤੇ ਪੂਲ ਨੂੰ ਉਸੇ ਲਈ ਰੱਖੋ ਜਿਸ ਲਈ ਇਹ ਬਣਾਈ ਗਈ: ਟਨਲ ਦੇ ਅੰਦਰਲੇ ਪਤੇ। ਪੂਲ ਦੀ ਰੇਂਜ, ਸਥਿਰ ਅਲਾਟਮੈਂਟ ਅਤੇ ਸਥਿਰਤਾ ਮਾਰਗ ਇੱਕੋ ਥਾਂ ਲਿਖ ਲੈਣਾ ਅਗਲੇ ਵਿਅਕਤੀ ਨੂੰ ਹਰ ਕਿਰਾਏ ਨੂੰ ਮਨਮਾਨੀ ਸਮਝਣ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।