OpenVPN iroute ਬਨਾਮ ਕਰਨਲ ਰੂਟ: ਕਿਹੜਾ ਗੁੰਮ ਹੈ?

10.77.20.0/24 ਲਈ ਪੈਕੇਟ OpenVPN ਸਰਵਰ ’ਤੇ ਦੋ ਵੱਖਰੇ ਫੈਸਲੇ ਲੈਂਦਾ ਹੈ: ਆਪਰੇਟਿੰਗ ਸਿਸਟਮ ਨੂੰ ਇਸ ਨੂੰ VPN ਇੰਟਰਫੇਸ ਨੂੰ ਦੇਣਾ ਪੈਂਦਾ ਹੈ, ਅਤੇ OpenVPN ਨੂੰ ਜਾਣਨਾ ਪੈਂਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਜੁੜਿਆ ਕਲਾਇੰਟ ਉਸ ਪ੍ਰੀਫਿਕਸ ਦਾ ਮਾਲਕ ਹੈ। ਕਰਨਲ ਰੂਟ ਨਾ ਹੋਣ ’ਤੇ ਪੈਕੇਟ ਟਨਲ ਤੋਂ ਪਹਿਲਾਂ ਡਿੱਗਦਾ ਹੈ, ਅਤੇ ਪੀਅਰ ਰੂਟ ਨਾ ਹੋਣ ’ਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਡਿੱਗਦਾ ਹੈ। ਦੋਵੇਂ ਅਸਫਲਤਾਵਾਂ ਦੂਰ ਦੇ LAN ਤੋਂ ਇੱਕੋ ਜਿਹੀਆਂ ਦਿਸਦੀਆਂ ਹਨ, ਅਤੇ ਤੁਹਾਡੇ ਕੋਲ ਕਿਹੜੀ ਹੈ ਇਹ ਪਤਾ ਕਰਨ ਲਈ ਹਰ ਪਾਸੇ ਇੱਕ ਕਮਾਂਡ ਲੱਗਦੀ ਹੈ।

ਕਲਾਸਿਕ ਯੂਜ਼ਰਸਪੇਸ ਡੇਟਾ ਰਸਤੇ ਵਿੱਚ ਕਰਨਲ ਰੂਟ ਪੈਕੇਟ ਨੂੰ ਟਨਲ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਲੈ ਜਾਂਦਾ ਹੈ ਅਤੇ iroute ਉਸ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਪੀਅਰ ਇਸ ਨੂੰ ਲੈਣਾ ਚਾਹੀਦਾ ਹੈ। ਕੋਈ ਵੀ ਦੂਜੇ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈਂਦਾ, ਅਤੇ ਸਿਰਫ਼ ਇੱਕ ਰੱਖਣ ਵਾਲਾ ਸੰਰਚਨਾ ਪਹਿਲੀ ping ਤੱਕ ਵਾਜਬ ਦਿਸਦਾ ਹੈ।

ਦੋ ਫੈਸਲੇ, ਇੱਕ ਰੂਟ ਨਹੀਂ

ਇੱਕ ਸਾਈਟ-ਤੋਂ-ਸਾਈਟ ਲਿੰਕ ਦੀ ਕਲਪਨਾ ਕਰੋ ਜਿੱਥੇ 10.77.20.0/24 ਇੱਕ ਕਲਾਇੰਟ ਪਿੱਛੇ ਹੈ। ਸਰਵਰ ਦਾ ਕਰਨਲ ਰੂਟ, ਉਦਾਹਰਣ ਲਈ ip route add 10.77.20.0/24 dev tun0, ਮਿਲਦੇ ਪੈਕੇਟ ਟਨਲ ਡਿਵਾਈਸ ਨੂੰ ਭੇਜਦਾ ਹੈ। ਫਿਰ OpenVPN ਕਲਾਇੰਟ ਸੰਰਚਨਾ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚਲੀਆਂ iroute ਐਂਟਰੀਆਂ ਤੋਂ ਬਣੀ ਆਪਣੀ ਅੰਦਰੂਨੀ ਸਾਰਣੀ ਵੇਖਦਾ ਹੈ, ਤਾਂ ਜੋ ਤੈਅ ਕਰ ਸਕੇ ਕਿ ਕਿਹੜਾ ਪੀਅਰ ਕਨੈਕਸ਼ਨ ਉਹਨਾਂ ਨੂੰ ਲਵੇਗਾ। ਕਰਨਲ ਰੂਟ ਤੋਂ ਬਿਨਾਂ ਪੈਕੇਟ ਕਦੇ ਪ੍ਰਕਿਰਿਆ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦਾ, ਅਤੇ ਪੀਅਰ ਰੂਟ ਤੋਂ ਬਿਨਾਂ ਉਹ ਪ੍ਰਕਿਰਿਆ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ ਅਤੇ ਕਿਤੇ ਨਹੀਂ ਜਾਂਦਾ।

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

iroute ਕਿੱਥੇ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਕੀ ਕਹਿੰਦਾ ਹੈ

ਐਂਟਰੀ ਕਲਾਇੰਟ ਦੇ common_name ਅਨੁਸਾਰ ਨਾਮ ਵਾਲੀ ਪ੍ਰਤੀ-ਕਲਾਇੰਟ ਫਾਈਲ ਵਿੱਚ, client-config-dir ਅਧੀਨ, iroute 10.77.20.0/24 ਵਜੋਂ ਜਾਂਦੀ ਹੈ। ਫਾਈਲ ਨਾਮ ਦਾ ਮੇਲ ਸਜਾਵਟੀ ਨਹੀਂ ਹੈ: OpenVPN ਪ੍ਰਮਾਣਿਤ ਪਛਾਣ ਲੱਭਦਾ ਹੈ ਅਤੇ ਠੀਕ ਉਸੇ ਨਾਮ ਵਾਲੀ ਫਾਈਲ ਪੜ੍ਹਦਾ ਹੈ, ਇਸ ਲਈ site-a ਨਾਮ ਦੀ ਫਾਈਲ ਸਿਰਫ਼ ਉਸ ਕਲਾਇੰਟ ਲਈ ਲਾਗੂ ਹੁੰਦੀ ਹੈ ਜਿਸਦਾ ਆਮ ਨਾਮ site-a ਹੈ। ਜੇ ਅਜਿਹੀ ਫਾਈਲ ਤੋਂ ਬਿਨਾਂ ਕਲਾਇੰਟਾਂ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਕਾਰਨਾ ਹੋਵੇ ਤਾਂ ccd-exclusive ਸ਼ਾਮਲ ਕਰੋ, ਜੋ ਤਦ ਸਹੀ ਸੈਟਿੰਗ ਹੈ ਜਦੋਂ ਹਰ ਕਲਾਇੰਟ ਇੱਕ ਸਾਈਟ ਗੇਟਵੇ ਹੋਵੇ। ਹਰ ਗੇਟਵੇ ਲਈ ਇੱਕ ਫਾਈਲ ਰੱਖੋ ਅਤੇ ਇਸ ਨੂੰ ਉਸੇ ਪ੍ਰਮਾਣਪੱਤਰ ਵਿਸ਼ੇ ਦੇ ਨਾਮ ’ਤੇ ਰੱਖੋ ਜੋ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਜਾਰੀ ਕਰਦੇ ਹੋ।

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

ਜਾਲ: ਫਾਈਲ ਮੌਜੂਦ ਹੈ, ਪਛਾਣ ਗਲਤ

ਗਲਤ ਪੀਅਰ ਨਾਲ ਜੁੜਿਆ ਸਹੀ ਦਿਸਦਾ iroute ਗੁੰਮ ਫਾਈਲ ਤੋਂ ਵੱਧ ਸਮਾਂ ਬਰਬਾਦ ਕਰਦਾ ਹੈ, ਕਿਉਂਕਿ ਡਿਸਕ ’ਤੇ ਸਭ ਕੁਝ ਸਹੀ ਦਿਸਦਾ ਹੈ। ਪ੍ਰਮਾਣਪੱਤਰਾਂ ਦੇ ਨਾਮ ਬਦਲਣਾ, ਦੋਹਰੇ ਆਮ ਨਾਮ, ਅਤੇ ਪ੍ਰਭਾਵੀ ਪਛਾਣ ਬਦਲਣ ਵਾਲਾ username-as-common-name ਇਹ ਸਭ ਪੈਦਾ ਕਰਦੇ ਹਨ। ਜਾਂਚੋ ਕਿ ਸਰਵਰ ਨੇ ਕਿਹੜੀ ਪਛਾਣ ਪ੍ਰਮਾਣਿਤ ਕੀਤੀ, ਤੁਸੀਂ ਜਿਸਦੀ ਉਮੀਦ ਕੀਤੀ ਸੀ ਉਹ ਨਹੀਂ: ਸਥਿਤੀ ਆਉਟਪੁੱਟ ਹੀ ਅਧਿਕਾਰਿਕ ਹੈ, ਜਦੋਂ ਕਿ ਫਾਈਲ ਨਾਮ ਸਿਰਫ਼ ਖੋਜ ਕੁੰਜੀ ਹੈ।

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

ਪੀਅਰ ਤੋਂ ਪਾਰ ਰਸਤਾ ਪੂਰਾ ਕਰੋ

ਪੀਅਰ ਦੀ ਮਾਲਕੀ ਰਸਤੇ ਦੇ ਵਿਚਕਾਰ ਹੈ, ਅੰਤ ਵਿੱਚ ਨਹੀਂ। ਕਲਾਇੰਟ ਨੂੰ ਟਨਲ ਤੋਂ ਪੈਕੇਟ ਆਪਣੇ LAN ਵਿੱਚ ਫਾਰਵਰਡ ਕਰਨੇ ਪੈਂਦੇ ਹਨ, ਭਾਵ ਉਸ ਹੋਸਟ ’ਤੇ IP ਫਾਰਵਰਡਿੰਗ ਸਮਰੱਥ ਹੋਵੇ ਅਤੇ ਫਾਇਰਵਾਲ ਨਿਯਮ ਲੰਘਣ ਦੇਵੇ। ਦੂਰ ਦੇ LAN ਦੇ ਹੋਸਟਾਂ ਨੂੰ ਟਨਲ ਪਤੇ ਲਈ ਵਾਪਸੀ ਰਸਤਾ ਚਾਹੀਦਾ ਹੈ: ਜਾਂ ਤਾਂ ਗੇਟਵੇ ਵੱਲ ਵਾਪਸ ਦਿਸ਼ਾ ਦੇਣ ਵਾਲਾ ਰੂਟ, ਜਾਂ ਕਲਾਇੰਟ ਪਾਸੇ ਜਾਣ-ਬੁੱਝ ਕੇ ਤਿਆਰ ਕੀਤਾ NAT ਡਿਜ਼ਾਈਨ। ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਦੇ ਡਿਫਾਲਟ ਨੂੰ ਮੰਨਣ ਦੀ ਬਜਾਏ sysctl net.ipv4.ip_forward ਨਾਲ ਕਲਾਇੰਟ ’ਤੇ ਫਾਰਵਰਡ ਸੈਟਿੰਗ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।

ਜੇ ਹੋਰ VPN ਕਲਾਇੰਟਾਂ ਨੂੰ ਉਸ ਸਬਨੈੱਟ ਤੱਕ ਪਹੁੰਚਣਾ ਹੈ, ਤਾਂ ਪ੍ਰਬੰਧ ਫਿਰ ਵਧਦਾ ਹੈ: ਸਰਵਰ ਨੂੰ client-to-client ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਉਹਨਾਂ ਕਲਾਇੰਟਾਂ ਨੂੰ ਪ੍ਰੀਫਿਕਸ ਟਨਲ ਰਾਹੀਂ ਰੂਟ ਕਰਨਾ ਪਵੇਗਾ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੁਝ ਵੀ ਸਰਵਰ ਦੀ ਆਪਣੀ ਰੂਟ ਸਾਰਣੀ ਤੋਂ ਨਹੀਂ ਆਉਂਦਾ।

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