Pi VPN ਸਰਵਰ: ਰੈਸਿਪੀ ਨਹੀਂ, ਫ਼ੋਨ ਦੀ ਐਪ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ

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

ਉਹ ਕ੍ਰਮ ਜੋ ਦੁਬਾਰਾ ਬਣਾਉਣ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ

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

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

ਐਪ ਤੈਅ ਹੋਣ ਮਗਰੋਂ ਸਰਵਰ ਦੀ ਚੋਣ ਸੰਕੁਚਿਤ ਹੋ ਜਾਂਦੀ ਹੈ ਅਤੇ ਬਾਕੀ ਬਿਲਡ ਦਾ ਟੀਚਾ ਹੁੰਦਾ ਹੈ।

ਫ਼ੋਨ ਦੀ ਐਪ ਅਸਲ ਵਿੱਚ ਕੀ ਲਾਗੂ ਕਰਦੀ ਹੈ

ਪ੍ਰਕਾਸ਼ਿਤ ਕਲਾਇੰਟ ਸੂਚੀ ਸੇਵਾ ਨਹੀਂ, ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਵਰਣਨ ਕਰਦੀ ਹੈ। Android ਲਈ OpenVPN Connect ਐਪ OpenVPN ਸਰਵਰ ਦੀ ਉਮੀਦ ਕਰਦੀ ਹੈ; ਇਹ ਸਰਵਰ ਵਾਲਾ ਪਾਸਾ ਨਹੀਂ ਦਿੰਦੀ। ਪ੍ਰੋਫ਼ਾਈਲ ਸਮਾਨ ਦਿਸਣ 'ਤੇ ਇਹ IPsec ਜਾਂ L2TP ਕਲਾਇੰਟ ਵੀ ਨਹੀਂ ਬਣਦੀ।

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

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

ਚਾਰ ਹਿੱਸਿਆਂ ਦਾ ਸਮਝੌਤਾ

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

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

ਪ੍ਰਮਾਣ-ਪੱਤਰਾਂ ਦੇ ਵੱਖਰੇ ਕੰਮ ਹਨ

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

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

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

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

ਪਹੁੰਚ ਇੱਕ ਵੱਖਰਾ ਇਕਰਾਰਨਾਮਾ ਹੈ

ਫ਼ੋਨ ਨੂੰ ਸਰਵਰ ਦੇ ਬਾਹਰੀ ਅੰਤ ਬਿੰਦੂ ਤੱਕ ਅਸਲ ਅੱਪਸਟ੍ਰੀਮ ਬੰਦੋਬਸਤ ਰਾਹੀਂ ਪਹੁੰਚਣਾ ਚਾਹੀਦਾ ਹੈ। ਘਰ ਦੇ ਰਾਊਟਰ ਦਾ ਅਨੁਵਾਦ, ਫ਼ਿਲਟਰਿੰਗ ਅਤੇ ਆਪਰੇਟਰ ਦਾ NAT ਸਾਰੇ ਦੋਵਾਂ ਦੇ ਵਿਚਕਾਰ ਹੁੰਦੇ ਹਨ। ਗਤੀਸ਼ੀਲ DNS ਨਾਮ ਅੰਤ ਬਿੰਦੂ ਨੂੰ ਸਿਰਫ਼ ਸਥਿਰ ਨਾਮ ਦਿੰਦਾ ਹੈ; ਇਹ ਅੰਦਰ ਆਉਣ ਵਾਲਾ ਰਾਹ ਨਹੀਂ ਬਣਾਉਂਦਾ।

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

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