OpenVPN UDP ਟਨਲ ਦੇ ਅੰਦਰ TCP ’ਤੇ NFS: ਦੋ ਟ੍ਰਾਂਸਪੋਰਟ

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

ਕੁਝ ਵੀ ਡੀਬੱਗ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਦੋਵੇਂ ਵੱਖਰੇ ਲਿਖੋ; ਇਹਨਾਂ ਘਟਨਾਵਾਂ ਵਿੱਚੋਂ ਬਹੁਤੀਆਂ ਤਦ ਸ਼ੁਰੂ ਹੁੰਦੀਆਂ ਹਨ ਜਦੋਂ ਕੋਈ ਗਲਤ ਪਰਤ ਬਦਲਦਾ ਹੈ।

ਦੋ ਪਰਤਾਂ, ਦੋ ਸੈਟਿੰਗਾਂ

ਮਾਊਂਟ ਚੋਣ proto=tcp ਦੱਸਦੀ ਹੈ ਕਿ NFS ਕਲਾਇੰਟ NFS ਸਰਵਰ ਨਾਲ ਕਿਵੇਂ ਗੱਲ ਕਰਦਾ ਹੈ। VPN ਪ੍ਰੋਫਾਈਲ ਦੀ proto udp ਸੈਟਿੰਗ ਦੱਸਦੀ ਹੈ ਕਿ ਟਨਲ ਦੇ ਸਿਰੇ ਇਨਕੈਪਸੁਲੇਟਿਡ ਪੈਕਟ ਕਿਵੇਂ ਬਦਲਦੇ ਹਨ। ਮਾਊਂਟ ਚੋਣ ਬਦਲਣ ਨਾਲ ਟਨਲ ਨਹੀਂ ਬਦਲਦੀ, ਅਤੇ ਟਨਲ ਦੀ ਆਵਾਜਾਈ ਬਦਲਣ ਨਾਲ ਉਹ ਨਹੀਂ ਬਦਲਦਾ ਜੋ NFS ਕਲਾਇੰਟ ਨੇ ਤੈਅ ਕੀਤਾ ਹੈ। fstab ਲਾਈਨ ਦੀ ਥਾਂ nfsstat -m ਨਾਲ ਪ੍ਰਭਾਵੀ ਮਾਊਂਟ ਚੋਣਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਅਤੇ VPN ਆਵਾਜਾਈ ਦੀ ਪੁਸ਼ਟੀ ਉਸੇ ਪ੍ਰੋਫਾਈਲ ਤੋਂ ਕਰੋ ਜੋ ਅਸਲ ਵਿੱਚ ਵਰਤੀ ਜਾ ਰਹੀ ਹੈ।

ਫਿਰ ਉਹਨਾਂ ਨੂੰ ਘਟਨਾ ਦੇ ਨੋਟ ਵਿੱਚ ਦੋ ਵੱਖਰੇ ਖੇਤਰਾਂ ਵਜੋਂ ਦਰਜ ਕਰੋ। ਦਿਖਣ ਵਾਲਾ ਸੁਧਾਰ ਤਦ ਹੀ ਲੱਭ ਸਕਦਾ ਹੈ ਜਦੋਂ ਨੋਟ ਦੱਸੇ ਕਿ ਕਿਹੜੀ ਪਰਤ ਬਦਲੀ।

ਬ੍ਰਾਊਜ਼ਿੰਗ ਬਲਕ ਰੀਡ ਨਹੀਂ ਹੈ

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

ਅਸਫਲ ਹੋ ਰਹੀ ਕਾਰਵਾਈ ਦਾ ਸਟੀਕ ਵਰਣਨ ਕਰੋ: ਰਾਹ, ਦਿਸ਼ਾ, ਰੁਕਾਵਟ ਦੀ ਲਗਭਗ ਥਾਂ, ਅਤੇ ਕਲਾਇੰਟ, ਸਰਵਰ ਅਤੇ VPN ਲੌਗਾਂ ਵਿੱਚ ਆਖਰੀ ਸੰਬੰਧਿਤ ਘਟਨਾ। ਫਿਰ ਤੁਲਨਾ ਕਰੋ ਕਿ ਟ੍ਰੈਫਿਕ ਕਿੱਥੇ ਚੱਲਦਾ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਕਿੱਥੇ ਰੁਕਦਾ ਹੈ।

MTU ਇੱਕ ਧਾਰਨਾ ਹੈ, ਨਿਦਾਨ ਨਹੀਂ

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

ਸਿਰਫ਼ ਟਾਈਮਆਉਟ ਇਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ ਕਿ UDP ਬਦਲਣਾ ਚਾਹੀਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਇਹ ਇੱਕ ਲੱਛਣ ਹੈ ਜਿਸਦੇ ਕਈ ਸੰਭਾਵੀ ਮਾਲਕ ਹਨ।

ਇੱਕ ਵਾਰ ਵਿੱਚ ਇੱਕ ਚਲ ਬਦਲੋ

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

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

ਜੋ ਪਰਤ ਅਸਫਲ ਹੋਈ ਉਸਨੂੰ ਪੜ੍ਹੋ

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

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