VPN ਪਤੇ 'ਤੇ ਬੰਨ੍ਹਿਆ NFS ਨਿਰਯਾਤ: ਇਹ ਕੀ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ
ਨਿਰਯਾਤ ਨਿਯਮ ਜਾਂਚਦਾ ਹੈ ਕਿ ਪੈਕਟ ਕਿੱਥੋਂ ਆਇਆ; AUTH_SYS ਸਥਾਨਕ UID ਦਾ ਦਾਅਵਾ ਕਰਦਾ ਹੈ ਅਤੇ Kerberos ਵਰਤੋਂਕਾਰ ਦੀ ਪ੍ਰਮਾਣਿਕਤਾ ਕਰਦਾ ਹੈ। ਤੈਅ ਕਰੋ ਕਿ ਤੁਹਾਡੀ ਫਾਈਲ ਸੇਵਾ ਨੂੰ ਕਿਹੜਾ ਚਾਹੀਦਾ ਹੈ।
ਇੱਕ ਹੋਸਟ ਡਾਇਰੈਕਟਰੀ ਨੂੰ VPN ਪਤੇ 'ਤੇ ਨਿਰਯਾਤ ਕਰਦਾ ਹੈ, ਮਾਊਂਟ ਸਫਲ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਡਿਜ਼ਾਈਨ ਪ੍ਰਮਾਣਿਤ ਵਜੋਂ ਦਰਜ ਹੋ ਜਾਂਦਾ ਹੈ। ਉਹ ਨਿਯਮ ਅਸਲ ਵਿੱਚ ਸਿਰਫ਼ ਇਹ ਸੀਮਤ ਕਰਦਾ ਹੈ ਕਿ ਪੈਕਟ ਕਿੱਥੋਂ ਆਉਂਦੇ ਦਿਸਦੇ ਹਨ। ਫਾਈਲ ਕਿਰਿਆ ਚਲਾਉਣ ਵਾਲਾ ਵਿਅਕਤੀ ਉਹੀ ਹੈ ਜੋ ਉਹ ਆਪਣੇ ਆਪ ਨੂੰ ਕਹਿੰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਇਹ NFS ਸੁਰੱਖਿਆ ਫਲੇਵਰ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਸ ਕਿਸਮ ਦੇ ਜ਼ਿਆਦਾਤਰ ਨਿਰਯਾਤਾਂ ਵਿੱਚ ਕਿਸੇ ਨੇ ਵੀ ਇਸਨੂੰ ਡਿਫ਼ਾਲਟ ਤੋਂ ਨਹੀਂ ਬਦਲਿਆ।
ਇੱਕ ਬੇਨਤੀ ਵਿੱਚ ਤਿੰਨ ਪਛਾਣਾਂ ਆ ਸਕਦੀਆਂ ਹਨ
VPN ਸਾਥੀ ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਜਾਂ ਸਾਥੀ ਕੁੰਜੀ ਵਰਗੀ ਰਜਿਸਟਰਡ ਪਛਾਣ ਰੱਖਦਾ ਹੈ। ਅੰਦਰਲਾ IP ਪੈਕਟ ਸਰੋਤ ਪਤਾ ਰੱਖਦਾ ਹੈ। ਫਾਈਲ ਕਿਰਿਆ ਉਹ ਵਰਤੋਂਕਾਰ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਰੱਖਦੀ ਹੈ ਜੋ ਇਸਦਾ NFS ਤੰਤਰ ਦਿੰਦਾ ਹੈ। ਜੋ ਡਿਜ਼ਾਈਨ ਪਤੇ ਨੂੰ ਤਿੰਨਾਂ ਦਾ ਬਦਲ ਮੰਨਦਾ ਹੈ, ਉਸਨੇ ਚੁੱਪਚਾਪ ਉਹੀ ਹਿੱਸਾ ਮੰਨ ਲਿਆ ਹੈ ਜਿਸਦੀ ਪੁਸ਼ਟੀ ਕਰਨੀ ਸੀ।
| Identity | What it proves | What it does not |
|---|---|---|
| VPN peer | Which peer was accepted by the tunnel | Which user runs on that machine |
| Inner source address | Where the packet appears to originate | That only the intended client can use it |
| NFS credential | What the file service believes about the caller | Anything, if the flavour only asserts local IDs |
ਉਹ ਤਿੰਨ ਕਤਾਰਾਂ ਲਿਖਣਾ ਹੀ ਪੂਰੀ ਕਸਰਤ ਹੈ। ਨਿਰਯਾਤ ਸੁਰੱਖਿਅਤ ਹੈ ਜਾਂ ਨਹੀਂ ਇਸ ਬਹਿਸ ਦਾ ਵੱਡਾ ਹਿੱਸਾ ਤਦੇ ਢਹਿ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਸਪਸ਼ਟ ਹੋ ਜਾਂਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਨਿਯੰਤਰਣ ਕਿਹੜੀ ਕਤਾਰ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ।
ਪਤੇ ਦੀ ਮਾਲਕੀ ਲਾਗੂਕਰਨ ਦਾ ਵੇਰਵਾ ਹੈ
ਇੱਕ ਗੇਟਵੇ ਸਵੀਕਾਰ ਕੀਤੇ ਸਾਥੀ ਨੂੰ ਸੁਰੰਗ ਪਤਾ ਦੇ ਸਕਦਾ ਹੈ, ਜਾਂ ਉਸ ਲਈ ਰੂਟ ਕੀਤਾ ਸਬਨੈੱਟ ਅਧਿਕਾਰਤ ਕਰ ਸਕਦਾ ਹੈ। ਫਿਰ ਲਾਗੂਕਰਨ ਉਸ ਪੈਕਟ ਨੂੰ ਰੱਦ ਕਰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ ਜਿਸਦਾ ਅੰਦਰਲਾ ਸਰੋਤ ਕਿਸੇ ਹੋਰ ਕਲਾਇੰਟ ਦਾ ਹੈ, ਇਹ ਉਸ ਲਾਗੂਕਰਨ ਦਾ ਗੁਣ ਹੈ, ਅਤੇ ਮੰਨਣ ਦੀ ਬਜਾਏ ਇਸਦੀ ਜਾਂਚ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।
ਰਵਾਇਤੀ Community OpenVPN ਵਰਤੋਂਕਾਰ-ਸਥਾਨ ਸਰਵਰ ਕੋਡ, ਉਦਾਹਰਣ ਲਈ, TUN ਯੰਤਰ ਰਾਹੀਂ ਪੈਕਟ ਪਹੁੰਚਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਕਿਸੇ ਹੋਰ ਕਲਾਇੰਟ ਨਾਲ ਜੁੜੇ ਸਰੋਤ ਨੂੰ ਰੱਦ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਅਸਲ ਮੁੱਲ ਵਾਲੀ ਪਤਾ-ਮਾਲਕੀ ਜਾਂਚ ਹੈ, ਅਤੇ ਇਹ ਅਜੇ ਵੀ NFS ਵਰਤੋਂਕਾਰ ਪ੍ਰਮਾਣਿਕਤਾ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਨਹੀਂ ਦੱਸਦੀ ਕਿ ਕਿਹੜਾ ਖਾਤਾ ਇਹ ਕਿਰਿਆ ਕਰ ਰਿਹਾ ਹੈ।
ਸਰੋਤ ਅਨੁਵਾਦ ਇਸਨੂੰ ਵੀ ਘਸਾ ਦਿੰਦਾ ਹੈ। NAT ਗੇਟਵੇ ਹਰ ਕਲਾਇੰਟ ਨੂੰ ਇੱਕੋ ਪਤੇ ਵਜੋਂ ਪੇਸ਼ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਨਿਰਯਾਤ ਨਿਯਮ ਇਸਦੇ ਪਿੱਛੇ ਦੇ ਲੋਕਾਂ ਵਿੱਚ ਫ਼ਰਕ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਨਿਯਮ ਦੀ ਦਿਸਦੀ ਸ਼ੁੱਧਤਾ ਫਿਰ ਚਿੱਤਰ ਵੱਲੋਂ ਟਿਕਾਈ ਗਈ ਕਲਪਨਾ ਬਣ ਜਾਂਦੀ ਹੈ। ਜੇ ਨਿਰਯਾਤ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਤਾਂ ਪਤਾ-ਨਿਰਧਾਰਨ ਸਪਸ਼ਟ ਰੱਖੋ, ਅਨੁਵਾਦਕ ਨੂੰ ਇਹ ਤੈਅ ਕਰਨ ਨਾ ਦਿਓ ਕਿ ਕੌਣ ਕਿਸਦੀ ਥਾਂ ਗਿਣਿਆ ਜਾਂਦਾ ਹੈ।
ਨਿਰਯਾਤ 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸੁਰੱਖਿਆ ਫਲੇਵਰ ਪੜ੍ਹੋ
Red Hat ਦੀ NFS ਮਾਰਗਦਰਸ਼ਨ sec=sys, ਜੋ AUTH_SYS ਰਾਹੀਂ ਸਥਾਨਕ UNIX UID ਅਤੇ GID ਵਰਤਦਾ ਹੈ, ਨੂੰ Kerberos ਢੰਗਾਂ ਤੋਂ ਵੱਖ ਕਰਦੀ ਹੈ। krb5 ਵਰਤੋਂਕਾਰ ਪ੍ਰਮਾਣਿਕਤਾ ਜੋੜਦਾ ਹੈ, krb5i ਅਖੰਡਤਾ ਸੁਰੱਖਿਆ ਜੋੜਦਾ ਹੈ, ਅਤੇ krb5p ਟ੍ਰੈਫਿਕ ਲਈ ਗੋਪਨੀਯਤਾ ਸੁਰੱਖਿਆ ਜੋੜਦਾ ਹੈ।
AUTH_SYS ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਵਿੱਚ ਕਾਲਰ ਦਾ UID ਅਤੇ ਸਮੂਹ ਪਛਾਣਕਰਤਾ ਵਰਗੇ ਖੇਤਰ ਹੁੰਦੇ ਹਨ, ਅਤੇ RFC 5531 ਸਪਸ਼ਟ ਚੇਤਾਵਨੀ ਦਿੰਦਾ ਹੈ ਕਿ ਇਹ ਫਲੇਵਰ ਆਪਣੇ ਆਪ ਵਿੱਚ ਕੋਈ ਸੁਰੱਖਿਆ ਨਹੀਂ ਦਿੰਦਾ ਅਤੇ ਬਾਹਰੀ ਸੁਰੱਖਿਆ 'ਤੇ ਨਿਰਭਰ ਹੈ। ਇਸਨੂੰ VPN ਦੇ ਅੰਦਰ ਚਲਾਉਣ ਨਾਲ ਆਵਾਜਾਈ ਲਈ ਸੁਰੱਖਿਆ ਮਿਲਦੀ ਹੈ ਅਤੇ ਪੈਕਟ ਦੇ ਅੰਦਰਲੇ ਦਾਅਵੇ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ।
exportfs -v
showmount -e nfs.example.internalਕਲਾਇੰਟ ਸੂਚੀ ਪੜ੍ਹਨ ਤੋਂ ਪਹਿਲਾਂ ਉਸ ਆਉਟਪੁੱਟ ਵਿੱਚ ਫਲੇਵਰ ਪੜ੍ਹੋ। ਸੀਮਤ ਦਿਸਦਾ ਨਿਰਯਾਤ ਸਿਰਫ਼ ਪਤੇ ਨਾਲ ਸੀਮਤ ਹੋ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਹਰ ਕਾਲਰ ਅਜੇ ਵੀ ਜੋ ਚਾਹੇ ਉਹ UID ਦਾਅਵਾ ਕਰਦਾ ਹੈ।
ਮਾਡਲ ਚੁਣੋ, ਫਿਰ ਅਨੁਮਤੀਆਂ ਰੱਖੋ
ਉਹ ਫਾਈਲ-ਸੇਵਾ ਪ੍ਰਮਾਣਿਕਤਾ ਮਾਡਲ ਚੁਣੋ ਜੋ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਪ੍ਰਬੰਧਿਤ ਕਰਦੇ ਕਲਾਇੰਟਾਂ ਲਈ ਢੁਕਵਾਂ ਹੈ। Kerberos ਨੂੰ ਪਿੱਛੇ ਪਛਾਣ ਅਤੇ ਸੇਵਾ ਤੈਨਾਤੀ ਚਾਹੀਦੀ ਹੈ, ਇਸ ਲਈ ਇੱਕ ਮਾਊਂਟ ਵਿਕਲਪ ਬਦਲਣਾ ਸਥਾਨਾਂਤਰਣ ਨਹੀਂ ਹੈ ਅਤੇ Kerberos ਡੋਮੇਨ, ਪ੍ਰਿੰਸੀਪਲ ਅਤੇ keytab ਨਾ ਹੋਣ ਤੱਕ ਇਹ ਸਿਰਫ਼ ਅਸਫਲ ਹੋਵੇਗਾ।
ਦੋਵਾਂ ਮਾਡਲਾਂ ਵਿੱਚ, ਨਿਰਯਾਤ ਅਨੁਮਤੀਆਂ ਅਤੇ ਫਾਈਲਸਿਸਟਮ ਅਧਿਕਾਰ ਰੱਖੋ ਜੋ ਪ੍ਰਮਾਣਿਤ ਪ੍ਰਿੰਸੀਪਲ ਕੀ ਕਰ ਸਕਦਾ ਹੈ ਸੀਮਤ ਕਰਦੇ ਹਨ। ਪ੍ਰਮਾਣਿਕਤਾ ਦੱਸਦੀ ਹੈ ਕਿ ਕੌਣ ਪੁੱਛ ਰਿਹਾ ਹੈ; ਅਧਿਕਾਰ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਜਵਾਬ ਹਾਂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਇਹਨਾਂ ਦੋਵਾਂ ਨੂੰ ਇੱਕ ਸੈਟਿੰਗ ਵਿੱਚ ਮਿਲਾ ਦੇਣਾ ਹੀ ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਸਥਾਨਾਂਤਰਣ ਪੁਰਾਣੀ ਸੰਰਚਨਾ ਨਾਲੋਂ ਵੱਧ ਅਧਿਕਾਰ ਦੇਣ ਲੱਗਦਾ ਹੈ।
ਪਤਾ ਨਿਯਮ ਨੂੰ ਇਸਦੇ ਅਸਲ ਮਕਸਦ ਲਈ ਵਰਤੋ
ਸੇਵਾ ਨੂੰ ਮਨਜ਼ੂਰ ਮਾਰਗ ਅਤੇ ਸਰੋਤਾਂ ਤੱਕ ਸੀਮਤ ਰੱਖਣਾ ਅਜੇ ਵੀ ਲਾਹੇਵੰਦ ਹੈ, ਜਿਸ ਵਿੱਚ ਹੋਸਟ ਇਨਪੁੱਟ ਨੀਤੀ ਵੀ ਸ਼ਾਮਲ ਹੈ ਜਦੋਂ VPN ਅੰਤ ਬਿੰਦੂ ਅਤੇ NFS ਸਰਵਰ ਇੱਕੋ ਮਸ਼ੀਨ ਸਾਂਝੀ ਕਰਦੇ ਹਨ। ਟ੍ਰੈਫਿਕ ਅੱਗੇ ਭੇਜਣ ਵਾਲੇ ਨਿਯਮ ਉਹਨਾਂ ਬੇਨਤੀਆਂ ਨੂੰ ਨਿਯੰਤਰਿਤ ਨਹੀਂ ਕਰਦੇ ਜੋ ਉਸੇ ਹੋਸਟ 'ਤੇ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਚੱਲ ਰਹੀ ਸੇਵਾ ਵੱਲ ਨਿਸ਼ਾਨਾ ਹਨ। ਇਹ ਅੰਤਰ ਹੈਰਾਨੀਜਨਕ ਗਿਣਤੀ ਵਿੱਚ ਨਿਰਯਾਤਾਂ ਦੀ ਵਿਆਖਿਆ ਕਰਦਾ ਹੈ ਜੋ ਨਿੱਜੀ ਹੋਣੇ ਚਾਹੀਦੇ ਸਨ। ਸੁਰੰਗ ਨਿਯਮ ਇਸਨੂੰ ਢਕਦੇ ਹਨ ਇਹ ਮੰਨਣ ਦੀ ਬਜਾਏ ਸਥਾਨਕ ਇਨਪੁੱਟ ਨੀਤੀ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਜਾਂਚੋ।
ਜਾਂਚੋ ਕਿ ਕੋਈ ਹੋਰ ਇੰਟਰਫੇਸ ਜਾਂ ਸਰੋਤ-ਅਨੁਵਾਦ ਕਰਨ ਵਾਲਾ ਗੇਟਵੇ ਅਚਾਨਕ ਨਿਯਮ ਪੂਰਾ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਅਤੇ ਇਸਨੂੰ ਪਤਾ ਜਾਲੀ ਬਣਾਉਣ ਨਾਲ ਕੰਮ ਕਰਨ ਵਾਲੇ ਮਾਊਂਟ ਦੀ ਗਾਰੰਟੀ ਹੋਣ ਦੇ ਦਾਅਵੇ ਦੀ ਬਜਾਏ ਮੂਲ ਸਥਾਪਤ ਕਰਨ ਦਾ ਕਾਰਨ ਮੰਨੋ।
ਇੱਕ ਦੀ ਬਜਾਏ ਤਿੰਨ ਸਵੀਕ੍ਰਿਤੀ ਕੇਸ ਚਲਾਓ। ਮਨਜ਼ੂਰ ਕਲਾਇੰਟ ਨਾਲ ਮਨਜ਼ੂਰ ਵਰਤੋਂਕਾਰ ਵਜੋਂ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ ਕਦੇ ਮਨਜ਼ੂਰ ਨਾ ਹੋਏ ਸਾਥੀ ਤੋਂ ਦੁਹਰਾਓ, ਫਿਰ ਕੁਝ ਅਜਿਹਾ ਅਜ਼ਮਾਓ ਜੋ ਮਨਜ਼ੂਰ ਵਰਤੋਂਕਾਰ ਨੂੰ ਅਜੇ ਵੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਹੈ। ਫਿਰ ਪੁੱਛੋ ਕਿ ਜੇ ਅਧਿਕਾਰਤ ਕਲਾਇੰਟ ਨਾਲ ਸਮਝੌਤਾ ਹੋ ਜਾਵੇ ਤਾਂ ਕੀ ਬਦਲਦਾ ਹੈ, ਕਿਉਂਕਿ ਆਵਾਜਾਈ ਪ੍ਰਮਾਣਿਕਤਾ ਉਸ ਮਸ਼ੀਨ ਦੀ ਹਰ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਭਰੋਸੇਯੋਗ ਨਹੀਂ ਬਣਾਉਂਦੀ। ਚੋਰੀ ਹੋਇਆ ਸਰਟੀਫਿਕੇਟ ਅਤੇ ਜਿਗਿਆਸੂ ਸਥਾਨਕ ਖਾਤਾ ਵੱਖਰੇ ਨਿਯੰਤਰਣਾਂ ਵਾਲੀਆਂ ਵੱਖਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਹਨ।