ਕਾਰਪੋਰੇਟ VPN 'ਤੇ ਕੰਟੇਨਰ HTTPS ਅਟਕਦਾ ਹੈ? DTLS ਲੱਤ ਦੀ ਜਾਂਚ ਕਰੋ

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

ਦੋ ਟਰਾਂਸਪੋਰਟ, ਇੱਕ ਉਲਝਾਉਣ ਵਾਲਾ ਲੱਛਣ

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

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

ਅਨੁਭਵ ਨਾਲ ਨਹੀਂ, ਪ੍ਰਯੋਗ ਨਾਲ ਫੈਸਲਾ ਕਰੋ

ਸਭ ਤੋਂ ਸਸਤਾ ਪ੍ਰਯੋਗ UDP ਡੇਟਾ ਚੈਨਲ ਬੰਦ ਕਰਦਾ ਹੈ ਅਤੇ ਬੇਨਤੀ ਦੁਹਰਾਉਂਦਾ ਹੈ। ਡੈਸਕਟਾਪ ਰੈਪਰ ਦੀ ਥਾਂ ਕਮਾਂਡ-ਲਾਈਨ ਕਲਾਇੰਟ ਵਰਤੋ, ਤਾਂ ਜੋ ਫਲੈਗ ਸੱਚਮੁੱਚ ਲਾਗੂ ਹੋਵੇ: openconnect vpn.example.net --user=you --interface=tun0 --no-dtls. ਜੇ ਅਟਕੀ ਹੋਈ ਬੇਨਤੀ ਹੁਣ ਪੂਰੀ ਹੁੰਦੀ ਹੈ, ਤਾਂ DTLS ਲੱਤ ਹੀ ਸਮੱਸਿਆ ਸੀ ਅਤੇ ਬਾਕੀ ਸ਼ੋਰ ਸੀ।

ਇੱਕ ਹੀ ਕੰਟੇਨਰ ਤੋਂ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਨਤੀਜਾ ਪੁਸ਼ਟ ਕਰੋ: ਫਲੈਗ ਨਾਲ ਇੱਕ ਵੱਡੀ ਬੇਨਤੀ ਅਤੇ ਬਿਨਾਂ ਇੱਕ। ਫਲੈਗ ਦਾ ਪਿੱਛਾ ਕਰਨ ਵਾਲਾ ਵਿਵਹਾਰ ਬਦਲਾਅ ਸਬੂਤ ਹੈ; ਅੰਤ ਵਿੱਚ ਲੋਡ ਹੋਣ ਵਾਲਾ ਪੰਨਾ ਸਬੂਤ ਨਹੀਂ।

ਜੇ ਫਲੈਗ ਇਸਨੂੰ ਠੀਕ ਕਰਦਾ ਹੈ, ਤਾਂ ਕਿਉਂ ਫੈਸਲਾ ਕਰੋ

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

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

ਵਰਕਅਰਾਊਂਡ ਰੱਖਣ ਤੋਂ ਪਹਿਲਾਂ ਪੈਕਟ ਆਕਾਰ ਜਾਂਚੋ

ਜੇ ਕਾਰਨ ਆਕਾਰ ਹੈ, ਤਾਂ ਟਨਲ ਇੰਟਰਫੇਸ ਅਜਿਹੇ ਪੈਕਟ ਸਵੀਕਾਰਦਾ ਹੈ ਜੋ ਰਾਹ ਚੁੱਕ ਨਹੀਂ ਸਕਦਾ, ਅਤੇ ਪੇਲੋਡ ਵਧਦਿਆਂ ਹੀ ਸਮੱਸਿਆ ਕਿਸੇ ਵੀ ਟਰਾਂਸਪੋਰਟ 'ਤੇ ਮੁੜ ਆਉਂਦੀ ਹੈ। ਇੰਟਰਫੇਸਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ: ਹੋਸਟ 'ਤੇ ip link show tun0, ਫਿਰ ਨੈੱਟਵਰਕ ਵਿਕਲਪਾਂ ਵਿੱਚ ਦਰਜ MTU ਪੜ੍ਹਨ ਲਈ docker network inspect bridge. ਘੱਟ ਚੁੱਕਣ ਵਾਲੀ ਟਨਲ ਹੇਠਾਂ ਅਜੇ ਵੀ 1500 ਬਾਈਟ 'ਤੇ ਖੜ੍ਹਾ ਕੰਟੇਨਰ ਬ੍ਰਿਜ ਆਮ ਖੋਜ ਹੈ।

ਟਨਲ ਦੇ ਅੰਦਰ ਵਿਭਾਜਨ-ਨਿਖੇਧ ਜਾਂਚ ਨਾਲ ਜਾਣੇ-ਪਛਾਣੇ ਚੰਗੇ ਆਕਾਰ ਤੋਂ ਉੱਪਰ ਖੋਜੋ, ਫਿਰ ਕੰਟੇਨਰ ਨੈੱਟਵਰਕ ਦਾ MTU ਘਟਾਓ ਜਾਂ ਟਨਲ 'ਤੇ TCP MSS ਕਲੈਂਪ ਕਰੋ। ਦੋਹਾਂ ਸੁਧਾਰਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਅਕਸਰ UDP ਰਾਹ ਨੂੰ ਦੁਬਾਰਾ ਵਰਤੋਂਯੋਗ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਫਲੈਗ ਦੀ ਲੋੜ ਹਟਾਉਂਦਾ ਹੈ, ਜੋ ਫਿਲਟਰਿੰਗ ਕਾਰਨ ਨਾ ਹੋਣ 'ਤੇ ਬਿਹਤਰ ਨਤੀਜਾ ਹੈ।

ਤੁਸੀਂ ਕੀ ਬਦਲਣ ਲਈ ਤਿਆਰ ਹੋ, ਫੈਸਲਾ ਕਰੋ

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

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