TUN/TAP: ਅਵੈਧ ਆਰਗਿਊਮੈਂਟ — OpenVPN ਫਰੇਮਿੰਗ ਦਾ ਮੇਲ ਨਹੀਂ

ਕਲਾਇੰਟ ਪ੍ਰਮਾਣਿਕਤਾ ਕਰਦਾ ਹੈ, ਲੌਗ ਕਹਿੰਦਾ ਹੈ ਜੁੜ ਗਿਆ, ਅਤੇ ਕੋਈ ਵੀ ਪੈਕਟ ਟਨਲ ਪਾਰ ਨਹੀਂ ਕਰਦਾ। ਸਰਵਰ write to TUN/TAP: Invalid argument (code=22) ਨਾਲ ਕੋਸ਼ਿਸ਼ ਖ਼ਤਮ ਕਰਦਾ ਹੈ, ਜੋ ਡਰਾਈਵਰ ਦੀ ਖਰਾਬੀ ਵਾਂਗ ਲੱਗਦਾ ਹੈ ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਨਹੀਂ ਹੁੰਦਾ। ਰਾਊਟਰਾਂ ਅਤੇ ਛੋਟੇ Linux ਸਰਵਰਾਂ 'ਤੇ ਉਹ ਲਾਈਨ ਆਮ ਤੌਰ 'ਤੇ ਦਰਸਾਉਂਦੀ ਹੈ ਕਿ ਦੋਵੇਂ ਸਿਰੇ ਇਸ ਗੱਲ 'ਤੇ ਸਹਿਮਤ ਨਹੀਂ ਕਿ ਡੇਟਾ-ਪੈਕਟ ਕਿਵੇਂ ਫਰੇਮ ਕੀਤੇ ਜਾਣ, ਇਸ ਲਈ ਕਰਨਲ ਆਪਣੇ ਦਿੱਤੇ ਡੀਕ੍ਰਿਪਟ ਕੀਤੇ ਬਫਰ ਨੂੰ ਅਸਵੀਕਾਰ ਕਰਦਾ ਹੈ। ਉਸ ਸਮੇਂ ਰਾਊਟਿੰਗ ਦੀ ਜਾਂਚ ਨਹੀਂ ਹੋਈ।

ਸਹੀ ਰਾਊਟਿੰਗ ਟੇਬਲ ਅਤੇ ਟੁੱਟਿਆ ਫਰੇਮਿੰਗ ਸਮਝੌਤਾ ਕਲਾਇੰਟ ਵੱਲੋਂ ਇੱਕੋ ਜਿਹੇ ਦਿਖਦੇ ਹਨ: ਜੁੜਿਆ ਹੋਇਆ, ਅਤੇ ਕੁਝ ਵੀ ਕੰਮ ਨਹੀਂ ਕਰਦਾ।

ਟਨਲ ਉੱਪਰ ਆਉਂਦੀ ਹੈ ਅਤੇ ਇਸ ਨੂੰ ਕੋਈ ਪਾਰ ਨਹੀਂ ਕਰਦਾ

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

ਪਹਿਲੀ ਗਲਤੀ ਦੀ ਬਜਾਏ ਡੇਟਾ-ਚੈਨਲ ਸੈੱਟਅੱਪ ਦੇ ਆਸ-ਪਾਸ ਦਾ ਲੌਗ ਪੜ੍ਹੋ। ਸਹਿਮਤ ਕੰਪਰੈਸ਼ਨ ਮੋਡ, dev ਕਿਸਮ ਅਤੇ ਪੁਸ਼ ਕੀਤੇ ਵਿਕਲਪ ਸਭ ਵੱਧ ਵਰਬੋਸਿਟੀ 'ਤੇ ਦਿਖਦੇ ਹਨ, ਅਤੇ ਉਹ ਦੱਸਦੇ ਹਨ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਤਿੰਨਾਂ ਵਿੱਚੋਂ ਕਿਹੜੀ ਅਸੰਗਤੀ ਹੈ।

ਕੰਪਰੈਸ਼ਨ ਫਰੇਮਿੰਗ ਹੈ, ਬੈਂਡਵਿਡਥ ਨਹੀਂ

ਜਦੋਂ ਕੰਪਰੈਸ਼ਨ ਚਾਲੂ ਹੁੰਦਾ ਹੈ, ਹਰ ਡੇਟਾ-ਪੈਕਟ ਇੱਕ ਹੈਡਰ ਲੈ ਕੇ ਜਾਂਦਾ ਹੈ ਜੋ ਦੱਸਦਾ ਹੈ ਕਿ ਇਹ ਕਿਵੇਂ ਐਨਕੋਡ ਕੀਤਾ ਗਿਆ, ਅਤੇ ਦੋਵੇਂ ਸਿਰਿਆਂ ਨੂੰ ਉਸ ਹੈਡਰ 'ਤੇ ਸਹਿਮਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਪੁਰਾਣੇ ਨਮੂਨਾ ਕਾਨਫਿਗਰੇਸ਼ਨ ਤੋਂ ਅਜੇ ਵੀ comp-lzo ਲੈ ਕੇ ਜਾਣ ਵਾਲਾ ਸਰਵਰ, ਕੰਪਰੈਸ਼ਨ ਲਾਈਨ ਤੋਂ ਬਿਨਾਂ ਕਲਾਇੰਟ ਨਾਲ ਜੋੜਿਆ ਜਾਣ 'ਤੇ ਠੀਕ ਇਹੀ ਗਲਤੀ ਪੈਦਾ ਕਰਦਾ ਹੈ: ਸਰਵਰ ਅਜਿਹੇ ਹੈਡਰ ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ ਜੋ ਕਲਾਇੰਟ ਨੇ ਕਦੇ ਨਹੀਂ ਲਿਖਿਆ। comp-lzo ਨੂੰ compress lz4-v2 ਨਾਲ ਮਿਲਾਉਣਾ ਵੀ ਉਸੇ ਤਰ੍ਹਾਂ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਦੋਵਾਂ ਨੂੰ ਕੰਪਰੈਸ਼ਨ ਕਿਹਾ ਜਾਂਦਾ ਹੈ ਪਰ ਐਲਗੋਰਿਦਮ ਵੱਖਰੇ ਹਨ। ਆਧੁਨਿਕ ਲਿੰਕਾਂ 'ਤੇ ਵਿਕਲਪ ਬੈਂਡਵਿਡਥ ਸੁਵਿਧਾ ਨਹੀਂ, ਫਰੇਮਿੰਗ ਸਮਝੌਤਾ ਹੈ।

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

ਦੋਵੇਂ ਸਿਰੇ ਮਿਲਾਓ ਜਾਂ ਦੋਵਾਂ ਵਿੱਚੋਂ ਹਟਾਓ

ਹਰ ਕੰਪਰੈਸ਼ਨ ਨਿਰਦੇਸ਼ ਗਿਣੋ: ਸਰਵਰ ਫਾਈਲ, ਕੋਈ ਵੀ ਪੁਸ਼ ਕੀਤੇ ਵਿਕਲਪ, ਕਲਾਇੰਟ-ਖਾਸ ਫਾਈਲਾਂ ਅਤੇ ਕਲਾਇੰਟ ਪ੍ਰੋਫਾਈਲ। ਸਰਵਰ 'ਤੇ comp-lzo ਲਈ ਕਲਾਇੰਟ 'ਤੇ ਵੀ ਉਹੀ ਸ਼ਬਦ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ adaptive ਉਹ ਪੁਰਾਣਾ ਡਿਫੌਲਟ ਹੈ ਜੋ ਪੁਰਾਣੀਆਂ ਬਿਲਡਾਂ ਵਿੱਚ ਨੰਗਾ ਵਿਕਲਪ ਆਮ ਤੌਰ 'ਤੇ ਦਰਸਾਉਂਦਾ ਹੈ। LZO ਜਾਂ ਕੰਪਰੈਸ਼ਨ ਲੇਬਲ ਵਾਲਾ ਰਾਊਟਰ ਦਾ GUI ਸਵਿੱਚ ਵੀ ਉਹੀ ਵਿਕਲਪ ਲਿਖਦਾ ਹੈ, ਇਸ ਲਈ ਐਲਗੋਰਿਦਮ ਮਿਲਾਉਣ ਦੀ ਬਜਾਏ ਮੇਲ ਖਾਣ ਲਈ ਸੈੱਟ ਕਰੋ। ਇਹ ਨਾ ਮੰਨੋ ਕਿ ਮਿਲਦਾ-ਜੁਲਦਾ ਨਾਮ ਅਨੁਕੂਲ ਹੈ।

ਜੇ ਕੰਪਰੈਸ਼ਨ ਨਹੀਂ ਚਾਹੀਦਾ, ਤਾਂ ਇਸ ਨੂੰ ਦੋਵੇਂ ਸਿਰਿਆਂ ਤੋਂ ਜਾਣ-ਬੁੱਝ ਕੇ ਹਟਾਓ। ਸਰਵਰ 'ਤੇ allow-compression no ਕੰਪ੍ਰੈਸਡ ਪੈਕਟ ਅਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਪਰ ਸਿਰਫ਼ ਉਦੋਂ ਹੀ ਜਦੋਂ ਕਲਾਇੰਟ ਉਹਨਾਂ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਨੀ ਬੰਦ ਕਰ ਦੇਣ; ਕਿਸੇ ਕਲਾਇੰਟ ਵੱਲੋਂ ਅਜੇ ਵੀ ਕੰਪਰੈਸ਼ਨ ਭੇਜੇ ਜਾਣ ਸਮੇਂ ਇਸਨੂੰ ਲਾਗੂ ਕਰਨ ਨਾਲ ਦੂਜੀ ਦਿਸ਼ਾ ਵਿੱਚ ਅਸੰਗਤੀ ਦੁਬਾਰਾ ਬਣਦੀ ਹੈ।

ਪੁਸ਼ ਅਤੇ ਡਿਵਾਈਸ ਦੀ ਕਿਸਮ ਜਾਂਚੋ

ਸਰਵਰ ਆਪਣੀ ਮੁੱਖ ਫਾਈਲ ਜਾਂ ਕਲਾਇੰਟ-ਖਾਸ ਫਾਈਲ ਤੋਂ ਕੰਪਰੈਸ਼ਨ ਨਿਰਦੇਸ਼ ਪੁਸ਼ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ pull-filter ਨਾਲ ਪੁਸ਼ ਕੀਤੇ ਵਿਕਲਪ ਛੱਡ ਸਕਦਾ ਹੈ। ਵਰਬੋਸਿਟੀ 4 'ਤੇ ਇੱਕ ਕਲਾਇੰਟ ਜੋੜੋ, ਸਰਵਰ ਨੇ ਜੋ ਐਲਾਨਿਆ ਉਸ ਦੀ ਕਲਾਇੰਟ ਨੇ ਜੋ ਸਵੀਕਾਰ ਕੀਤਾ ਨਾਲ ਤੁਲਨਾ ਕਰੋ, ਫਿਰ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਕਿਸੇ ਫਿਲਟਰ ਨੇ ਇਸ ਨੂੰ ਨਹੀਂ ਹਟਾਇਆ। ਜੇ ਦੋਵੇਂ ਧਿਰਾਂ ਹੁਣ ਸਹਿਮਤ ਹਨ ਅਤੇ ਗਲਤੀ ਬਾਕੀ ਹੈ, ਤਾਂ ਡਿਵਾਈਸ ਦੀ ਕਿਸਮ ਦੇਖੋ: ਇੱਕ ਸਿਰੇ 'ਤੇ dev tap ਅਤੇ ਦੂਜੇ 'ਤੇ dev tun ਫਰੇਮਾਂ ਦਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਅਤੇ ਕਰਨਲ ਵੀ ਉਸੇ ਤਰ੍ਹਾਂ ਲਿਖਣ ਤੋਂ ਇਨਕਾਰ ਕਰਦਾ ਹੈ।

ਬ੍ਰਿਜ ਵਾਲੀ TAP ਤੈਨਾਤੀ ਲਈ ਸਰਵਰ 'ਤੇ ਅਸਲ ਬ੍ਰਿਜ ਚਾਹੀਦਾ ਹੈ, ਸਿਰਫ਼ ਵੱਖਰਾ ਡਿਵਾਈਸ ਨਾਮ ਨਹੀਂ। ਇੰਟਰਫੇਸ ਨੂੰ ਬ੍ਰਿਜ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤੇ ਬਿਨਾਂ tap0 ਨਾਮ ਦੇਣ ਨਾਲ ਅਜਿਹੀ ਡਿਵਾਈਸ ਬਣਦੀ ਹੈ ਜੋ ਲਿਖਣਾ ਸਵੀਕਾਰ ਕਰਦੀ ਹੈ ਅਤੇ ਕਿਤੇ ਨਹੀਂ ਜਾਂਦੀ।

ਫਿਰ ਇੱਕ ਕਲਾਇੰਟ ਅਤੇ ਇੱਕ ਮੰਜ਼ਿਲ ਨਾਲ ਤਸਦੀਕ ਕਰੋ: ਸਰਵਰ ਦੇ ਟਨਲ ਪਤੇ 'ਤੇ ਪਿੰਗ ਕਰੋ, ਫਿਰ ਇਸ ਦੇ LAN 'ਤੇ ਕਿਸੇ ਹੋਸਟ 'ਤੇ। ਪਹਿਲਾ ਡੇਟਾ-ਚੈਨਲ ਸਾਬਤ ਕਰਦਾ ਹੈ ਅਤੇ ਦੂਜਾ ਫਾਰਵਰਡਿੰਗ।