TLS OpenVPN ਦੇ ਅੰਦਰ ਕਿੱਥੇ ਬੈਠਦਾ ਹੈ ਅਤੇ ਆਕਾਰ ਕੀ ਬਦਲਦਾ ਹੈ
OpenVPN ਆਪਣੇ ਕੰਟਰੋਲ ਚੈਨਲ ਲਈ TLS ਆਪਣੀ ਫਰੇਮਿੰਗ ਦੇ ਅੰਦਰ ਚਲਾਉਂਦਾ ਹੈ, ਇਸ ਲਈ ਪਹਿਲੇ ਬਾਈਟ ਵੈੱਬ ਹੈਂਡਸ਼ੇਕ ਨਹੀਂ ਹਨ। ਤਿੰਨ ਵਿਕਲਪ ਸੱਚਮੁੱਚ ਬਦਲਦੇ ਹਨ ਕਿ ਕੀ ਦਿਸਦਾ ਹੈ।
OpenVPN ਸੱਚਮੁੱਚ TLS ਵਰਤਦਾ ਹੈ, ਅਤੇ ਲੋਕ ਇਸ ਨੂੰ ਨਿਯਮਿਤ ਤੌਰ ’ਤੇ ਉਸ ਦਾਅਵੇ ਤੱਕ ਵਧਾਉਂਦੇ ਹਨ ਜੋ ਇਹ ਚੁੱਕ ਨਹੀਂ ਸਕਦਾ: ਕਿ ਟਨਲ ਇਸ ਲਈ ਕਿਸੇ ਸਾਈਟ ਨੂੰ ਮਿਲਣ ਵਾਲੇ ਬ੍ਰਾਊਜ਼ਰ ਵਰਗੀ ਦਿਸਦੀ ਹੈ। ਪਹਿਲਾ ਹਿੱਸਾ ਸੱਚ ਹੈ। ਦੂਜਾ ਨਹੀਂ। ਇੱਥੇ TLS ਉਸ ਕੰਟਰੋਲ ਚੈਨਲ ਦਾ ਹੈ ਜੋ OpenVPN ਦੇ ਆਪਣੇ ਕੰਟੇਨਰ ਦੇ ਅੰਦਰ ਸਫ਼ਰ ਕਰਦਾ ਹੈ, ਇਸ ਦੇ ਨਾਲ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੱਖਰੀ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ ਵਾਲਾ ਪੇਲੋਡ ਚੈਨਲ ਹੈ, ਇਸ ਲਈ ਜੋ ਖੁੱਲ੍ਹਣ ਵਾਲੇ ਬਾਈਟ ਜਾਂਚਦਾ ਹੈ ਉਹ OpenVPN ਦੇਖਦਾ ਹੈ।
ਇੱਕ ਲਿਫ਼ਾਫ਼ੇ ਵਿੱਚ ਦੋ ਗੱਲਬਾਤਾਂ
ਕਿਸੇ ਸੈਸ਼ਨ ਨੂੰ ਇੱਕ ਲਿਫ਼ਾਫ਼ਾ ਸਾਂਝਾ ਕਰਦੀਆਂ ਦੋ ਗੱਲਬਾਤਾਂ ਸਮਝੋ। ਇੱਕ ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦੀ ਹੈ ਅਤੇ ਕੁੰਜੀ ਸਮੱਗਰੀ ਕੱਢਦੀ ਹੈ। ਦੂਜੀ ਉਹ ਐਨਕ੍ਰਿਪਟ ਕਰਦੀ ਹੈ ਜੋ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਭੇਜ ਰਹੇ ਹੋ, ਪਹਿਲੀ ਦੇ ਪੈਦਾ ਕੀਤੇ ਨਾਲ।
ਲਿਫ਼ਾਫ਼ਾ ਹੀ ਪ੍ਰੋਟੋਕੋਲ ਹੈ। ਹਰ ਪੈਕਟ ਆਪਣੀ ਕਿਸਮ ਦੱਸਦੇ ਛੋਟੇ ਹੈਡਰ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਉਹ ਹੈਡਰ ਬਾਕੀ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਆਉਂਦਾ ਹੈ।
ਅਸਲ ਵਿੱਚ ਪਹਿਲਾਂ ਕੀ ਆਉਂਦਾ ਹੈ
ਇਸ ਕ੍ਰਮ ਕਾਰਨ ਤਾਰ ਉੱਤੇ ਪਹਿਲੀ ਚੀਜ਼ TLS ਰਿਕਾਰਡ ਨਹੀਂ ਹੈ। ਉਹ OpenVPN ਦਾ ਹੈਡਰ ਹੈ, ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਹੈਡਰ ਜਿਸ ਚੈਨਲ ਦਾ ਐਲਾਨ ਕਰਦਾ ਹੈ ਉਸ ਦੀ ਸਮੱਗਰੀ ਆਉਂਦੀ ਹੈ। ਉੱਥੇ ਇੱਕ ClientHello ਮੌਜੂਦ ਹੈ, ਬੱਸ ਸਿਫ਼ਰ ਬਾਈਟ ਉੱਤੇ ਨਹੀਂ। ਫ਼ਰਕ ਵੇਖਣ ਲਈ ਕੋਈ ਡੀਕ੍ਰਿਪਸ਼ਨ ਲੋੜੀਂਦੀ ਨਹੀਂ, ਕਿਉਂਕਿ ਆਕਾਰ ਆਪਣੇ ਆਪ ਹੀ ਇਸ ਨੂੰ ਜ਼ਾਹਰ ਕਰ ਦਿੰਦਾ ਹੈ।
ਡਿਫ਼ਾਲਟ ਵੀ ਇੱਥੇ ਮਹੱਤਵਪੂਰਨ ਹਨ। ਪ੍ਰਵਾਹ UDP ਰਾਹੀਂ 1194 ਵੱਲ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਪ੍ਰੋਫ਼ਾਈਲ TCP ਨਾ ਚੁਣੇ। ਦੋਵਾਂ ਹਾਲਤਾਂ ਵਿੱਚ ਬਾਹਰੀ ਰੂਪ ਟਨਲ ਹੈ, ਵੈੱਬ ਬੇਨਤੀ ਨਹੀਂ।
ਆਕਾਰ ਬਦਲਣ ਦੇ ਤਿੰਨ ਇਮਾਨਦਾਰ ਤਰੀਕੇ
stunnel ਵਰਗਾ TLS ਟਰਮੀਨੇਟਰ ਦੋਵੇਂ ਸਿਰਿਆਂ ਉੱਤੇ ਇੱਕ ਪੋਰਟ ਉੱਤੇ TLS ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਅਤੇ ਡੀਕ੍ਰਿਪਟ ਕੀਤਾ ਪ੍ਰਵਾਹ ਸਥਾਨਕ ਤੌਰ ’ਤੇ OpenVPN ਨੂੰ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਨੈੱਟਵਰਕ ਉਸ ਪੋਰਟ ਵੱਲ TLS ਦੇਖਦਾ ਹੈ। ਜੋ ਪ੍ਰੋਟੋਕੋਲ ਪਹਿਲੇ ਬਾਈਟ ਤੋਂ ਹੀ TLS ਹੈ ਉਹ ਹੋਰ ਵੱਖਰਾ ਵਿਵਹਾਰ ਕਰਦਾ ਹੈ: ocserv ਵੱਲੋਂ ਲਾਗੂ AnyConnect-ਅਨੁਕੂਲ ਅਦਲਾ-ਬਦਲੀ ਉਸ ਕਾਰਪੋਰੇਟ ਦੂਰਸਥ ਪਹੁੰਚ ਵਰਗੀ ਲੱਗਦੀ ਹੈ ਜਿਸ ਦੀ ਕਈ ਨੈੱਟਵਰਕ ਪਹਿਲਾਂ ਹੀ ਉਮੀਦ ਕਰਦੇ ਹਨ। Windows ਨਾਲ ਆਉਣ ਵਾਲਾ SSTP ਕਿਸੇ ਹੋਰ ਉਤਪਾਦ ਵਿੱਚ ਇਹੀ ਗੁਣ ਰੱਖਦਾ ਹੈ।
Linux ਉੱਤੇ, SSH ਦਾ -w ਵਿਕਲਪ SSH ਸੈਸ਼ਨ ਦੇ ਅੰਦਰ ਬਿੰਦੂ-ਤੋਂ-ਬਿੰਦੂ ਲਿੰਕ ਲੈ ਕੇ ਜਾਂਦਾ ਹੈ, ਜੋ ਉਦੋਂ ਲਾਹੇਵੰਦ ਹੈ ਜਦੋਂ SSH ਹੀ ਇਕੱਲਾ ਮਨਜ਼ੂਰ ਪ੍ਰੋਟੋਕੋਲ ਹੋਵੇ। ਜੇ SSH ਉਸ ਨੈੱਟਵਰਕ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਕੰਮ ਕਰਦਾ ਹੈ ਤਾਂ ਇਹ ਚਾਰਾਂ ਵਿੱਚੋਂ ਸਭ ਤੋਂ ਸਸਤਾ ਹੈ, ਅਤੇ ਨਾ ਕਰੇ ਤਾਂ ਸਭ ਤੋਂ ਘੱਟ ਲਾਹੇਵੰਦ।
ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਜੋ ਨਹੀਂ ਬਦਲਦਾ
ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਇਹ ਨਹੀਂ ਬਦਲਦਾ ਕਿ ਟਨਲ ਕਿੱਥੋਂ ਤੱਕ ਪਹੁੰਚ ਸਕਦੀ ਹੈ। ਉਹ ਰੋਕੇ ਹੋਏ ਪਤੇ ਨੂੰ ਪਹੁੰਚਯੋਗ ਨਹੀਂ ਬਣਾਉਂਦੇ, ਕਿਸੇ ਦੀ ਪ੍ਰਮਾਣਿਕਤਾ ਨਹੀਂ ਜਾਂਚਦੇ ਅਤੇ ਰੂਟ ਤੈਅ ਨਹੀਂ ਕਰਦੇ।
ਲਪੇਟਾ ਤੁਹਾਨੂੰ ਇੱਕ ਹਿੱਸੇ ਦਾ ਵੀ ਖ਼ਰਚ ਕਰਵਾਉਂਦਾ ਹੈ। ਦੋ ਸਰੋਤੇ ਅਤੇ ਦੋ ਕਨਫ਼ੀਗਰੇਸ਼ਨ ਫ਼ਾਈਲਾਂ ਭਾਵ ਅਸਫ਼ਲਤਾ ਦੀਆਂ ਦੋ ਥਾਵਾਂ, ਅਤੇ ਦੋਵੇਂ ਵਰਤੋਂਕਾਰ ਦੀ ਸੀਟ ਤੋਂ ਇੱਕੋ ਜਿਹੀਆਂ ਦਿਸਦੀਆਂ ਹਨ। ਇੱਕ ਅਪਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਇਸ ਦਾ ਬਜਟ ਰੱਖੋ। ਸੈਸ਼ਨ ਇੱਕ ਮੰਜ਼ਿਲ ਵੱਲ ਇੱਕ ਹੀ ਲੰਮੇ ਸਮੇਂ ਦਾ ਐਨਕ੍ਰਿਪਟਿਡ ਪ੍ਰਵਾਹ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਇਸ ਦਾ ਆਕਾਰ ਤੇ ਸਮਾਂ ਦਿਸਦਾ ਰਹਿੰਦਾ ਹੈ।
ਪਹਿਲਾਂ ਨਿਦਾਨ ਕਰੋ, ਫਿਰ ਚੁਣੋ
ਇਸ ਲਈ ਪਹਿਲਾਂ ਨਿਦਾਨ ਕਰੋ। ਡਿੱਗੇ UDP ਦਾ ਜਵਾਬ TCP ਮੋਡ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਪਛਾਣੇ ਹਸਤਾਖ਼ਰ ਦਾ ਜਵਾਬ ਹੋਰ ਪ੍ਰੋਟੋਕੋਲ ਜਾਂ ਲਪੇਟਾ ਦਿੰਦਾ ਹੈ। ਰੋਕ ਜਾਣਨ ਤੋਂ ਪਹਿਲਾਂ ਸੰਦ ਚੁਣਨਾ ਹੀ ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਲੋਕ ਅੰਤ ਵਿੱਚ ਤਿੰਨ ਪਰਤਾਂ ਸੰਭਾਲਦੇ ਹਨ ਜੋ ਸਭ ਇੱਕੋ ਕਾਰਨ ਨਾਲ ਫ਼ੇਲ ਹੁੰਦੀਆਂ ਹਨ।
ਸਿਰਫ਼ ਵੈੱਬ ਪੋਰਟਾਂ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣ ਵਾਲਾ ਨੈੱਟਵਰਕ ਚੋਣ ਨੂੰ 443 ਉੱਤੇ TLS-ਅਧਾਰਿਤ ਪ੍ਰੋਟੋਕੋਲ ਤੱਕ ਸੀਮਤ ਕਰਦਾ ਹੈ। ਤਿੰਨੇ ਇਕੱਠੇ ਲਾਗੂ ਕਰਨ ਨਾਲ ਅਜਿਹਾ ਸਟੈਕ ਬਣਦਾ ਹੈ ਜਿਸ ਨੂੰ ਕੋਈ ਡੀਬੱਗ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਇਸ ਲਈ ਇੱਕ ਚੀਜ਼ ਬਦਲੋ ਅਤੇ ਉਹੀ ਪ੍ਰਵਾਹ ਦੁਬਾਰਾ ਜਾਂਚੋ।
ਜੇ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਲਾਗੂ ਨਾ ਹੋਵੇ, ਤਾਂ ਸਹੀ ਜਵਾਬ ਹੈ ਕਿ ਇਹ ਨੈੱਟਵਰਕ ਤੁਹਾਡੇ ਲਈ ਟਨਲ ਨਹੀਂ ਢੋਵੇਗਾ। ਇਹ ਕੋਸ਼ਿਸ਼ ਦੀ ਅਸਫ਼ਲਤਾ ਨਹੀਂ ਸਗੋਂ ਇੱਕ ਖੋਜ ਹੈ। ਵਧੇਰੇ ਵਿਕਲਪਾਂ ਵਿੱਚੋਂ ਲੰਘਣਾ ਉੱਪਰ ਲਏ ਨੀਤੀ ਫ਼ੈਸਲੇ ਨੂੰ ਉਲਟਾਉਂਦਾ ਨਹੀਂ।
ਇਨ੍ਹਾਂ ਸਭ ਦੇ ਸਾਹਮਣੇ ਇੱਕ ਹੱਦ ਖੜ੍ਹੀ ਹੈ। ਕਿਸੇ ਹੋਰ ਦੇ ਨੈੱਟਵਰਕ ਉੱਤੇ ਟਨਲ ਚਲਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਨੀਤੀ ਦਾ ਮਾਮਲਾ ਹੈ, ਜੋ ਇਸ ਤੋਂ ਵੱਖਰਾ ਤੈਅ ਹੁੰਦਾ ਹੈ ਕਿ ਕਾਰਜਵਿਧੀ ਕੰਮ ਕਰਦੀ ਹੈ ਜਾਂ ਨਹੀਂ। ਇਹ ਤੱਥ ਦੱਸਦੇ ਹਨ ਕਿ ਨਿਰੀਖਕ ਕੀ ਦੇਖਦਾ ਹੈ, ਅਤੇ ਉਹ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੰਦੇ।