OpenVPN ਰੂਟ ਯੋਜਨਾ ਵਿੱਚ bypass-dhcp ਅਸਲ ਵਿੱਚ ਕੀ ਜੋੜਦਾ ਹੈ

redirect-gateway def1 bypass-dhcp ਵਾਲਾ ਪਰੋਫਾਈਲ IPv4 ਡਿਫਾਲਟ ਰੂਟ ਦੀ ਥਾਂ ਲੈਣ ਨੂੰ ਇੱਕ ਤੰਗ ਅਪਵਾਦ ਨਾਲ ਜੋੜਦਾ ਹੈ। ਲੋਕ ਆਖਰੀ ਸ਼ਬਦ ਪੜ੍ਹਦੇ ਹਨ ਅਤੇ ਮੋਬਾਈਲ ਕਨੈਕਸ਼ਨਾਂ ਲਈ ਆਮ ਹੱਲ ਉਮੀਦ ਕਰਦੇ ਹਨ, ਫਿਰ ਉਸ DHCP ਸਿਧਾਂਤ ਉੱਤੇ ਦੁਪਹਿਰ ਬਿਤਾਉਂਦੇ ਹਨ ਜਿਸਨੂੰ ਇਸ ਫਲੈਗ ਨੇ ਕਦੇ ਸਮਰਥਨ ਨਹੀਂ ਦਿੱਤਾ। ਹਰ ਭਾਗ ਇੱਕ ਕੰਮ ਕਰਦਾ ਹੈ, ਅਤੇ ਅਪਵਾਦ ਆਪਣੀ ਪ੍ਰਤਿਸ਼ਠਾ ਤੋਂ ਬਹੁਤ ਛੋਟਾ ਹੈ।

ਸਿਰਫ਼ ਮੋਬਾਈਲ ਨੈੱਟਵਰਕ ਦੀ ਅਸਫਲਤਾ ਨੂੰ ਪਤਾ ਨਿਰਧਾਰਨ ਉੱਤੇ ਥੋਪਣ ਤੋਂ ਪਹਿਲਾਂ ਫਲੈਗਾਂ ਨੂੰ ਵੱਖ ਕਰੋ। ਉਸ ਸਤਰ ਦੇ ਦੋਵੇਂ ਅੱਧਿਆਂ ਦਾ ਇੱਕ-ਦੂਜੇ ਨਾਲ ਕੋਈ ਸੰਬੰਧ ਨਹੀਂ ਹੈ।

ਦੋ ਫਲੈਗ, ਦੋ ਅਸੰਬੰਧਿਤ ਕੰਮ

def1 ਨਾਲ, ਕਲਾਇੰਟ ਪਹਿਲਾਂ ਤੋਂ ਮੌਜੂਦ ਡਿਫਾਲਟ ਰੂਟ ਨੂੰ ਬਦਲਣ ਦੀ ਬਜਾਏ ਦੋ IPv4 ਅੱਧ-ਡਿਫਾਲਟ ਰੂਟ ਜੋੜਦਾ ਹੈ। 0.0.0.0/1 ਪਤਾ ਥਾਂ ਦਾ ਹੇਠਲਾ ਅੱਧਾ ਹਿੱਸਾ ਕਵਰ ਕਰਦਾ ਹੈ ਅਤੇ 128.0.0.0/1 ਉੱਪਰਲਾ ਅੱਧਾ, ਇਸ ਲਈ ਮਿਲ ਕੇ ਉਹ ਹਰ ਮੰਜ਼ਿਲ ਤੱਕ ਪਹੁੰਚਦੇ ਹਨ, ਜਦੋਂ ਕਿ ਹਰ ਇੱਕ 0.0.0.0/0 ਤੋਂ ਵੱਧ ਖ਼ਾਸ ਰਹਿੰਦਾ ਹੈ। ਇਸ ਲਈ ਮੂਲ ਡਿਫਾਲਟ ਰੂਟ ਉਹਨਾਂ ਖੋਜਾਂ ਨੂੰ ਜਿੱਤੇ ਬਿਨਾਂ ਸਾਰਣੀ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ, ਜੋ ਪੁਰਾਣੇ ਗੇਟਵੇ ਨੂੰ ਕਲਾਇੰਟ ਵੱਲੋਂ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਰੂਟ ਕੀਤੀ ਹਰ ਚੀਜ਼ ਲਈ ਪਹੁੰਚਯੋਗ ਰੱਖਦਾ ਹੈ। ਇਹ ਸਾਰਣੀ ਵਿੱਚ ਦੋ ਇੱਕ-ਦੂਜੇ ਉੱਤੇ ਚੜ੍ਹਦੇ ਡਿਫਾਲਟ ਰੂਟ ਵੀ ਛੱਡਦਾ ਹੈ, ਅਤੇ ਇਸੇ ਲਈ ਰੂਟ ਡੰਪ ਪਰੋਫਾਈਲ ਦੇ ਸੰਕੇਤ ਨਾਲੋਂ ਅਜੀਬ ਲੱਗ ਸਕਦਾ ਹੈ।

bypass-dhcp ਵੱਖਰਾ ਹੈ, ਅਤੇ ਇਹ ਡਿਫਾਲਟ ਰੂਟ ਨੂੰ ਬਿਲਕੁਲ ਨਹੀਂ ਛੂੰਹਦਾ। OpenVPN 2.6 ਮੈਨੁਅਲ ਇਸਨੂੰ ਸਥਾਨਕ ਸਬਨੈੱਟ ਉੱਤੇ ਨਾ ਹੋਣ ਵਾਲੇ DHCP ਸਰਵਰ ਤੱਕ ਸਿੱਧਾ ਰੂਟ ਜੋੜਨਾ ਦੱਸਦਾ ਹੈ, ਤਾਂ ਜੋ ਲੀਜ਼ ਟ੍ਰੈਫਿਕ ਟਨਲ ਤੋਂ ਬਾਹਰ ਜਾਵੇ, ਅਤੇ ਨੋਟ ਕਰਦਾ ਹੈ ਕਿ ਇਹ ਵਿਵਹਾਰ Windows ਕਲਾਇੰਟਾਂ ਵਿੱਚ ਲਾਗੂ ਹੈ ਅਤੇ ਹੋਰ ਥਾਂ ਉਪਲਬਧ ਨਾ ਹੋ ਸਕਦਾ ਹੈ।

ਇਸਦੇ ਹੋਣ ਦਾ ਕਾਰਨ ਯਾਂਤਰਿਕ ਹੈ। ਇੱਕ ਵਾਰ ਅੱਧ-ਡਿਫਾਲਟ ਰੂਟ ਬਾਹਰ ਜਾਂਦਾ ਟ੍ਰੈਫਿਕ ਫੜ ਲੈਣ, ਭੌਤਿਕ ਨੈੱਟਵਰਕ ਦੇ ਸਰਵਰ ਵੱਲ ਭੇਜਿਆ DHCP ਨਵੀਨੀਕਰਨ ਟਨਲ ਵਿੱਚ ਰੂਟ ਹੋ ਜਾਵੇਗਾ, ਜਦੋਂ ਤੱਕ ਕੋਈ ਉਸ ਪਤੇ ਨੂੰ ਅਸਲੀ ਇੰਟਰਫੇਸ ਨਾਲ ਪਿੰਨ ਨਾ ਕਰੇ। ਫਲੈਗ ਉਸਨੂੰ ਪਿੰਨ ਕਰਦਾ ਹੈ।

ਅਪਵਾਦ ਅਸਲ ਵਿੱਚ ਕਿੰਨਾ ਸੀਮਿਤ ਹੈ

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

0.0.0.0/1        via 10.8.0.1      dev tun0
128.0.0.0/1      via 10.8.0.1      dev tun0
192.168.1.1/32   via 192.168.1.254 dev wlan0

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

ਜਾਂਚੋ ਕਿ ਕਲਾਇੰਟ ਨੇ ਅਸਲ ਵਿੱਚ ਕੀ ਸਥਾਪਤ ਕੀਤਾ

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

VPN ਅੰਤ ਬਿੰਦੂ ਤੱਕ ਦਾ ਰੂਟ ਵੀ ਉਸੇ ਸਮੇਂ ਵਰਤੋਂਯੋਗ ਰੱਖੋ। ਉਹ ਅੰਤ ਬਿੰਦੂ ਅਪਵਾਦ DHCP ਅਪਵਾਦ ਤੋਂ ਵੱਖਰੀ ਲੋੜ ਹੈ, ਅਤੇ ਇਸ ਤੋਂ ਬਿਨਾਂ ਟਨਲ ਉਸ ਆਵਾਜਾਈ ਨੂੰ ਫੜ ਸਕਦਾ ਹੈ ਜੋ ਇਸਨੂੰ ਕਾਇਮ ਰੱਖਦੀ ਹੈ।

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

ਬਾਕੀ ਰਾਹ ਇਸ ਫਲੈਗ ਵਿੱਚ ਨਹੀਂ ਹੈ

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

ਨਾਮ ਹੱਲ ਅਤੇ IPv6 ਦੋਵਾਂ ਨੂੰ ਆਪਣੀ ਨੀਤੀ ਚਾਹੀਦੀ ਹੈ। IPv4 ਬਦਲਾਅ ਨਾ ਰਿਜ਼ੋਲਵਰ ਨੂੰ ਟਨਲ-ਪਾਸੇ ਦੇ ਸਰਵਰ ਵੱਲ ਮੋੜਦਾ ਹੈ ਅਤੇ ਨਾ IPv6 ਕਵਰੇਜ ਸਥਾਪਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਕੇਵਲ v4 ਨੂੰ ਰੀਡਾਇਰੈਕਟ ਕਰਨ ਵਾਲਾ ਕਲਾਇੰਟ v6 ਰਾਹ ਨੂੰ ਅਛੂਤਾ ਛੱਡਦਾ ਹੈ।

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