ਬੂਟ ਸਮੇਂ SoftEther ਕਲਾਇੰਟ: AccountStartupSet ਅਤੇ ਡੈਮਨ ਦਾ ਕ੍ਰਮ

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

ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਖਾਤਾ ਆਪਣੇ-ਆਪ ਸ਼ੁਰੂ ਹੋਣ ਲਈ ਨਿਸ਼ਾਨਿਤ ਹੈ

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

cd /opt/softether/vpnclient
./vpncmd

VPN ਕਲਾਇੰਟ ਪ੍ਰਬੰਧਨ ਲਈ 2 ਚੁਣੋ ਅਤੇ Enter ਦਬਾ ਕੇ ਸਥਾਨਕ ਸਰਵਰ ਸਵੀਕਾਰ ਕਰੋ।

AccountStartupSet
office-hub
exit

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

ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਸੇਵਾ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਕਾਫ਼ੀ ਜਲਦੀ

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

cd /opt/softether/vpnclient
./vpnclient start

ਜਿੱਥੇ rc.local ਨਹੀਂ ਹੈ, ਉੱਥੇ ਸਪਸ਼ਟ WorkingDirectory ਅਤੇ ਰੀਸਟਾਰਟ ਨੀਤੀ ਵਾਲੀ systemd ਯੂਨਿਟ ਲਿਖੋ। ਬਾਈਨਰੀ ਆਪਣੀ ਸੰਰਚਨਾ ਉਸ ਥਾਂ ਦੇ ਸਾਪੇਖਿਕ ਹੱਲ ਕਰਦੀ ਹੈ ਜਿੱਥੋਂ ਇਹ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ ਉਸ ਸੈਟਿੰਗ ਤੋਂ ਬਿਨਾਂ ਯੂਨਿਟ ਸਫਲਤਾਪੂਰਵਕ ਸ਼ੁਰੂ ਹੋ ਕੇ ਕੁਝ ਵੀ ਨਹੀਂ ਪੜ੍ਹ ਸਕਦੀ। ਕ੍ਰਮ ਸਮੱਸਿਆ ਦਾ ਦੂਜਾ ਅੱਧਾ ਹਿੱਸਾ ਹੈ: ਡੈਮਨ ਦੇ ਸੁਣਨਾ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਚੱਲਣ ਵਾਲੀ ਕਨੈਕਸ਼ਨ ਕੋਸ਼ਿਸ਼ ਕਦੇ-ਕਦਾਈਂ ਅਸਫਲ ਹੁੰਦੀ ਹੈ, ਜਿਸਦਾ ਨਿਦਾਨ ਲਗਾਤਾਰ ਅਸਫਲਤਾ ਨਾਲੋਂ ਕਿਤੇ ਔਖਾ ਹੈ। ਰੀਸਟਾਰਟ ਨੀਤੀ ਤੀਜੀ ਸਥਿਤੀ ਨੂੰ ਢਕਦੀ ਹੈ, ਜਿੱਥੇ ਡੈਮਨ ਘੰਟਿਆਂ ਬਾਅਦ ਚੁੱਪਚਾਪ ਮਰ ਜਾਂਦਾ ਹੈ।

ਪਿਛਲੇ ਬੂਟ ਵੱਲੋਂ ਛੱਡੀ ਗਈ pid ਫਾਈਲ ’ਤੇ ਭਰੋਸਾ ਕਰਨ ਦੀ ਬਜਾਏ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੀ ਸੂਚੀ ਜਾਂਚੋ।

ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਅਡੈਪਟਰ ਨੂੰ ਪਤਾ ਮਿਲਿਆ ਹੈ

ਖਾਤਾ ਜੁੜਦਿਆਂ ਹੀ ਕਲਾਇੰਟ ਇੱਕ ਵਰਚੁਅਲ ਅਡੈਪਟਰ ਦਿਖਾਉਂਦਾ ਹੈ ਅਤੇ ਅਡੈਪਟਰ ਨੂੰ ਅਜੇ ਵੀ ਪਤੇ ਦੀ ਲੋੜ ਹੈ। SecureNAT ਚਲਾਉਣ ਵਾਲਾ ਹੱਬ ਆਮ ਤੌਰ ’ਤੇ DHCP ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ; ਭੌਤਿਕ LAN ਨਾਲ ਬ੍ਰਿਜ ਕੀਤਾ ਹੱਬ ਇਸ ਦੀ ਬਜਾਏ ਉਸ LAN ਦੇ ਸਰਵਰ ਦੇ ਜਵਾਬ ਦੇਣ ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ।

ip -brief address
dhclient vpn_vpn1

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

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

ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਰੂਟ ਉੱਥੇ ਜਾ ਰਿਹਾ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਸੋਚਦੇ ਹੋ

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

ip route get 10.10.20.15

ਹੱਬ ਦੀ ਰੇਂਜ ਨਾਲ ਓਵਰਲੈਪ ਹੁੰਦਾ ਸਥਾਨਕ ਸਬਨੈੱਟ ਜਿੱਤਦਾ ਹੈ, ਕਿਉਂਕਿ ਇਸਦਾ ਰੂਟ ਵਧੇਰੇ ਖਾਸ ਹੈ ਅਤੇ ਪਹਿਲਾਂ ਹੀ ਸਥਾਪਿਤ ਹੈ।

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

ਚਾਰੇ ਜਾਂਚਾਂ ਪੁਨਰ-ਨਿਰਮਾਣ ਨੋਟਾਂ ਵਿੱਚ ਲਿਖੋ

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

ਫਲੈਗ ਦੁਬਾਰਾ ਲਾਗੂ ਕਰਨ ਦੀ ਇੱਕ ਲਾਈਨ ਹੈ ਅਤੇ ਭੁੱਲਣਾ ਸੌਖਾ ਹੈ।

ਕ੍ਰਮ ਰੱਖੋ: ਫਲੈਗ, ਸੇਵਾ, ਪਤਾ, ਰੂਟ। ਵਿਚਕਾਰੋਂ ਸ਼ੁਰੂ ਹੋਣ ਵਾਲੀ ਜਾਂਚ-ਸੂਚੀ ਬਹੁਤ ਸਾਰੇ ਆਤਮ-ਵਿਸ਼ਵਾਸੀ ਗਲਤ ਜਵਾਬ ਦਿੰਦੀ ਹੈ।