DD-WRT ਉੱਤੇ OpenVPN 2.5 ਲਿਸਨਰ ਮਰਿਆ? ਇਸ ਨੇ ਬਣਾਈ ਕਾਨਫਿਗ ਪੜ੍ਹੋ

DD-WRT ਉੱਤੇ ਮਰਿਆ ਲਿਸਨਰ ਆਮ ਤੌਰ ਉੱਤੇ ਇਹ ਦੱਸਦਾ ਹੈ ਕਿ ਡੈਮਨ ਆਪਣੀ ਕਾਨਫਿਗ ਪਾਰਸ ਕਰਦੇ ਹੋਏ ਬਾਹਰ ਨਿਕਲ ਗਿਆ, ਇਹ ਨਹੀਂ ਕਿ ਫਾਇਰਵਾਲ ਨਿਯਮ ਨੇ ਪੋਰਟ ਰੋਕਿਆ। OpenVPN 2.5 ਨੇ ਕਈ ਡਿਫਾਲਟ ਸਖ਼ਤ ਕੀਤੇ ਜਿਨ੍ਹਾਂ ਉੱਤੇ ਪੁਰਾਣੀਆਂ ਕਾਨਫਿਗ ਨਿਰਭਰ ਸਨ, ਅਤੇ ਪੁਰਾਣੇ ਬਿਲਡ ਉੱਤੇ ਚੱਲੀ ਬਣਾਈ ਕਾਨਫਿਗ ਸਾਕਟ ਖੁੱਲ੍ਹਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਰੱਦ ਹੋ ਸਕਦੀ ਹੈ। ਕਾਰਨ ਰਾਊਟਰ ਦੇ ਆਪਣੇ ਲਾਗ ਵਿੱਚ ਹੈ, ਅਤੇ ਇਨਪੁਟ ਬਣਾਈ ਫਾਈਲ ਵਿੱਚ ਹੈ। ਦੋਵੇਂ ਇਸੇ ਕ੍ਰਮ ਵਿੱਚ ਪੜ੍ਹਨਾ ਕਿਸੇ ਵੀ ਪੈਕਟ ਕੈਪਚਰ ਨਾਲੋਂ ਤੇਜ਼ ਹੈ।

ਡੈਮਨ ਫਾਇਰਵਾਲ ਨਹੀਂ ਹੈ

ਇਹ ਫ਼ਰਕ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਬਾਹਰੋਂ ਦੋਵੇਂ ਅਸਫਲਤਾਵਾਂ ਇੱਕੋ ਜਿਹੀਆਂ ਦਿਸਦੀਆਂ ਹਨ: ਕਲਾਇੰਟ ਹੈਂਡਸ਼ੇਕ ਭੇਜਦਾ ਹੈ ਅਤੇ ਕੁਝ ਵਾਪਸ ਨਹੀਂ ਆਉਂਦਾ। ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਚੱਲ ਰਹੀ ਨਹੀਂ, ਅਤੇ ਦੂਜੀ ਪ੍ਰਕਿਰਿਆ ਚੱਲ ਰਹੀ ਹੈ ਅਤੇ ਫਿਲਟਰ ਕਰ ਰਹੀ ਹੈ।

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

DD-WRT ਨੇ ਬਣਾਈ ਕਾਨਫਿਗ ਪੜ੍ਹੋ

DD-WRT ਵੈੱਬ ਇੰਟਰਫੇਸ ਵਿੱਚ ਟਾਈਪ ਕੀਤਾ ਟੈਕਸਟ OpenVPN ਨੂੰ ਨਹੀਂ ਦਿੰਦਾ। ਇਹ ਬਣਾਈ ਕਾਨਫਿਗ /tmp/openvpn/openvpn.conf ਵਿੱਚ ਲਿਖਦਾ ਹੈ ਅਤੇ ਉਸ ਫਾਈਲ ਨਾਲ ਡੈਮਨ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਇੰਟਰਫੇਸ ਦੇ ਖੇਤਰ ਅਤੇ Additional Config ਦਾ ਕੋਈ ਵੀ ਟੈਕਸਟ OpenVPN ਦੇ ਵੇਖਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਰਲ ਜਾਂਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਬਣਾਈ ਫਾਈਲ ਦੀ ਥਾਂ ਫਾਰਮ ਡੀਬਗ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਇਰਾਦਾ ਪੜ੍ਹ ਰਹੇ ਹੋ, ਅਸਲ ਇਨਪੁਟ ਨਹੀਂ। ਰੀਬੂਟ /tmp ਸਾਫ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਫਾਈਲ ਕਿਸੇ ਪੱਕੀ ਥਾਂ ਤੇ ਕਾਪੀ ਕਰੋ।

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

ਜੇ ਬਣਾਈ ਫਾਈਲ ਖਾਲੀ ਹੈ ਜਾਂ ਨਹੀਂ ਹੈ, ਤਾਂ ਡੈਮਨ ਸ਼ੁਰੂ ਹੋਣ ਤੱਕ ਵੀ ਨਹੀਂ ਪਹੁੰਚਿਆ, ਅਤੇ ਸਮੱਸਿਆ OpenVPN ਤੋਂ ਪਹਿਲਾਂ ਹੈ।

OpenVPN 2.5 ਨੇ ਕੀ ਸਵੀਕਾਰ ਕਰਨਾ ਬੰਦ ਕੀਤਾ

OpenVPN 2.5 ਨੇ ncp-ciphers ਨੂੰ data-ciphers ਨਾਲ ਬਦਲਿਆ, ਅਤੇ ਡਿਫਾਲਟ ਘੱਟੋ-ਘੱਟ TLS ਸੰਸਕਰਣ 1.2 ਕੀਤਾ। ਇਸ ਨੇ ਕੰਪ੍ਰੈਸ਼ਨ ਦੀ ਸੰਭਾਲ ਵੀ ਬਦਲੀ, ਜਿਸ ਨਾਲ ਕੰਪ੍ਰੈਸ਼ਨ ਪੇਸ਼ ਕਰਨ ਵਾਲਾ ਸਾਥੀ ਰੱਦ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜਦ ਤੱਕ ਕਾਨਫਿਗ ਸਪੱਸ਼ਟ ਰੂਪ ਵਿੱਚ ਆਗਿਆ ਨਾ ਦੇਵੇ, ਅਤੇ ns-cert-type ਵਰਗੇ ਪੁਰਾਣੇ ਵਿਕਲਪ ਨਾਵਾਂ ਨੂੰ remote-cert-tls ਦੇ ਹੱਕ ਵਿੱਚ ਪੁਰਾਣਾ ਘੋਸ਼ਿਤ ਕੀਤਾ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਹਰ ਬਦਲਾਅ ਪਹਿਲਾਂ ਚੱਲ ਰਹੀ ਕਾਨਫਿਗ ਨੂੰ ਪਾਰਸ ਜਾਂ ਗੱਲਬਾਤ ਦੀ ਅਸਫਲਤਾ ਬਣਾ ਦਿੰਦਾ ਹੈ।

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

ਲਾਗ ਵਿੱਚ ਪਹਿਲੀ ਗਲਤੀ ਪੜ੍ਹੋ, ਆਖ਼ਰੀ ਨਹੀਂ। ਪਾਰਸਿੰਗ ਪਹਿਲੇ ਖ਼ਰਾਬ ਨਿਰਦੇਸ਼ ਉੱਤੇ ਰੁਕ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਸਭ ਬੰਦ ਹੋਣ ਦਾ ਸ਼ੋਰ ਹੈ।

Broadcom-ਵਿਸ਼ੇਸ਼ ਪੂਰਵ-ਸ਼ਰਤਾਂ

Broadcom ਬਿਲਡ ਉੱਤੇ ਡੈਮਨ ਦੀ ਵਰਤੋਂ ਤੋਂ ਪਹਿਲਾਂ ਟਨਲ ਡਿਵਾਈਸ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਜਾਂਚੋ ਕਿ tun ਮਾਡਿਊਲ ਲੋਡ ਹੈ ਅਤੇ /dev/net/tun ਮੌਜੂਦ ਹੈ, ਕਿਉਂਕਿ ਡਿਵਾਈਸ ਨਾ ਹੋਣ ਨਾਲ ਅਜਿਹੀ ਸ਼ੁਰੂਆਤੀ ਅਸਫਲਤਾ ਹੁੰਦੀ ਹੈ ਜਿਸ ਦਾ ਸਰਟੀਫਿਕੇਟਾਂ ਨਾਲ ਕੋਈ ਸੰਬੰਧ ਨਹੀਂ। ਇਹੀ ਗੱਲ DD-WRT ਰੂਟ ਅਤੇ DNS ਲਈ ਬਣਾਉਂਦਾ ਹੈ ਉਹਨਾਂ ਸਹਾਇਕ ਸਕ੍ਰਿਪਟਾਂ ਲਈ ਵੀ ਲਾਗੂ ਹੈ: ਜੇ ਉਹ ਨਹੀਂ ਹਨ ਜਾਂ ਚਲਾਉਣ ਯੋਗ ਨਹੀਂ, ਤਾਂ ਡੈਮਨ ਸ਼ੁਰੂ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਆਪਣਾ ਸੈਟਅਪ ਪੂਰਾ ਨਹੀਂ ਕਰ ਸਕਦਾ।

ਜਦੋਂ ਅਸਲ ਸੁਨੇਹਾ ਚਾਹੀਦਾ ਹੋਵੇ ਤਾਂ ਬਣਾਈ ਕਾਨਫਿਗ ਉੱਤੇ ਵੱਧ ਵੇਰਵੇ ਨਾਲ ਡੈਮਨ ਨੂੰ ਫੋਰਗਰਾਊਂਡ ਵਿੱਚ ਚਲਾਓ। ਫੋਰਗਰਾਊਂਡ ਰਨ ਉਹ ਪਾਰਸ ਗਲਤੀ ਛਾਪਦਾ ਹੈ ਜੋ init ਸਕ੍ਰਿਪਟ ਨੇ ਨਿਗਲ ਲਈ ਸੀ।

ਫਿਰ ਆਮ ਸੇਵਾ ਬਹਾਲ ਕਰੋ, ਕਿਉਂਕਿ ਫੋਰਗਰਾਊਂਡ ਡੈਮਨ ਅਤੇ init ਸਕ੍ਰਿਪਟ ਪੋਰਟ ਲਈ ਲੜਨਗੇ।

ਕਲਾਇੰਟ ਡੀਬਗ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸਾਬਤ ਕਰੋ ਕਿ ਲਿਸਨਰ ਮੌਜੂਦ ਹੈ

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

ਕਲਾਇੰਟ ਪਾਸੇ ਦੀ ਡੀਬਗਿੰਗ ਲਿਸਨਰ ਮੌਜੂਦ ਹੋਣ ਤੋਂ ਬਾਅਦ ਹੀ ਅਰਥ ਰੱਖਦੀ ਹੈ। ਫਿਰ ਜਾਂਚੋ ਕਿ ਕਲਾਇੰਟ ਦਾ ਸਾਈਫਰ ਅਤੇ TLS ਸੈਟਿੰਗਾਂ ਸਰਵਰ ਦੀ data-ciphers ਸੂਚੀ ਅਤੇ ਘੱਟੋ-ਘੱਟ ਸੰਸਕਰਣ ਨਾਲ ਮੇਲ ਖਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਪੋਰਟ ਅਸਲ ਵਿੱਚ ਰਾਊਟਰ ਤੱਕ ਫਾਰਵਰਡ ਹੈ।

ਬਣਾਈ ਕਾਨਫਿਗ ਅਤੇ ਉਹ ਲਾਗ ਲਾਈਨ ਸੰਭਾਲੋ ਜਿਸ ਨੇ ਸੁਧਾਰ ਸਾਬਤ ਕੀਤਾ। ਅਗਲਾ ਫਰਮਵੇਅਰ ਅਪਡੇਟ ਡਿਫਾਲਟ ਫਿਰ ਬਦਲ ਸਕਦਾ ਹੈ, ਅਤੇ ਉਹੀ ਰਿਕਾਰਡ ਦੁਹਰਾਅ ਨੂੰ ਪੰਜ ਮਿੰਟ ਦੀ ਜਾਂਚ ਵਿੱਚ ਬਦਲਦਾ ਹੈ।