ਇੱਕੋ ਸਰਵਰ IP, ਦੋ ਰਾਹ: OpenVPN ਦੇ ਬਾਹਰੀ ਪ੍ਰਵਾਹ ਨੂੰ ਨਿਸ਼ਾਨ ਲਗਾਉਣਾ

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

ਉਹਨਾਂ ਦੋ ਪ੍ਰਵਾਹਾਂ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਵੱਖ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ

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

ਇਸ ਵਿਆਖਿਆ ਵਿੱਚ ਮੰਨ ਲਓ ਕਿ 10.90.0.10 'ਤੇ ਇੱਕ ਕਲਾਇੰਟ tun1 ਰਾਹੀਂ ਹੈ, ਸਰਵਰ ਦਾ ਜਨਤਕ ਪਤਾ 198.51.100.25 ਹੈ, ਅਤੇ ਮੁੱਖ ਸਾਰਣੀ ਅਛੂਤੀ ਹੈ ਜਿਸਦਾ ਡਿਫ਼ਾਲਟ ਰੂਟ ਆਮ ਅਪਲਿੰਕ ਵੱਲ ਹੈ। ਸਰਵਰ ਪਾਸੇ ਵੀ ਅੰਦਰੂਨੀ ਰਾਹ 'ਤੇ ਵੈੱਬ ਸੇਵਾ ਸਵੀਕਾਰ ਕਰਨੀ ਪੈਂਦੀ ਹੈ ਅਤੇ ਟ੍ਰੈਫ਼ਿਕ ਨੂੰ ਟਨਲ ਸਰੋਤ ਵੱਲ ਵਾਪਸ ਭੇਜਣਾ ਪੈਂਦਾ ਹੈ; ਜਨਤਕ ਪਤੇ 'ਤੇ ਪੈਕਟ ਭੇਜਣਾ ਸਰਵਰ ਦੇ ਲਿਸਨਰ ਜਾਂ ਫਾਇਰਵਾਲ ਨੀਤੀ ਨੂੰ ਰੱਦ ਨਹੀਂ ਕਰਦਾ।

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

ਲਿਫ਼ਾਫ਼ਾ ਢੋਣ ਵਾਲੇ ਸਾਕਟ ਨੂੰ ਨਿਸ਼ਾਨ ਲਗਾਓ

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

mark 42
route-noexec
disable-dco

ਦਸ਼ਮਲਵ 42 ਹੈਕਸਾਡੈਸੀਮਲ 0x2a ਹੈ, ਅਤੇ ਹੈਕਸ ਰੂਪ ਹੀ ਉਹ ਹੈ ਜਿਸ ਨਾਲ ਰਾਊਟਿੰਗ ਨਿਯਮ ਮਿਲਣਗੇ। link-options ਦਾ ਹਵਾਲਾ mark ਨੂੰ Linux 'ਤੇ ਇਨਕ੍ਰਿਪਟਡ ਬਾਹਰ ਜਾਣ ਵਾਲੇ ਪੈਕਟ 'ਤੇ ਲਾਗੂ ਹੋਣ ਵਾਲੀ ਚੀਜ਼ ਦੱਸਦਾ ਹੈ, ਭਾਵ ਠੀਕ ਉਹੀ ਸਾਕਟ ਜਿਸਦਾ ਰਾਹ ਤੁਹਾਨੂੰ ਕੰਟਰੋਲ ਕਰਨਾ ਹੈ। ਡੇਟਾ ਚੈਨਲ ਦਾ ਓਫਲੋਡ ਬੰਦ ਕਰਨ ਨਾਲ ਇਹ ਉਦਾਹਰਨ ਵਰਤੋਂਕਾਰ-ਸਪੇਸ ਰਾਹ 'ਤੇ ਰਹਿੰਦੀ ਹੈ, ਜਿੱਥੇ ਨਿਸ਼ਾਨ ਦਾ ਵਿਵਹਾਰ ਦੱਸਿਆ ਗਿਆ ਹੀ ਹੈ।

route-noexec OpenVPN ਵੱਲੋਂ ਰੂਟਾਂ ਦੇ ਆਪਣੇ-ਆਪ ਜੋੜਨ ਅਤੇ ਹਟਾਉਣ ਨੂੰ ਦਬਾ ਦਿੰਦਾ ਹੈ। ਇਹ ਉਹਨਾਂ ਦੀ ਥਾਂ ਕੁਝ ਵੀ ਸਥਾਪਤ ਨਹੀਂ ਕਰਦਾ, ਇਸ ਲਈ ਇਸ ਪਲ ਤੋਂ ਰੂਟਾਂ ਦੇ ਮਾਲਕ ਨੂੰ ਟਨਲ ਲਈ ਲੋੜੀਂਦਾ ਹਰ ਰੂਟ ਸੰਭਾਲਣਾ ਪੈਂਦਾ ਹੈ। ਜੇ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਕੋਈ ਨਿੱਜੀ ਮੰਜ਼ਿਲ ਗਾਇਬ ਹੋ ਜਾਵੇ, ਤਾਂ ਉਹ ਗੁੰਮ ਬਦਲਵੀਂ ਨੀਤੀ ਹੈ, ਨਿਸ਼ਾਨ ਦਾ ਨੁਕਸ ਨਹੀਂ।

ਇਹ ਕਰਦਿਆਂ 198.51.100.25 ਲਈ ਮੁੱਖ ਸਾਰਣੀ ਵਿੱਚ ਹੋਸਟ ਰੂਟ ਨਾ ਰੱਖੋ। ਅਜਿਹਾ ਰੂਟ ਉਹੀ ਛੋਟ ਮੁੜ ਲਿਆਉਂਦਾ ਹੈ ਜਿਸ ਨੂੰ ਡਿਜ਼ਾਈਨ ਸੰਕੁਚਿਤ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ, ਅਤੇ ਹੇਠਾਂ ਦੀ ਕਿਸੇ ਵੀ ਨੀਤੀ ਨੂੰ ਪੁੱਛਣ ਤੋਂ ਪਹਿਲਾਂ ਇਹ HTTPS ਪ੍ਰਵਾਹ ਲਈ ਜਿੱਤ ਜਾਵੇਗਾ।

ਬਾਕੀ ਸਭ ਟਨਲ ਸਾਰਣੀ ਵਿੱਚ ਭੇਜੋ

ਜਦੋਂ ਟਨਲ ਇੰਟਰਫੇਸ ਮੌਜੂਦ ਹੋਵੇ ਅਤੇ ਆਪਣਾ ਪਤਾ ਰੱਖੇ, ਨੀਤੀ ਇਵੇਂ ਦਿਸਦੀ ਹੈ:

ip -4 route add default dev tun1 src 10.90.0.10 table 47100
ip -4 rule add priority 20000 lookup main suppress_prefixlength 0
ip -4 rule add priority 20001 not fwmark 0x2a lookup 47100
ip -4 rule add priority 20002 not fwmark 0x2a unreachable

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

ਬਿਨਾਂ ਨਿਸ਼ਾਨ ਵਾਲਾ ਟ੍ਰੈਫ਼ਿਕ ਫਿਰ ਟਨਲ ਸਾਰਣੀ ਵਿੱਚ ਡਿੱਗਦਾ ਹੈ, ਟਨਲ ਸਰੋਤ ਲੈਂਦਾ ਹੈ ਅਤੇ VPN ਰਾਹੀਂ ਬਾਹਰ ਨਿਕਲਦਾ ਹੈ। ਨਿਸ਼ਾਨ ਵਾਲਾ ਟ੍ਰੈਫ਼ਿਕ ਅਗਲੇ ਦੋ ਨਿਯਮਾਂ 'ਤੇ fwmark ਪਰਖ ਵਿੱਚ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ ਅਤੇ ਸੂਚੀ ਵਿੱਚ ਹੇਠਾਂ ਵਾਲੀ ਆਮ ਮੁੱਖ ਖੋਜ ਵੱਲ ਵਧਦਾ ਹੈ, ਜਿੱਥੇ ਅਪਲਿੰਕ ਦਾ ਡਿਫ਼ਾਲਟ ਰੂਟ ਹਾਲੇ ਵੀ ਹੈ। ਆਖ਼ਰੀ unreachable ਨਿਯਮ ਉਹੀ ਹੈ ਜੋ ਟਨਲ ਰੂਟ ਨਾ ਹੋਣ 'ਤੇ ਬਿਨਾਂ ਨਿਸ਼ਾਨ ਵਾਲੇ ਪ੍ਰਵਾਹ ਨੂੰ ਚੁੱਪਚਾਪ ਅਪਲਿੰਕ 'ਤੇ ਵਾਪਸ ਡਿੱਗਣ ਤੋਂ ਰੋਕਦਾ ਹੈ। ਚੋਣਕਰਤਾ ਸ਼ੁਰੂ ਤੋਂ ਅੰਤ ਤੱਕ ਨਿਸ਼ਾਨ ਹੈ, ਅਤੇ ਮੰਜ਼ਿਲ ਪਤਾ ਕਦੇ ਫ਼ੈਸਲੇ ਵਿੱਚ ਨਹੀਂ ਆਉਂਦਾ।

ਉਸ ਰਾਖੇ ਨੂੰ ਡਿਸਕਨੈਕਟ ਦੌਰਾਨ ਥਾਂ 'ਤੇ ਰੱਖੋ, ਅਤੇ ਇਸ ਨੂੰ ਬਾਕੀ ਨੀਤੀ ਨਾਲ ਸਥਾਪਤ ਕਰੋ, ਹੱਥ ਨਾਲ ਨਹੀਂ। ਇੰਟਰਫੇਸ ਨਾਲ ਗਾਇਬ ਹੋਣ ਵਾਲਾ ਨਿਯਮ ਨੀਤੀ ਨਹੀਂ, ਸੰਜੋਗ ਹੈ। ਟਨਲ ਡਿੱਗਣ 'ਤੇ ਨੀਤੀ ਹਟਾਉਣ ਨਾਲ ਫੇਲ੍ਹ ਹੋਣ ਦਾ ਢੰਗ “ਅਵਰੋਧਿਤ” ਤੋਂ “ਲੀਕ” ਹੋ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਖ਼ਤਮ ਹੋਣ ਵਾਲਾ ਪੁਰਾਣਾ ਟਨਲ ਰੂਟ ਗ਼ਲਤ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਬਾਹਰ ਗਏ ਟ੍ਰੈਫ਼ਿਕ ਨਾਲੋਂ ਸਮਝਾਉਣਾ ਕਿਤੇ ਸੌਖਾ ਮਸਲਾ ਹੈ।

ਵਾਪਸੀ ਰਾਹ ਨੂੰ ਵੀ ਉਹੀ ਨਿਸ਼ਾਨ ਦਿਸਣ ਦਿਓ

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

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

ਢਿੱਲੀ ਵਾਪਸੀ-ਰਾਹ ਪਰਖ ਵੀ ਬਦਲ ਨਹੀਂ। ਢਿੱਲੇ ਮੋਡ ਵਿੱਚ ਵੀ ਸਰੋਤ ਲਈ ਕੋਈ ਰੂਟ ਹੋਣਾ ਲਾਜ਼ਮੀ ਹੈ, ਅਤੇ ਤੁਹਾਡਾ ਜੋੜਿਆ unreachable ਰਾਖਾ ਬਿਨਾਂ ਨਿਸ਼ਾਨ ਵਾਲੀਆਂ ਖੋਜਾਂ ਲਈ ਜਾਣ-ਬੁੱਝ ਕੇ ਇੱਕ ਹਟਾ ਦਿੰਦਾ ਹੈ। ਇਸ ਡਿਜ਼ਾਈਨ 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕਨੈਕਸ਼ਨ-ਨਿਸ਼ਾਨ ਏਕੀਕਰਨ ਪੂਰਾ ਕਰਵਾਓ ਅਤੇ ਸਮੀਖਿਆ ਕਰਵਾਓ, ਅਤੇ ਹੋਸਟ ਫਿਲਟਰਾਂ ਨੂੰ ਵੱਖਰਾ ਸਵਾਲ ਮੰਨੋ: ਨਿਸ਼ਾਨ ਰਾਊਟਿੰਗ ਸੰਕੇਤ ਹੈ, ਇਜਾਜ਼ਤ ਨਹੀਂ। ਏਕੀਕਰਨ ਨਾ ਹੋਵੇ ਤਾਂ ਲੱਛਣ ਉਹ ਸੈਸ਼ਨ ਹੈ ਜੋ ਸਥਾਪਤ ਹੁੰਦਾ ਹੈ ਅਤੇ ਫਿਰ ਜਵਾਬ ਆਉਣ ਲੱਗਿਆਂ ਹੀ ਚੁੱਪ ਹੋ ਜਾਂਦਾ ਹੈ।

ਦੋ ਰੂਟ ਖੋਜਾਂ ਨਾਲ ਇਹ ਸਾਬਤ ਕਰੋ

ਕਰਨਲ ਦੋ ਸੰਦਰਭਾਂ ਲਈ ਕੀ ਫ਼ੈਸਲਾ ਕਰਦਾ ਹੈ ਦੀ ਤੁਲਨਾ ਕਰੋ, ਅਤੇ ਨਿਕਾਸ ਸਥਿਤੀ ਦੀ ਥਾਂ dev ਅਤੇ src ਖੇਤਰ ਪੜ੍ਹੋ:

ip -4 route get 198.51.100.25
ip -4 route get 198.51.100.25 mark 0x2a

ਪਹਿਲੀ ਖੋਜ ਟਨਲ ਸਰੋਤ ਨਾਲ tun1 'ਤੇ ਹੱਲ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ ਦੂਜੀ ਅਪਲਿੰਕ 'ਤੇ। ਇਹ ਨਕਲੀ ਖੋਜਾਂ ਹਨ, ਇਸ ਲਈ ਇਹ ਨੀਤੀ ਸਾਬਤ ਕਰਦੀਆਂ ਹਨ, ਚੱਲ ਰਹੀ ਪ੍ਰਕਿਰਿਆ ਨਹੀਂ: ਚੱਲ ਰਹੇ ਕਲਾਇੰਟ ਦਾ ਅਸਲੀ ਆਵਾਜਾਈ ਰਾਹ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਪੁਸ਼ਟੀ ਕਰੋ, ਫਿਰ ਸਰਟੀਫਿਕੇਟ ਪਰਖ ਚਾਲੂ ਰੱਖਦਿਆਂ ਸੱਚੀ HTTPS ਬੇਨਤੀ ਕਰੋ।

ਪੂਰਾ ਐਲਾਨਣ ਤੋਂ ਪਹਿਲਾਂ ਲਿਖੋ ਕਿ ਡਿਜ਼ਾਈਨ ਕੀ ਨਹੀਂ ਢੱਕਦਾ। DNS, IPv6 ਅਤੇ ਨਿਯਮਾਂ ਦਾ ਜੀਵਨ-ਚੱਕਰ ਹਰ ਇੱਕ ਨੂੰ ਆਪਣਾ ਫ਼ੈਸਲਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਇਹ IPv4 ਰਾਊਟਿੰਗ ਦੀ ਉਦਾਹਰਨ ਹੈ, ਪੂਰੀ ਨਿਜਤਾ ਸੰਰਚਨਾ ਨਹੀਂ। ਇਸਦਾ ਮੁੱਲ ਚੋਣਕਰਤਾ ਹੈ: ਲਿਫ਼ਾਫ਼ੇ ਨੂੰ ਅਪਲਿੰਕ ਦੀ ਛੋਟ ਮਿਲਦੀ ਹੈ, ਅਤੇ ਉਸੇ ਪਤੇ ਦੀ ਆਮ ਸੇਵਾ ਨੂੰ ਇਹ ਵਿਰਾਸਤ ਵਿੱਚ ਲੈਣ ਦੀ ਲੋੜ ਨਹੀਂ।