FreeBind ਬਨਾਮ After=: systemd ਸਾਕਟ ਨੂੰ VPN ਪਤੇ ਨਾਲ ਬੰਨ੍ਹਣਾ

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

ਦੋ ਵੱਖਰੀਆਂ ਸਮੱਸਿਆਵਾਂ, ਦੋ ਵੱਖਰੇ ਸਵਿੱਚ

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

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

FreeBind: ਪਤੇ ਤੋਂ ਪਹਿਲਾਂ ਸਰੋਤਾ ਮੌਜੂਦ

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

[Socket]
ListenStream=
ListenStream=10.8.0.1:8443
FreeBind=yes

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

systemd ਸਾਕਟ ਸੰਦਰਭ ਇਸ ਵਿਕਲਪ ਪਿੱਛੇ IPv4 ਅਤੇ IPv6 ਵਿਵਹਾਰ ਦਸਤਾਵੇਜ਼ ਕਰਦਾ ਹੈ, ਅਤੇ ਮਹੱਤਵਪੂਰਨ ਵੇਰਵਾ ਇਹ ਹੈ ਕਿ ਇਹ ਬੰਨ੍ਹਣ ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ, ਰੂਟਿੰਗ ਤੇ ਨਹੀਂ। ਇਸ ਵਿੱਚ ਕੁਝ ਵੀ ਪਤਾ ਨਹੀਂ ਦਿੰਦਾ ਜਾਂ VPN ਸ਼ੁਰੂ ਨਹੀਂ ਕਰਦਾ। FreeBind ਸਰੋਤੇ ਨੂੰ ਦਿੱਤੀ ਆਗਿਆ ਹੈ, ਇੰਟਰਫੇਸ ਦਾ ਬਦਲ ਨਹੀਂ।

After= ਅਤੇ Wants=: ਕ੍ਰਮ ਤਿਆਰੀ ਨਹੀਂ ਹੈ

ਕ੍ਰਮ ਅਤੇ ਲੋੜ ਵੱਖਰੇ ਧੁਰੇ ਹਨ, ਅਤੇ ਇਨ੍ਹਾਂ ਨੂੰ ਮਿਲਾਉਣ ਨਾਲ ਅਜਿਹੀਆਂ ਇਕਾਈਆਂ ਬਣਦੀਆਂ ਹਨ ਜੋ ਸਹੀ ਕ੍ਰਮ ਵਿੱਚ ਸ਼ੁਰੂ ਹੋ ਕੇ ਵੀ ਫੇਲ੍ਹ ਹੁੰਦੀਆਂ ਹਨ। After=vpn-client.service ਦਾ ਮਤਲਬ ਸਿਰਫ਼ ਇਹ ਹੈ ਕਿ ਜੇ ਦੋਵੇਂ ਕੰਮ ਸ਼ੁਰੂ ਹੋਣ, ਤਾਂ ਇਹ ਦੂਜੇ ਦੇ ਸ਼ੁਰੂ ਹੋਣ ਦੀ ਉਡੀਕ ਕਰਦਾ ਹੈ। ਇਹ VPN ਨੂੰ ਖਿੱਚਦਾ ਨਹੀਂ, ਅਤੇ VPN ਦੇ ਜੁੜਨਾ ਪੂਰਾ ਹੋਣ ਦੀ ਉਡੀਕ ਨਹੀਂ ਕਰਦਾ।

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

systemctl cat ਅਤੇ systemctl show -p After -p Wants -p Requires ਨਾਲ ਜਾਂਚੋ ਕਿ ਇਕਾਈ ਅਸਲ ਵਿੱਚ ਕੀ ਐਲਾਨ ਕਰਦੀ ਹੈ। ਤਿੰਨ ਵੱਖਰੀਆਂ ਡਾਇਰੈਕਟਰੀਆਂ ਦੇ drop-in ਉਹ ਨਿਰਦੇਸ਼ ਜੋੜ ਸਕਦੇ ਹਨ ਜੋ ਤੁਸੀਂ ਕਦੇ ਨਹੀਂ ਲਿਖੇ, ਅਤੇ systemd ਸਿਰਫ਼ ਪ੍ਰਭਾਵੀ ਇਕਾਈ ਪੜ੍ਹਦਾ ਹੈ।

network-online.target ਜੋ ਨਹੀਂ ਕਰਦਾ

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

systemd ਪ੍ਰੋਜੈਕਟ ਉਹ ਫ਼ਰਕ ਸਿੱਧਾ ਦਸਤਾਵੇਜ਼ ਕਰਦਾ ਹੈ, ਅਤੇ ਵਿਹਾਰਕ ਨਤੀਜਾ ਇਹ ਹੈ ਕਿ ਟਨਲ ਪਤਾ ਲੋੜੀਂਦਾ ਹੋਣ ਤੇ ਨਿਰਭਰਤਾ ਆਪਣੇ ਆਪ ਰੱਖਣੀ ਪੈਂਦੀ ਹੈ। ਜੋ ਇਕਾਈ network-online ਦੀ ਉਡੀਕ ਕਰਕੇ ਫਿਰ ਟਨਲ ਪਤਾ ਬੰਨ੍ਹਦੀ ਹੈ, ਉਹ ਸਿਰਫ਼ ਤਦ ਸਹੀ ਹੈ ਜਦੋਂ ਟਨਲ ਸੰਜੋਗ ਨਾਲ ਪਹਿਲਾਂ ਚੜ੍ਹੇ, ਅਤੇ ਉਹ ਸੰਜੋਗ ਹੈ, ਡਿਜ਼ਾਈਨ ਨਹੀਂ।

ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਜੋ ਜੀਵਨ-ਚੱਕਰ ਚੁਣਿਆ, ਉਸਦੀ ਜਾਂਚ ਕਰੋ

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

systemd-analyze verify myapp.socket
systemctl cat myapp.socket
ss -ltn "sport = :8443"

ਪਹਿਲਾ ਹੁਕਮ ਰੀਸਟਾਰਟ ਤੋਂ ਪਹਿਲਾਂ ਇਕਾਈ-ਫਾਈਲ ਦੀਆਂ ਗਲਤੀਆਂ ਫੜਦਾ ਹੈ, ਦੂਜਾ ਇਕੱਠੀ ਇਕਾਈ ਦਿਖਾਉਂਦਾ ਹੈ, ਅਤੇ ਤੀਜਾ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਸਰੋਤਾ ਹੈ ਜਾਂ ਨਹੀਂ ਅਤੇ ਕਿਹੜੇ ਪਤੇ ਤੇ। ਜਿੱਥੇ ਤੁਸੀਂ ਟਨਲ ਪਤੇ ਦੀ ਉਮੀਦ ਕੀਤੀ ਸੀ ਉੱਥੇ wildcard ਪਤੇ ਤੇ ਸਰੋਤਾ ਉਹੀ ਬਚਿਆ ਹਿੱਸਾ ਹੈ ਜੋ ਖਾਲੀ ListenStream ਨੇ ਹਟਾਉਣਾ ਸੀ। ਪਤਾ ਹਿੱਲਿਆ ਜਾਂ ਨਹੀਂ ਇਹ ਵੇਖਣ ਲਈ VPN ਮੁੜ-ਕਨੈਕਸ਼ਨ ਤੋਂ ਬਾਅਦ ਤੀਜਾ ਹੁਕਮ ਦੁਹਰਾਓ।

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