route-gateway redirect-gateway ਨਹੀਂ ਹੈ: ਅਸਲ ਵਿੱਚ ਕੀ ਬਦਲਦਾ ਹੈ
ਇਹ ਵਿਕਲਪ ਸਿਰਫ਼ ਉਨ੍ਹਾਂ ਰੂਟਾਂ ਲਈ ਅਗਲਾ ਹੌਪ ਦਿੰਦਾ ਹੈ ਜੋ OpenVPN ਸਥਾਪਿਤ ਕਰਦਾ ਹੈ। ਇਸ ਨੂੰ ਹਟਾਉਣ ਨਾਲ ਧੱਕਿਆ ਪੂਰਾ ਟਨਲ ਬੰਦ ਨਹੀਂ ਹੁੰਦਾ, ਅਤੇ ਸੁਧਾਰ ਰੀਡਾਇਰੈਕਸ਼ਨ ਵਿੱਚ ਹੈ।
ਤੁਹਾਡਾ ਟਨਲ ਉੱਪਰ ਆਉਂਦਾ ਹੈ, ਪ੍ਰਾਈਵੇਟ ਸਬਨੈੱਟ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਕਿਸੇ ਨੇ ਪਰੋਫ਼ਾਈਲ ਤੋਂ ਗੇਟਵੇ ਲਾਈਨ ਹਟਾ ਦਿੱਤੀ ਹੋਣ ਦੇ ਬਾਵਜੂਦ ਆਮ ਬ੍ਰਾਊਜ਼ਿੰਗ ਅਜੇ ਵੀ VPN ਵਿੱਚ ਗਾਇਬ ਹੋ ਜਾਂਦੀ ਹੈ। ਇਹੀ ਸੰਜੋਗ ਗਲਤ ਨਿਰਦੇਸ਼ ਦੇ ਸੰਪਾਦਿਤ ਹੋਣ ਦੀ ਉਂਗਲ ਦੀ ਛਾਪ ਹੈ। ਹਟਾਇਆ ਗਿਆ ਕਲਾਇੰਟ ਨੂੰ ਉਹਨਾਂ ਰੂਟਾਂ ਲਈ ਅਗਲਾ ਹੌਪ ਦਿੰਦਾ ਸੀ ਜੋ ਇਹ ਸਥਾਪਿਤ ਕਰਦਾ ਹੈ; ਜੋ ਟ੍ਰੈਫ਼ਿਕ ਫੜਨਾ ਜਾਰੀ ਰੱਖਿਆ ਉਹ ਕਿਤੇ ਹੋਰੋਂ ਆਇਆ ਅਤੇ ਸਰਵਰ ਨੇ ਧੱਕਿਆ। ਕਵਰੇਜ ਅਤੇ ਅਗਲਾ ਹੌਪ ਵੱਖਰੇ ਕੰਮ ਹਨ, ਅਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਹੀ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਜਨਤਕ ਮੰਜ਼ਿਲਾਂ ਟਨਲ ਵਰਤਦੀਆਂ ਹਨ ਜਾਂ ਨਹੀਂ।
ਤੁਸੀਂ ਜੋ ਲਾਈਨ ਹਟਾਈ ਉਹ ਅਗਲਾ ਹੌਪ ਸੀ, ਨੀਤੀ ਸਵਿੱਚ ਨਹੀਂ
ਕਲਾਇੰਟ ਜੋ ਵੀ ਰੂਟ ਸਥਾਪਿਤ ਕਰਦਾ ਹੈ ਉਸ ਨੂੰ ਦਿਸ਼ਾ ਦੇਣ ਲਈ ਗੇਟਵੇ ਪਤਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਜਦੋਂ ਰੂਟ ਆਪ ਕੋਈ ਪਤਾ ਨਹੀਂ ਦੱਸਦਾ ਤਾਂ ਗੇਟਵੇ ਨਿਰਦੇਸ਼ ਉਸੇ ਪਤੇ ਦਾ ਸਰੋਤ ਹੁੰਦਾ ਹੈ। ਇਸ ਨੂੰ ਹਟਾ ਦਿਓ ਤਾਂ ਉਹਨਾਂ ਰੂਟਾਂ ਕੋਲ ਟੰਗਣ ਦੀ ਥਾਂ ਨਹੀਂ ਰਹਿੰਦੀ, ਇਸ ਲਈ ਉਹ ਜਾਂ ਤਾਂ ਸਥਾਪਿਤ ਨਹੀਂ ਹੁੰਦੇ ਜਾਂ ਐਸੇ ਰਸਤੇ ਉੱਤੇ ਉਤਰਦੇ ਹਨ ਜੋ ਕਿਤੇ ਨਹੀਂ ਜਾਂਦਾ। ਪ੍ਰਾਈਵੇਟ ਸਬਨੈੱਟ ਉਹੀ ਹੈ ਜੋ ਐਸਾ ਰੂਟ ਢੋਂਦਾ ਸੀ।
ਇਸ ਦੌਰਾਨ ਬਚੇ ਹੋਏ ਵਿਵਹਾਰ ਦਾ ਹੋਰ ਲੇਖਕ ਹੈ: ਧੱਕੇ ਹੋਏ ਬਲਾਕ ਵਿੱਚ ਰੀਡਾਇਰੈਕਟ ਵਿਕਲਪ, ਜੋ ਆਪਣੇ ਫਲੈਗਾਂ ਅਨੁਸਾਰ ਆਮ ਬਾਹਰ ਜਾਣ ਵਾਲੇ ਟ੍ਰੈਫ਼ਿਕ ਨੂੰ ਟਨਲ ਵਿੱਚ ਲੈ ਜਾਂਦਾ ਹੈ। ਗੇਟਵੇ ਹਟਾਉਣ ਨਾਲ ਇਹ ਨਾ ਬੰਦ ਹੁੰਦਾ ਹੈ ਨਾ ਕਮਜ਼ੋਰ। ਨਤੀਜਾ ਦੋਵਾਂ ਹਾਲਤਾਂ ਵਿੱਚੋਂ ਸਭ ਤੋਂ ਮਾੜਾ ਹੈ, ਜਨਤਕ ਟ੍ਰੈਫ਼ਿਕ ਅਜੇ ਵੀ ਫੜਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਜਿਸ ਪ੍ਰਾਈਵੇਟ ਮੰਜ਼ਿਲ ਨੇ ਟਨਲ ਨੂੰ ਜਾਇਜ਼ ਠਹਿਰਾਇਆ ਸੀ ਉਹ ਹੁਣ ਪਹੁੰਚ ਤੋਂ ਬਾਹਰ ਹੈ। ਇਸੇ ਲਈ ਉਸੇ ਭਾਵਨਾ ਨਾਲ ਕੀਤਾ ਦੂਜਾ ਸੰਪਾਦਨ ਵੀ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ।
ਚਾਰ ਲੀਵਰ, ਚਾਰ ਵੱਖਰੇ ਕੰਮ
ਇਸ ਚਰਚਾ ਵਿੱਚ ਚਾਰ ਨਿਰਦੇਸ਼ ਇੱਕ-ਦੂਜੇ ਦੀ ਥਾਂ ਉੱਪਰ ਲਏ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਕਵਰੇਜ ਨਿਯੰਤਰਿਤ ਕਰਦਾ ਹੈ, ਯਾਨੀ ਕਿਹੜੀਆਂ ਮੰਜ਼ਿਲਾਂ ਟਨਲ ਵਿੱਚੋਂ ਲੰਘਦੀਆਂ ਹਨ। ਦੂਜਾ ਉਹ ਅਗਲਾ ਹੌਪ ਤੈਅ ਕਰਦਾ ਹੈ ਜੋ ਰੂਟ ਵਰਤਦੇ ਹਨ, ਤੀਜਾ ਇੱਕ ਹੀ ਪ੍ਰੀਫ਼ਿਕਸ ਸਥਾਪਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਚੌਥਾ ਸਰਵਰ ਵੱਲੋਂ ਧੱਕਿਆ ਸਭ ਕੁਝ ਸੁੱਟ ਦਿੰਦਾ ਹੈ, ਤੈਨਾਤੀ ਲਈ ਲੋੜੀਂਦੇ ਪ੍ਰਾਈਵੇਟ ਰੂਟਾਂ ਸਮੇਤ। ਸਾਰਣੀ ਉਹਨਾਂ ਨੂੰ ਨਾਮ ਅਨੁਸਾਰ ਨਹੀਂ, ਸਗੋਂ ਪ੍ਰਬੰਧਕ ਕੀ ਬਦਲਣਾ ਚਾਹੁੰਦਾ ਹੈ ਉਸ ਅਨੁਸਾਰ ਲਗਾਉਂਦੀ ਹੈ, ਕਿਉਂਕਿ ਉਲਝਣ ਨਾਮਾਂ ਕਰਕੇ ਹੀ ਹੁੰਦੀ ਹੈ। ਇਹਨਾਂ ਨੂੰ ਚਾਰ ਵੱਖਰੇ ਫ਼ੈਸਲੇ ਮੰਨੋ ਅਤੇ ਉਹ ਚੁਣੋ ਜੋ ਤੁਸੀਂ ਸੱਚਮੁੱਚ ਉਲਟਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ।
ਵਿਵਹਾਰ ਵਿੱਚ ਚਾਰੇ ਅਕਸਰ ਇੱਕ ਹੀ ਧੱਕੇ ਹੋਏ ਬਲਾਕ ਵਿੱਚ, ਲਾਈਨ ਤੋਂ ਬਾਅਦ ਲਾਈਨ ਆਉਂਦੇ ਹਨ, ਜੋ ਉਹਨਾਂ ਨੂੰ ਇੱਕੋ ਸੈਟਿੰਗ ਦੇ ਹਿੱਸੇ ਜਿਹੇ ਦਿਖਾਉਂਦਾ ਹੈ। ਉਹ ਨਹੀਂ ਹਨ, ਅਤੇ OpenVPN ਹਵਾਲਾ ਉਹਨਾਂ ਨੂੰ ਵੱਖਰੇ ਮਕੈਨਿਜ਼ਮ ਵਜੋਂ ਦਰਜ ਕਰਦਾ ਹੈ ਇਸੇ ਕਾਰਨ। ਤੁਸੀਂ ਕਿਹੜਾ ਫ਼ੈਸਲਾ ਉਲਟਾ ਰਹੇ ਹੋ ਇਹ ਪਤਾ ਕਰਨਾ ਕੰਮ ਹੈ; ਸੰਪਾਦਨ ਇੱਕ ਲਾਈਨ ਹੈ।
| What you are trying to change | Directive that decides it | What it leaves alone |
|---|---|---|
| Which destinations use the tunnel | redirect-gateway | Per-prefix routes and resolver choice |
| The next hop a pushed route points at | route-gateway | Coverage of public destinations |
| One reachable prefix | route | Every other destination, default path included |
| All pushed routing and DNS at once | route-nopull | Nothing, which is the problem |
ਧੱਕੀ ਹੋਈ ਲਾਈਨ ਫਿਲਟਰ ਕਰੋ, ਅਗਲਾ ਹੌਪ ਰੱਖੋ
ਜੇ ਤੁਸੀਂ ਜਿਸ ਕਵਰੇਜ ਦਾ ਵਿਰੋਧ ਕਰਦੇ ਹੋ ਉਹ ਧੱਕੇ ਹੋਏ ਵਿਕਲਪ ਵਜੋਂ ਆਉਂਦੀ ਹੈ, ਤਾਂ ਤੰਗ ਜਵਾਬ ਇਹ ਹੈ ਕਿ ਉਸ ਵਿਕਲਪ ਨੂੰ ਨਾਮ ਨਾਲ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰੋ ਅਤੇ ਧੱਕੇ ਹੋਏ ਬਲਾਕ ਦਾ ਬਾਕੀ ਹਿੱਸਾ ਅਛੂਤਾ ਛੱਡੋ। ਫਿਲਟਰ ਵਜੋਂ ਲਿਖਿਆ ਇਹ ਹੇਠਾਂ ਦਿੱਤੀ ਲਾਈਨ ਵਰਗਾ ਦਿਸਦਾ ਹੈ, ਅਤੇ ਇਸ ਦੀ ਥਾਂ ਪ੍ਰਭਾਵਿਤ ਕਲਾਇੰਟ ਦੀ ਪਰੋਫ਼ਾਈਲ ਵਿੱਚ ਹੈ, ਸਰਵਰ ਕਾਨਫ਼ਿਗਰੇਸ਼ਨ ਵਿੱਚ ਨਹੀਂ।
pull-filter ignore "redirect-gateway"ਤੰਗੀ ਹੀ ਮੁੱਦਾ ਹੈ। ਕਿਉਂਕਿ ਫਿਲਟਰ ਟੈਕਸਟ ਪ੍ਰੀਫ਼ਿਕਸ ਦੀ ਤੁਲਨਾ ਕਰਦਾ ਹੈ, ਛੋਟਾ ਪੈਟਰਨ ਅਗਲੇ-ਹੌਪ ਨਿਰਦੇਸ਼ ਨਾਲ ਵੀ ਮੇਲ ਖਾਂਦਾ ਹੈ, ਜੋ ਉਹੀ ਜਾਣਕਾਰੀ ਲਾਹ ਦਿੰਦਾ ਹੈ ਜਿਸ ਉੱਤੇ ਪ੍ਰਾਈਵੇਟ ਰੂਟ ਨਿਰਭਰ ਹਨ ਅਤੇ ਮੂਲ ਗਲਤੀ ਨੂੰ ਨਵੇਂ ਭੇਸ ਵਿੱਚ ਦੁਹਰਾਉਂਦਾ ਹੈ। ਫਿਲਟਰ ਸਿਰਫ਼ ਧੱਕੇ ਹੋਏ ਵਿਕਲਪਾਂ ਉੱਤੇ ਹੀ ਕੰਮ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਸਥਾਨਕ ਤੌਰ ਉੱਤੇ ਲਿਖੀ ਜਾਂ ਨੈੱਟਵਰਕ ਮੈਨੇਜਰ ਵੱਲੋਂ ਥੋਪੀ ਸਮਾਨ ਲਾਈਨ ਨੂੰ ਕਦੇ ਨਹੀਂ ਛੂੰਹਦਾ। ਇਸ ਤੋਂ ਬਾਅਦ ਮੁੜ ਕਨੈਕਟ ਕਰੋ, ਕਿਉਂਕਿ ਜੀਵਤ ਸੈਸ਼ਨ ਸਰਵਰ ਵੱਲੋਂ ਧੱਕੇ ਗਏ ਦਾ ਮੁੜ ਮੁਲਾਂਕਣ ਨਹੀਂ ਕਰਦਾ।
ਸਾਰਣੀ ਨਹੀਂ, ਖੋਜ ਪੜ੍ਹੋ
ਪਰੋਫ਼ਾਈਲ ਮੁੜ ਲੋਡ ਕਰਨ ਤੋਂ ਬਾਅਦ ਕਰਨਲ ਨੂੰ ਪੁੱਛੋ ਕਿ ਦੋ ਮੰਜ਼ਿਲਾਂ ਅਸਲ ਵਿੱਚ ਕਿੱਥੇ ਜਾਣਗੀਆਂ: ਇੱਕ ਪ੍ਰਾਈਵੇਟ ਪ੍ਰੀਫ਼ਿਕਸ ਦੇ ਅੰਦਰ ਅਤੇ ਇੱਕ ਜਨਤਕ ਇੰਟਰਨੈੱਟ ਉੱਤੇ। ਮੁੱਖ ਸਾਰਣੀ ਦਾ ਪੂਰਾ ਡੰਪ ਪੜ੍ਹਨਾ ਔਖਾ ਅਤੇ ਗਲਤ ਪੜ੍ਹਨਾ ਸੌਖਾ ਹੈ, ਕਿਉਂਕਿ ਰੂਟ ਮੌਜੂਦ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਵਧੇਰੇ ਖ਼ਾਸ ਮੇਲ ਨਾਲ ਹਾਰ ਸਕਦਾ ਹੈ। ਨੀਤੀ-ਆਧਾਰਿਤ ਰਾਊਟਿੰਗ ਵਿੱਚ ਨਿਯਮ, ਸਾਰਣੀ ਅਤੇ ਸਰੋਤ ਪਤਾ ਵੀ ਜਾਂਚ ਦਾ ਹਿੱਸਾ ਹਨ।
ip route get 10.40.7.25
ip route get 203.0.113.77
ip rule showdef1 ਕਿਸਮ ਨੂੰ ਜਾਣਨਾ ਲਾਜ਼ਮੀ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਪੁਰਾਣੀ ਡਿਫ਼ਾਲਟ ਐਂਟਰੀ ਦਿੱਖਦੀ ਰੱਖਦਾ ਹੈ ਜਦਕਿ ਅੱਧ-ਡਿਫ਼ਾਲਟ ਦੀ ਜੋੜੀ ਖੋਜ ਜਿੱਤ ਲੈਂਦੀ ਹੈ। ਇਸ ਲਈ ਆਉਟਪੁੱਟ ਵਿੱਚ 0.0.0.0/0 ਲਾਈਨ ਆਪਣੇ ਆਪ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ। ਖੋਜ ਉਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ ਜਿਸ ਦਾ ਜਵਾਬ ਸੂਚੀ ਸਿਰਫ਼ ਦਿੰਦੀ ਜਾਪਦੀ ਹੈ।
DNS, IPv6 ਅਤੇ ਪ੍ਰਾਈਵੇਟ ਰੂਟ ਨੂੰ ਅਜੇ ਵੀ ਕੰਮ ਕਰਨਾ ਹੈ
ਇੱਕ IPv4 ਰੀਡਾਇਰੈਕਟ ਇਨਕਾਰ ਕਰਨਾ ਰਿਜ਼ੌਲਵਰ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ, ਇਸ ਲਈ ਧੱਕਿਆ ਹੋਇਆ DNS ਵਿਕਲਪ ਰੂਟਾਂ ਦੇ ਸਹੀ ਦਿਸਣ ਦੌਰਾਨ ਵੀ ਸਵਾਲ ਟਨਲ ਵਿੱਚ ਭੇਜਣਾ ਜਾਰੀ ਰੱਖ ਸਕਦਾ ਹੈ। IPv6 ਡਿਫ਼ਾਲਟ ਉਸ ਪਤਾ ਪਰਿਵਾਰ ਲਈ ਇਹੀ ਕਰ ਸਕਦਾ ਹੈ ਜਿਸ ਨੂੰ IPv4 ਜਾਂਚ ਨੇ ਕਦੇ ਨਹੀਂ ਛੂਹਿਆ। ਦੋਵਾਂ ਨੂੰ ਅੰਦਾਜ਼ੇ ਦੀ ਥਾਂ ਸਪਸ਼ਟ ਫ਼ੈਸਲਾ ਚਾਹੀਦਾ ਹੈ। ਫਿਰ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਪ੍ਰਾਈਵੇਟ ਸੇਵਾ ਅਜੇ ਵੀ ਜਵਾਬ ਦਿੰਦੀ ਹੈ, ਕਿਉਂਕਿ ਪ੍ਰਾਈਵੇਟ ਰੂਟ ਗੁਆ ਚੁੱਕਿਆ ਸਪਲਿਟ ਟਨਲ ਸਪਲਿਟ ਟਨਲ ਨਹੀਂ ਹੈ, ਉਹ ਟੁੱਟਿਆ ਹੋਇਆ ਹੈ।
ਇੱਕ ਵਿਆਪਕ ਸੰਦ ਚੇਤਾਵਨੀ ਦਾ ਹੱਕਦਾਰ ਹੈ: route-nopull ਹਰ ਧੱਕਿਆ ਹੋਇਆ ਰੂਟ ਅਤੇ ਹਰ ਧੱਕਿਆ ਹੋਇਆ DNS ਵਿਕਲਪ ਸੁੱਟ ਦਿੰਦਾ ਹੈ, ਜੋ ਪੂਰਾ ਟਨਲ ਯਕੀਨੀ ਤੌਰ ਉੱਤੇ ਰੋਕਦਾ ਹੈ ਅਤੇ ਤੈਨਾਤੀ ਜਿਨ੍ਹਾਂ ਪ੍ਰਾਈਵੇਟ ਰੂਟਾਂ ਉੱਤੇ ਨਿਰਭਰ ਹੈ ਉਹਨਾਂ ਨੂੰ ਵੀ ਉੱਨੇ ਹੀ ਯਕੀਨ ਨਾਲ ਤੋੜਦਾ ਹੈ, ਇਸ ਲਈ ਇਹ ਇੱਕ ਵਿਕਲਪ ਉੱਤੇ ਨਿਸ਼ਾਨਾ ਲਾਏ ਨਾਮ-ਫਿਲਟਰ ਨਾਲੋਂ ਬਹੁਤ ਵੱਡਾ ਹਥੌੜਾ ਹੈ। ਕਿਸੇ ਵੀ ਤਬਦੀਲੀ ਤੋਂ ਬਾਅਦ ਪ੍ਰਾਈਵੇਟ ਮੰਜ਼ਿਲ, ਜਨਤਕ ਮੰਜ਼ਿਲ ਅਤੇ ਰਿਜ਼ੌਲਵਰ ਜਾਂਚੋ, ਅਤੇ ਪੂਰਾ ਹੋਇਆ ਹੈਂਡਸ਼ੇਕ ਨੂੰ ਹੈਂਡਸ਼ੇਕ ਤੋਂ ਇਲਾਵਾ ਹੋਰ ਕਿਸੇ ਚੀਜ਼ ਦਾ ਸਬੂਤ ਨਾ ਮੰਨੋ।