ਟਨਲ ਜੁੜਦੀ ਹੈ, ਫਿਰ ਐਕਸੈਸ ਲਿੰਕ ’ਤੇ ਲੀਜ਼ ਨਵੀਨੀਕਰਨ ਇਸਨੂੰ ਮਾਰ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਲਾਗ ਰੂਟ ਨਹੀਂ, ਟਾਈਮਆਊਟ ਨੂੰ ਦੋਸ਼ ਦਿੰਦਾ ਹੈ। VPN ਕੌਨਫਿਗਰੇਸ਼ਨ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਬਦਲਿਆ, ਅਤੇ ਇਹੀ ਸੁਰਾਗ ਹੈ: ਇਸ ਤੋਂ ਬਾਹਰ ਕੁਝ ਬਦਲਿਆ ਹੈ। ਕਿਸੇ DHCP ਘਟਨਾ ਨੇ ਪਤਾ ਜਾਂ ਗੇਟਵੇ ਦੁਬਾਰਾ ਲਿਖਿਆ, ਅਤੇ ਟਨਲ ਦੇ ਐਂਡਪੌਇੰਟ ਨੂੰ ਪਹੁੰਚਯੋਗ ਰੱਖਣ ਵਾਲਾ ਹੋਸਟ ਰੂਟ ਹੁਣ ਅਜਿਹੇ ਅਗਲੇ ਹੌਪ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ ਜੋ ਹੁਣ ਨਹੀਂ ਹੈ। ਇਹ ਰੂਟਿੰਗ ਸਮੱਸਿਆ ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ ਮਾਲਕੀ ਦੀ ਸਮੱਸਿਆ ਹੈ।

ਲੱਛਣ ਦੀ ਅੱਧ-ਡਿਫਾਲਟ ਰੂਟ ਨਾਲ ਤੁਲਨਾ ਕਰੋ

redirect-gateway def1 ਨਾਲ, OpenVPN ਡਿਫਾਲਟ ਰੂਟ ਬਦਲਣ ਦੀ ਬਜਾਏ 0.0.0.0/1 ਅਤੇ 128.0.0.0/1 ਸਥਾਪਿਤ ਕਰਦਾ ਹੈ। ਦੋਵੇਂ ਮਿਲ ਕੇ ਪੂਰੀ ਪਤਾ ਥਾਂ ਢਕ ਲੈਂਦੇ ਹਨ, ਅਤੇ ਉਹ ਸਿਰਫ਼ ਪ੍ਰੀਫਿਕਸ ਲੰਬਾਈ ਨਾਲ 0.0.0.0/0 ਨੂੰ ਹਰਾਉਂਦੇ ਹਨ। ਇਸ ਲਈ ਹੋਰ ਖਾਸ ਮੇਲ ਤੋਂ ਬਿਨਾਂ ਕੋਈ ਵੀ ਮੰਜ਼ਿਲ ਟਨਲ ਵਿੱਚ ਦਾਖਲ ਹੁੰਦੀ ਹੈ।

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

ਕੁਝ ਹੋਰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਟੇਬਲ ਦੀ ਸ਼ਕਲ ਪੁਸ਼ਟੀ ਕਰੋ। ip route show ਨੂੰ ਦੋਵੇਂ ਅੱਧ ਅਤੇ ਸਰਵਰ ਪਤੇ ਲਈ ਹੋਸਟ ਰੂਟ ਸੂਚੀਬੱਧ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ; ਹੋਸਟ ਰੂਟ ਨਾ ਹੋਣ ’ਤੇ ਬਾਕੀ ਜਾਂਚ ਨੂੰ ਸਪਸ਼ਟ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ ਮਿਲਦਾ ਹੈ।

ਮੈਟ੍ਰਿਕ ਬਦਲੇ ਬਿਨਾਂ ਅੱਧ-ਡਿਫਾਲਟ ਕਿਉਂ ਜਿੱਤਦੇ ਹਨ

ਘੱਟ ਮੈਟ੍ਰਿਕ ਲੰਬੇ ਪ੍ਰੀਫਿਕਸ ਨੂੰ ਨਹੀਂ ਹਰਾਉਂਦੀ। /1 ਰੂਟ ਜਿੱਤਦੇ ਹਨ ਕਿਉਂਕਿ ਕਰਨਲ ਪਹਿਲਾਂ ਸਭ ਤੋਂ ਖਾਸ ਰੂਟ ਮਿਲਾਉਂਦਾ ਹੈ, ਇਸ ਲਈ ਡਿਫਾਲਟ ਰੂਟ ’ਤੇ ਮੈਟ੍ਰਿਕ ਵਧਾਉਣ ਨਾਲ ਟਨਲ ਵੱਲ ਜਾਣ ਵਾਲੇ ਟ੍ਰੈਫਿਕ ਦੀ ਦਿਸ਼ਾ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ। ਮੈਟ੍ਰਿਕ ਦੇ ਪਿੱਛੇ ਭੱਜਣਾ ਇਸ ਨਿਦਾਨ ਵਿੱਚ ਸਭ ਤੋਂ ਆਮ ਗਲਤ ਮੋੜ ਹੈ।

ip route get 203.0.113.10 ਨਾਲ ਚੋਣ ਜਾਂਚੋ, ਇਸ ਵਿੱਚ ਸਰਵਰ ਦਾ ਅਸਲੀ ਪਤਾ ਪਾਓ। ਜਵਾਬ ਉਹ ਇੰਟਰਫੇਸ ਅਤੇ ਅਗਲਾ ਹੌਪ ਦੱਸਦਾ ਹੈ ਜੋ ਕਰਨਲ ਅਸਲ ਵਿੱਚ ਵਰਤੇਗਾ, ਅਤੇ ਇਹ ਟੇਬਲ ਪੜ੍ਹ ਕੇ ਉਸ ਬਾਰੇ ਸੋਚਣ ਨਾਲੋਂ ਵਧੇਰੇ ਜਾਣਕਾਰੀਪੂਰਨ ਹੈ।

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

ਇੱਕ ਨਹੀਂ, ਤਿੰਨ ਸਨੈਪਸ਼ਾਟ ਲਓ

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

ਸਨੈਪਸ਼ਾਟ ਸਮੇਂ-ਮੋਹਰਾਂ ਨਾਲ ਇੱਕ ਫ਼ਾਈਲ ਵਿੱਚ ਰੱਖੋ, ਕਿਉਂਕਿ ਬਾਅਦ ਵਿੱਚ ਦਿਲਚਸਪ ਸਵਾਲ ਕ੍ਰਮ ਹੈ। DHCP ਘਟਨਾ OpenVPN ਦੇ ਆਪਣਾ ਰੂਟ ਤਾਜ਼ਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਆਈ ਸੀ ਜਾਂ ਬਾਅਦ ਵਿੱਚ? ਜਵਾਬ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਇਸਨੂੰ ਕਿਸਨੇ ਠੀਕ ਕਰਨਾ ਹੈ। ਗਲਤ ਘੜੀ ਦੀ ਸਮੇਂ-ਮੋਹਰ ਨਾ ਹੋਣ ਨਾਲੋਂ ਮਾੜੀ ਹੈ, ਇਸ ਲਈ ਇਸਨੂੰ ਰੂਟਿੰਗ ਟੇਬਲ ਵਾਲੇ ਹੋਸਟ ਤੋਂ ਲਓ।

ਜਦੋਂ ਐਂਡਪੌਇੰਟ ਪਤੇ ਦੀ ਬਜਾਏ ਨਾਮ ਵਜੋਂ ਕੌਨਫਿਗਰ ਹੋਵੇ, ਤਾਂ ਹਰ ਸਨੈਪਸ਼ਾਟ ਵਿੱਚ ਇਸਨੂੰ ਵੀ ਹੱਲ ਕਰੋ। ਐਕਸੈਸ ਲਿੰਕ ’ਤੇ DNS ਬਦਲਾਅ ਕਿਸੇ ਵੀ ਰੂਟ ਨੂੰ ਛੂਹੇ ਬਿਨਾਂ ਐਂਡਪੌਇੰਟ ਨੂੰ ਹਿਲਾ ਸਕਦਾ ਹੈ।

ਕਿਹੜਾ ਹਿੱਸਾ ਅਪਵਾਦ ਤਾਜ਼ਾ ਕਰਦਾ ਹੈ, ਇਹ ਤੈਅ ਕਰੋ

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

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

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

ਸਿਰਫ਼ ਦੁਬਾਰਾ ਜੁੜਾਅ ਨਹੀਂ, ਜੀਵਨ-ਚੱਕਰ ਪਰਖੋ

dhcpcd -n eth0 ਨਾਲ ਜਾਂ ਲੀਜ਼ ਛੱਡ ਕੇ ਦੁਬਾਰਾ ਲੈ ਕੇ ਨਵੀਨੀਕਰਨ ਜ਼ਬਰਦਸਤੀ ਕਰੋ, ਫਿਰ ਐਂਡਪੌਇੰਟ ਲਈ ip route get ਦੁਬਾਰਾ ਵੇਖੋ। ਇਹ ਦੋ ਵਾਰ ਕਰੋ, ਕਿਉਂਕਿ ਦੂਜਾ ਦੌਰ ਦੁਹਰੇ ਰੂਟ ਜੋੜਨ ਵਾਲੇ ਹੂਕ ਫੜਦਾ ਹੈ। ਫਿਰ ਰੀਬੂਟ ਕਰੋ, ਕਿਉਂਕਿ ਟਿਕਾਊਪਣ ਸ਼ੁੱਧਤਾ ਤੋਂ ਵੱਖਰਾ ਗੁਣ ਹੈ।

ਨਵੀਨੀਕਰਨ ਅਤੇ ਰੀਬੂਟ ਦੋਵੇਂ ਝੱਲਣ ਵਾਲੀ ਟਨਲ ਦਾ ਮਾਲਕ ਅਤੇ ਕੰਮ ਕਰਨ ਵਾਲਾ ਅਪਵਾਦ ਹੁੰਦਾ ਹੈ। ਸਿਰਫ਼ ਹੱਥੀ ਰੀਸਟਾਰਟ ਝੱਲਣ ਵਾਲੀ ਕੋਲ ਦੋਵੇਂ ਨਹੀਂ ਹੁੰਦੇ, ਅਤੇ ਉਹ ਅਗਲੀ ਉਸ ਘਟਨਾ ’ਤੇ ਅਸਫਲ ਹੋਵੇਗੀ ਜਿਸਨੂੰ ਤੁਸੀਂ ਤੈਅ ਨਹੀਂ ਕਰ ਸਕਦੇ।

ਸੰਬੰਧਿਤ ਲੇਖ