ਇੰਟਰਨੈੱਟ ਲਿੰਕ ਤੋਂ ਬਿਨਾਂ LAN 'ਤੇ Raspberry Pi ਦਾ ਪ੍ਰਸ਼ਾਸਨ

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

ਇਸ ਗਾਈਡ ਦੀ ਧਾਰਨਾ ਇਹ ਹੈ ਕਿ ਦੋਵੇਂ ਡਿਵਾਈਸਾਂ ਕੋਲ ਇੱਕੋ ਨਿੱਜੀ ਨੈੱਟਵਰਕ 'ਤੇ ਮਨਜ਼ੂਰ ਪਤੇ ਹਨ। ਕੇਵਲ ਇਸ ਗੱਲ ਤੋਂ ਪਹੁੰਚ ਦਾ ਅੰਦਾਜ਼ਾ ਨਾ ਲਗਾਓ ਕਿ ਦੋਵੇਂ ਇੱਕੋ wifi ਨਾਲ ਜੁੜੇ ਹਨ; ਕਨੈਕਸ਼ਨ, ਰੂਟਿੰਗ ਅਤੇ ਪਹੁੰਚ ਨਿਯਮ ਅਜੇ ਵੀ ਇਹ ਤੈਅ ਕਰਦੇ ਹਨ।

ਸੁਰੱਖਿਆ ਕੰਮ ਅਨੁਸਾਰ ਚੁਣੋ, ਆਦਤ ਅਨੁਸਾਰ ਨਹੀਂ

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

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

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

ਸੂਚੀ ਬਣਾਓ ਕਿ LAN ਕੀ ਛੱਡੇਗਾ

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

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

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

ਪਛਾਣ ਜਾਂਚਾਂ ਉੱਥੇ ਰੱਖੋ ਜਿੱਥੇ ਉਹਨਾਂ ਦੀ ਥਾਂ ਹੈ

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

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

ਅਪਲਿੰਕ ਅਸਲ ਵਿੱਚ ਗੈਰ-ਮੌਜੂਦ ਹੋਣ 'ਤੇ ਪਰਖੋ

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

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