ਇੱਕ ਫ਼ਾਈਲ ਲਿਆਉਣ ਲਈ ਪੂਰਾ ਨੈੱਟਵਰਕ VPN ਜ਼ਰੂਰੀ ਨਹੀਂ

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

ਤਿੰਨ ਲੋੜਾਂ ਇੱਥੇ ਇਕੋ ਜਿਹੀਆਂ ਦਿਸਦੀਆਂ ਹਨ ਅਤੇ ਬਹੁਤ ਵੱਖਰਾ ਵਿਵਹਾਰ ਕਰਦੀਆਂ ਹਨ: ਤਿਆਰ PDF ਦੀ ਨਕਲ ਕਰਨਾ, ਦਸਤਾਵੇਜ਼ ਨੂੰ ਉਸੇ ਥਾਂ ਸੰਪਾਦਿਤ ਕਰਨਾ, ਅਤੇ ਸਾਂਝੀ ਡਾਇਰੈਕਟਰੀ ਵਿਰੁੱਧ ਐਪਲੀਕੇਸ਼ਨ ਚਲਾਉਣਾ।

ਫ਼ੋਲਡਰ ਤੋਂ ਨਹੀਂ, ਸੰਪਾਦਨ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ

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

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

SFTP ਇੱਕ ਟ੍ਰਾਂਸਫ਼ਰ ਪ੍ਰੋਟੋਕਾਲ ਹੈ, ਸਾਂਝ ਨਹੀਂ

SFTP ਐਨਕ੍ਰਿਪਟਿਡ SSH ਟ੍ਰਾਂਸਪੋਰਟ ਉੱਤੇ ਫ਼ਾਈਲਾਂ ਭੇਜਦਾ ਹੈ, ਜੋ ਨਕਲ ਨੂੰ ਬਿਲਕੁਲ ਉਹੀ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਨਕਸ਼ੇਬੱਧ ਡਰਾਈਵ ਨੂੰ ਨਹੀਂ। ਇਹ FTP ਨਹੀਂ ਹੈ, ਅਤੇ FTPS ਦੇਣ ਵਾਲਾ ਉਤਪਾਦ SFTP ਦੀ ਥਾਂ ਦੂਜਾ ਪ੍ਰੋਟੋਕਾਲ ਦਿੰਦਾ ਹੈ। ਫ਼ਾਈਲਸਿਸਟਮ ਪਰਤ ਰਾਹੀਂ SFTP ਡਾਇਰੈਕਟਰੀ ਮਾਊਂਟ ਕਰਨਾ ਅਸਲੀ ਸਾਂਝ ਦੀ ਲਾਕਿੰਗ, ਇਜਾਜ਼ਤ ਜਾਂ ਐਪਲੀਕੇਸ਼ਨ ਵਿਵਹਾਰ ਦੀ ਗਰੰਟੀ ਨਹੀਂ ਦਿੰਦਾ। ਇਸ ਨੂੰ ਸਿੱਧਾ ਬਦਲ ਕਹਿਣ ਤੋਂ ਪਹਿਲਾਂ ਕਲਾਇੰਟ ਐਪਲੀਕੇਸ਼ਨ ਦੀਆਂ ਲੋੜਾਂ ਜਾਂਚੋ।

sftp [email protected]
put report.pdf /upload/report.pdf
get /shared/template.docx

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

ਜੇ ਤੁਹਾਨੂੰ ਸਾਂਝ ਚਾਹੀਦੀ ਹੈ, ਤਾਂ ਇਸ ਨੂੰ ਪ੍ਰਕਾਸ਼ਿਤ ਨਾ ਕਰੋ

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

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

ਪਹੁੰਚ ਸੌਂਪਣ ਤੋਂ ਪਹਿਲਾਂ ਕੀ ਜਾਂਚਣਾ ਹੈ

sftp [email protected] <<< "get /shared/template.docx /tmp/probe.docx"
ssh [email protected] "cat /etc/passwd"

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

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