ਰੀਬੂਟ ਤੋਂ ਬਾਅਦ VPN ਸਰਵਰ ਦੀ ਰਿਕਵਰੀ ਦੀ ਜਾਂਚ ਕਰੋ: ਪਹਿਲਾਂ ਕੀ ਦੇਖਣਾ ਹੈ

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

ਚਾਰ ਮਾਲਕ, ਚਾਰ ਵੱਖਰੀਆਂ ਜਾਂਚਾਂ

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

ਹਰ ਮਾਲਕ ਆਪਣੀ ਸੰਰਚਨਾ ਕਿਸੇ ਹੋਰ ਥਾਂ ਰੱਖਦਾ ਹੈ। systemd ਦੁਆਰਾ ਪ੍ਰਬੰਧਿਤ OpenVPN ਸਰਵਰ ਸ਼ੁਰੂ ਹੁੰਦਿਆਂ ਆਪਣੀ ਸੰਰਚਨਾ ਪੜ੍ਹਦਾ ਹੈ, ਇਸ ਲਈ ਬੂਟ ਵੇਲੇ ਫਾਈਲ ਵਿੱਚ ਜੋ ਹੈ ਉਹੀ ਚੱਲਦਾ ਹੈ। wg-quick ਇੰਟਰਫੇਸ ਆਪਣੇ ਪਤੇ, ਰੂਟ ਅਤੇ DNS ਉਸੇ ਫਾਈਲ ਤੋਂ ਲੈਂਦਾ ਹੈ, ਭਾਵ ਸ਼ੈੱਲ ਤੋਂ ਹੱਥ ਨਾਲ ਉਠਾਇਆ ਅਤੇ ਕਦੇ ਵੀ unit ਵਜੋਂ ਸਮਰੱਥ ਨਾ ਕੀਤਾ ਇੰਟਰਫੇਸ ਵਾਪਸ ਨਹੀਂ ਆਵੇਗਾ। ਕੰਟੇਨਰ ਆਪਣਾ ਐਂਟਰੀਪਾਇੰਟ ਵਾਪਸ ਲਿਆਉਂਦਾ ਹੈ, ਪਰ ਹੋਸਟ ਦੇ ਫਾਇਰਵਾਲ ਬਦਲਾਅ ਨਹੀਂ, ਜੇ ਉਹ ਕੰਟੇਨਰ ਤੋਂ ਬਾਹਰ ਹੋਣ ਤਾਂ ਛੱਡ ਕੇ।

ਪਹਿਲਾਂ ਆਧਾਰ ਰੇਖਾ, ਨਹੀਂ ਤਾਂ ਨਤੀਜੇ ਦਾ ਕੋਈ ਅਰਥ ਨਹੀਂ

ਕੰਮ ਕਰਦਿਆਂ ਹੀ ਕਾਰਜਸ਼ੀਲ ਹਾਲਤ ਦਰਜ ਕਰੋ: ਟਨਲ ਉੱਤੇ ਪਤੇ, ਕਲਾਇੰਟ ਸਬਨੈੱਟ ਲਈ ਰੂਟ, NAT ਜਾਂ ਫਾਰਵਰਡਿੰਗ ਨਿਯਮ, ਸੁਣਨ ਵਾਲਾ ਸਾਕਟ, ਅਤੇ ਫਾਰਵਰਡਿੰਗ sysctl। ip addr show wg0, ip route, nft list ruleset ਜਾਂ iptables-save, ss -lunp ਅਤੇ sysctl net.ipv4.ip_forward ਬਹੁਤੇ ਹੋਸਟਾਂ ਉੱਤੇ ਕਾਫ਼ੀ ਹਨ।

ਸੇਵਾ ਚੱਲ ਰਹੀ ਹੈ ਕਿ ਨਹੀਂ, ਸਿਰਫ਼ ਇਹ ਨਹੀਂ, ਸਗੋਂ ਇਹ ਕਿਵੇਂ ਸ਼ੁਰੂ ਹੋਣ ਲਈ ਸੰਰਚਿਤ ਹੈ ਉਹ ਵੀ ਦਰਜ ਕਰੋ। systemctl is-enabled wg-quick@wg0 ਅਤੇ systemctl is-active wg-quick@wg0 ਵੱਖ-ਵੱਖ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਬੂਟ ਵੇਲੇ ਸਮਰੱਥ ਹਾਲਤ ਹੀ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਜਿਵੇਂ systemctl(1) ਵਿੱਚ ਵਰਣਿਤ ਹੈ। OpenVPN ਲਈ, ਹੋਸਟ ਕਿਹੜਾ ਟੈਂਪਲੇਟ ਵਰਤਦਾ ਹੈ ਜਾਂਚੋ, ਕਿਉਂਕਿ openvpn@server ਅਤੇ openvpn-server@server ਵੱਖ-ਵੱਖ ਡਿਫਾਲਟ ਵਾਲੇ ਵੱਖਰੇ unit ਹਨ।

ਰੀਸਟਾਰਟ ਚਲਾਓ ਅਤੇ ਪਹਿਲੀ ਅਸਫਲਤਾ ਪੜ੍ਹੋ

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

ਟਨਲ ਵਰਤੋਂ ਯੋਗ ਨਾ ਹੋਣ ਦੌਰਾਨ ਵੀ ਡੈਮਨ ਸਰਗਰਮ ਹੋ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਹੀ ਸਭ ਤੋਂ ਆਮ ਝੂਠੀ ਸਫਲਤਾ ਹੈ। ਜੇ unit ਸਿਰਫ਼ network.target ਦੀ ਉਡੀਕ ਕਰਦਾ ਹੈ, network-online.target ਦੀ ਨਹੀਂ, ਤਾਂ ਨੈੱਟਵਰਕ ਆਨਲਾਈਨ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਸਟਾਰਟਅੱਪ ਪੂਰਾ ਹੋ ਸਕਦਾ ਹੈ। ਪ੍ਰਮਾਣ ਪੱਤਰ, ਕੁੰਜੀਆਂ ਜਾਂ CRL ਵਰਗੀਆਂ ਹਵਾਲਾ ਦਿੱਤੀਆਂ ਫਾਈਲਾਂ ਉਸ ਪਲ ਪੜ੍ਹੀਆਂ ਨਾ ਜਾ ਸਕਣ, ਕਿਉਂਕਿ ਮਾਊਂਟ ਜਾਂ ਭੇਦ ਦਾ ਮਾਰਗ ਅਜੇ ਤਿਆਰ ਨਹੀਂ। unit ਦਾ ਜਰਨਲ ਪੜ੍ਹਨ ਤੱਕ ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਸਮੱਸਿਆ systemctl status ਵਿੱਚ ਨਹੀਂ ਦਿਸਦੀ।

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

ਤੁਹਾਡੇ ਸੁਧਾਰ ਨੂੰ ਤੈਅ ਕਰਨ ਵਾਲੀਆਂ ਤਿੰਨ ਸ਼ਰਤਾਂ

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

ਸੁਧਾਰ ਉੱਥੇ ਕਰੋ ਜਿੱਥੇ ਸੈਟਿੰਗ ਦੀ ਮਾਲਕੀ ਹੈ। ਫਾਰਵਰਡਿੰਗ ਨੂੰ sysctl drop-in ਵਿੱਚ ਰੱਖੋ, NAT ਨਿਯਮਾਂ ਨੂੰ ਬੂਟ ਵੇਲੇ ਲੋਡ ਹੋਣ ਵਾਲੇ ਨਿਯਮ ਸਮੂਹ ਵਿੱਚ ਰੱਖੋ, unit ਨੂੰ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਥਾਂ ਸਮਰੱਥ ਕਰੋ, ਅਤੇ ਭੇਦ ਉਸ ਮਾਰਗ ਉੱਤੇ ਰੱਖੋ ਜੋ unit ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਮੌਜੂਦ ਹੈ। unit ਵਿੱਚ ਨੀਂਦ ਜੋੜਨਾ ਨਿਰਭਰਤਾ ਨੂੰ ਘੋਸ਼ਿਤ ਕਰਨ ਦੀ ਥਾਂ ਲੁਕਾਉਂਦਾ ਹੈ।

ਨਤੀਜਾ runbook ਵਿੱਚ ਦਰਜ ਕਰੋ

ਆਪਣੇ ਆਪ ਕੀ ਵਾਪਸ ਆਇਆ, ਤੁਹਾਨੂੰ ਕੀ ਸ਼ੁਰੂ ਕਰਨਾ ਪਿਆ, ਅਤੇ ਅੰਤਰ ਕਿੰਨਾ ਸਮਾਂ ਰਿਹਾ ਲਿਖੋ। ਜਾਂਚ ਲਈ ਵਰਤੇ ਸਹੀ ਹੁਕਮ ਸ਼ਾਮਲ ਕਰੋ, ਤਾਂ ਜੋ ਅਗਲਾ ਵਿਅਕਤੀ ਨਵਾਂ ਘੜਨ ਦੀ ਥਾਂ ਜਾਂਚ ਨੂੰ ਦੁਹਰਾਏ। ਜੇ ਕਿਸੇ ਕਦਮ ਲਈ ਹੱਥ ਨਾਲ ਹੁਕਮ ਚਾਹੀਦਾ ਸੀ, ਤਾਂ ਉਹ ਹੁਕਮ ਸੰਰਚਨਾ ਦਾ ਹਿੱਸਾ ਹੈ, runbook ਵਿੱਚ ਸਥਾਈ ਕਦਮ ਵਜੋਂ ਨਹੀਂ।

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