VPN ਰੀਲੇ SSH ਸਵੀਕਾਰ ਕਰਨਾ ਬੰਦ ਕਰਦਾ ਹੈ: ਫਾਈਲ ਡਿਸਕ੍ਰਿਪਟਰ ਸੀਮਾਵਾਂ

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

ਸੰਖਿਆ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਮਾਰਗ ਦੀ ਪੈੜ ਕੱਢੋ

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

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

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

ਰੀਲੇ ਨੇ ਜੋ ਸੀਮਾ ਵਿਰਾਸਤ ਵਿੱਚ ਲਈ ਉਹ ਪੜ੍ਹੋ

ਸਿਰਫ਼ ਇੱਕ ਸੀਮਾ ਮਹੱਤਵਪੂਰਨ ਹੈ ਅਤੇ ਉਹ ਚੱਲ ਰਹੀ ਪ੍ਰਕਿਰਿਆ ਦੀ ਹੈ, ਅਤੇ ਉਹ ਉਸੇ ਚੀਜ਼ ਨੇ ਤੈਅ ਕੀਤੀ ਜਿਸਨੇ ਉਹ ਪ੍ਰਕਿਰਿਆ ਸ਼ੁਰੂ ਕੀਤੀ। ਸ਼ੈਲ ਵਿੱਚ ulimit -n ਲਿਖਣਾ ਸ਼ੈਲ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ। ਸੇਵਾ ਪ੍ਰਬੰਧਕ ਨੂੰ ਪੁੱਛੋ ਕਿ ਉਸਨੇ ਕੀ ਲਾਗੂ ਕੀਤਾ, ਫਿਰ PID ਉੱਤੇ ਪੁਸ਼ਟੀ ਕਰੋ।

systemctl show -p MainPID -p LimitNOFILE vpn-relay.service
cat /proc/$(systemctl show -p MainPID --value vpn-relay.service)/limits

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

Drop-in ਸ਼ਬਦਕੋਸ਼ ਕ੍ਰਮ ਵਿੱਚ ਲੋਡ ਹੁੰਦੇ ਹਨ ਅਤੇ ਬਾਅਦ ਵਾਲੀਆਂ ਫਾਈਲਾਂ ਜਿੱਤਦੀਆਂ ਹਨ, ਇਸ ਲਈ systemctl cat vpn-relay.service ਇਸ ਦਾ ਅਧਿਕਾਰਕ ਦ੍ਰਿਸ਼ ਹੈ ਕਿ ਕੀ ਲਾਗੂ ਹੁੰਦਾ ਹੈ। ਪ੍ਰਬੰਧਕ ਕਦੇ ਨਾ ਪੜ੍ਹੀ ਫਾਈਲ ਸੋਧਣਾ ਵਧਾਈ ਗਈ ਸੰਖਿਆ ਦਾ ਕੋਈ ਅਸਰ ਨਾ ਹੋਣ ਦਾ ਸਭ ਤੋਂ ਆਮ ਕਾਰਨ ਹੈ।

ਸਥਿਰ ਸਮਕਾਲੀਨਤਾ ਨੂੰ ਰੱਖੀ ਹਾਲਤ ਤੋਂ ਵੱਖ ਕਰੋ

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

ਨਿਸ਼ਕਿਰਿਆ ਹਾਲਤ ਵਿੱਚ, ਆਪਣੀ ਆਮ ਸਿਖਰ ਉੱਤੇ ਅਤੇ ਭਾਰ ਰੁਕਣ ਤੋਂ ਕੁਝ ਮਿੰਟ ਬਾਅਦ ਫਿਰ ਮਿਣੋ। ls /proc/PID/fd | wc -l ਨਾਲ ਖੁੱਲ੍ਹੀਆਂ ਐਂਟਰੀਆਂ ਨੂੰ ਨਰਮ ਸੀਮਾ ਦੇ ਮੁਕਾਬਲੇ ਗਿਣਨ ਨਾਲ ਤੁਹਾਨੂੰ ਅੰਤਰ ਪਤਾ ਲੱਗਦਾ ਹੈ, ਅਤੇ ਸੀਮਾ ਤੋਂ ਇੱਕ-ਦੋ ਘੱਟ ਗਿਣਤੀ ਹੌਲੀ ਮਾਰਗ ਨਹੀਂ ਸਗੋਂ ਸਖ਼ਤ ਰੁਕਾਵਟ ਹੈ।

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

ਜੀਵਤ ਪ੍ਰਕਿਰਿਆ ਉੱਤੇ ਨਵਾਂ ਮੁੱਲ ਜਾਂਚੋ

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

systemctl daemon-reload
systemctl restart vpn-relay.service
awk '/Max open files/ {print}' /proc/$(systemctl show -p MainPID --value vpn-relay.service)/limits
ss -tnp state established '( sport = :2222 )' | wc -l

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

ਕਿਸੇ ਵੀ ਵੱਡੇ ਵਾਧੇ ਨਾਲ ਇੱਕ ਚੇਤਾਵਨੀ ਆਉਂਦੀ ਹੈ। select() ਨਾਲ ਪੋਲ ਕਰਨ ਵਾਲੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ FD_SETSIZE ਤੋਂ ਉੱਪਰਲੇ ਡਿਸਕ੍ਰਿਪਟਰ ਨਹੀਂ ਦੇਖ ਸਕਦੀਆਂ, ਜੋ ਆਮ ਬਿਲਡਾਂ ਵਿੱਚ 1024 ਹੈ, ਇਸ ਲਈ ਇਸਤੋਂ ਉੱਪਰ ਚੁੱਕੀ ਸੀਮਾ ਅਸੰਬੰਧਿਤ ਦਿਖਣ ਵਾਲੀਆਂ ਅਸਫਲਤਾਵਾਂ ਪੈਦਾ ਕਰ ਸਕਦੀ ਹੈ। systemd ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਸੰਦਰਭ ਆਪਣੇ ਸ਼ੁਰੂ ਕੀਤੇ ਸੇਵਾਵਾਂ ਲਈ ਉਹੀ ਚੇਤਾਵਨੀ ਰੱਖਦਾ ਹੈ।

ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰਨ ਨੂੰ ਟਨਲ ਦੀ ਉਪਲਬਧਤਾ ਤੋਂ ਦੂਰ ਰੱਖੋ

ਰੀਲਾ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰਨ ਨਾਲ ਇਸਦੇ ਸਰਗਰਮ ਸੈਸ਼ਨ ਡਿੱਗਦੇ ਹਨ, ਅਤੇ ਇਹ VPN ਦੇ ਹੇਠਾਂ ਜਾਣ ਤੋਂ ਵੱਖਰੀ ਘਟਨਾ ਹੈ। ਤਬਦੀਲੀ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਤਰਤੀਬ ਦਿਓ ਕਿ ਰੀਲਾ ਚੱਕਰ ਕੱਢਦਾ ਰਹੇ ਅਤੇ ਟਨਲ ਉੱਪਰ ਰਹੇ, ਅਤੇ ਜਿਸਦਾ ਲੰਮਾ ਸੈਸ਼ਨ ਇਸਨੂੰ ਪਾਰ ਕਰਦਾ ਹੈ ਉਸਨੂੰ ਚੇਤਾਵਨੀ ਦਿਓ।

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