ਸੈਟਅਪ ਸਕ੍ਰਿਪਟ ਚੱਲਣ ਤੋਂ ਬਾਅਦ VPN ਸਰਵਰ ਦਾ ਮਾਲਕ ਕੋਈ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ

ਦੋ ਵੱਖਰੇ ਕੰਮ ਇੱਕ ਵਜੋਂ ਵੇਚੇ ਜਾਂਦੇ ਹਨ: ਮਸ਼ੀਨ ਨੂੰ VPN ਸਰਵਰ ਬਣਾਉਣਾ, ਅਤੇ ਦੂਜੇ ਦੇ ਗੇਟਵੇ ਵਿੱਚ ਜਾਣ ਵਾਲੇ ਲੈਪਟਾਪ ਵਿੱਚ VPN ਕਲਾਇੰਟ ਜੋੜਨਾ। ਸੈਟਅਪ ਸਕ੍ਰਿਪਟ ਪਹਿਲੇ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ ਅਤੇ ਦੂਜੇ ਦਾ ਨਹੀਂ ਦੇ ਸਕਦੀ, ਇਸਦਾ README ਕੁਝ ਵੀ ਕਿਉਂ ਨਾ ਕਹੇ। setup-ipsec-vpn ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਠੋਸ ਉਦਾਹਰਨ ਮੰਨੋ: ਇਹ ਸਮਰਥਿਤ Linux ਹੋਸਟ ਉੱਤੇ Libreswan ਅਤੇ xl2tpd ਵਰਤ ਕੇ IPsec/L2TP, Cisco IPsec ਜਾਂ IKEv2 ਸਰਵਰ ਬਣਾਉਂਦੀ ਹੈ। ਇਹ ਸਰਵਰ ਲਈ ਤੈਨਾਤੀ ਸਮਝੌਤਾ ਹੈ, ਕਿਸੇ ਵੀ ਮਸ਼ੀਨ ਲਈ ਆਮ ਵਿਧੀ ਨਹੀਂ। ਸਕ੍ਰਿਪਟ ਚੱਲਣ ਤੋਂ ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ ਤੁਹਾਡਾ ਕੰਮ ਕਿਹੜਾ ਹੈ, ਕਿਉਂਕਿ ਇਸਤੋਂ ਬਾਅਦ ਸਭ ਕੁਝ ਸਰਵਰ ਬਾਰੇ ਹੈ।

ਹੋਸਟ ਬਾਰੇ ਇਮਾਨਦਾਰ ਰਹੋ

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

ਸੇਵਾ ਸਮਰੱਥ ਕਰਨ ਨਾਲ ਉਸਦਾ ਰਾਹ ਨਹੀਂ ਖੁੱਲ੍ਹਦਾ। IPsec ਲਈ ਹੋਸਟ ਅੱਗੇ ਦਾ ਨੈੱਟਵਰਕ UDP 500 ਅਤੇ 4500 ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇਵੇ ਅਤੇ ਤੈਨਾਤੀ ਅਨੁਸਾਰ ESP ਪ੍ਰੋਟੋਕੋਲ ਵੀ। ਜੋ ਸਕ੍ਰਿਪਟ ਪ੍ਰੋਟੋਕੋਲ 50 ਸੁੱਟਣ ਵਾਲੇ ਸੁਰੱਖਿਆ ਸਮੂਹ ਪਿੱਛੇ ਸਫਲ ਹੁੰਦੀ ਹੈ, ਉਸਨੇ ਐਸਾ ਸਰਵਰ ਬਣਾਇਆ ਹੈ ਜਿੱਥੇ ਕੋਈ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦਾ, ਅਤੇ ਇੰਸਟਾਲਰ ਦੇ ਆਉਟਪੁੱਟ ਵਿੱਚ ਕੁਝ ਵੀ ਇਹ ਨਹੀਂ ਕਹੇਗਾ।

ਇੰਸਟਾਲਰ ਅਸਲ ਵਿੱਚ ਕੀ ਲੈਂਦਾ ਹੈ

IPsec ਕਨਫਿਗਰੇਸ਼ਨ ਅਤੇ ਭੇਤ ਫਾਈਲ, L2TP ਡੈਮਨ ਕਨਫਿਗਰੇਸ਼ਨ, PPP ਚੋਣਾਂ ਅਤੇ ਹੁਣ ਉਨ੍ਹਾਂ ਪੋਰਟਾਂ ਦੇ ਮਾਲਕ systemd ਯੂਨਿਟਾਂ ਦੀ ਆਸ ਰੱਖੋ। ਪ੍ਰੋਜੈਕਟ ਦਾ README ਕਹਿੰਦਾ ਹੈ ਕਿ ਬਦਲਾਅ ਤੋਂ ਪਹਿਲਾਂ ਮੌਜੂਦਾ ਕਨਫਿਗਰੇਸ਼ਨ ਫਾਈਲਾਂ ਦਾ ਬੈਕਅੱਪ ਲਿਆ ਜਾਂਦਾ ਹੈ, ਜੋ ਲਾਹੇਵੰਦ ਹੈ ਅਤੇ ਹੋਸਟ ਬੈਕਅੱਪ ਵਰਗਾ ਨਹੀਂ। ਤੈਅ ਕਰੋ ਕਿ ਕਿਹੜੇ ਹਿੱਸੇ ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਦੇ ਪੈਕੇਜਾਂ ਨਾਲ ਅਤੇ ਕਿਹੜੇ ਸਕ੍ਰਿਪਟ ਦੁਬਾਰਾ ਚਲਾ ਕੇ ਜਾਂ ਮੁੜ ਲਿਖ ਕੇ ਅੱਪਡੇਟ ਹੋਣਗੇ, ਕਿਉਂਕਿ ਇਹ ਵੱਖਰੇ ਫੇਲ੍ਹ ਹੋਣ ਦੇ ਢੰਗਾਂ ਵਾਲੇ ਦੋ ਰੱਖ-ਰਖਾਅ ਮਾਰਗ ਹਨ।

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

ਸਕ੍ਰਿਪਟ ਕੀ ਨਹੀਂ ਦੇ ਸਕਦੀ

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

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

ਪਹਿਲਾ ਕਲਾਇੰਟ ਹੀ ਸਵੀਕ੍ਰਿਤੀ ਪਰਖ ਹੈ

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

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

ਹੈਂਡਓਫ ਪੰਨਾ ਲਿਖੋ

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

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