ਕੀ ਤੁਹਾਡੇ ਵੈੱਬ ਸਰਵਰ 'ਤੇ VPN ਕਲਾਇੰਟ ਇਸ ਦੇ ਜਵਾਬ ਤੋੜਦਾ ਹੈ?

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

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

ਲੱਛਣ: ਇਹ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਬਾਹਰੋਂ ਨਹੀਂ

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

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

ਕੰਮ ਕਰਦਿਆਂ ਇੱਕ ਸੁਤੰਤਰ ਪ੍ਰਬੰਧਕੀ ਰਾਹ ਖੁੱਲ੍ਹਾ ਰੱਖੋ। ਜੋ ਨਿਯਮ ਤੁਹਾਡੇ ਆਪਣੇ SSH ਸੈਸ਼ਨ ਨੂੰ ਤੋੜਦਾ ਹੈ, ਉਹ ਦਸ ਮਿੰਟ ਦੀ ਸੋਧ ਨੂੰ ਭੌਤਿਕ ਫੇਰੀ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।

ਸਰੋਤ ਚੋਣਕਰਤਾ ਅਸਲ ਵਿੱਚ ਕਿਸ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ

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

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

ਤਰਜੀਹ ਨਤੀਜਾ ਤੈਅ ਕਰਦੀ ਹੈ। ਖੋਜਾਂ ਕ੍ਰਮ ਵਿੱਚ ਚੱਲਦੀਆਂ ਹਨ ਅਤੇ ਨਤੀਜਾ ਦੇਣ ਵਾਲੀ ਪਹਿਲੀ ਸਾਰਣੀ ਖੋਜ ਖਤਮ ਕਰ ਸਕਦੀ ਹੈ, ਇਸ ਲਈ ਬਹੁਤ ਜਲਦੀ ਰੱਖਿਆ ਨਿਯਮ ਉਸ ਵਧੇਰੇ ਖਾਸ ਰਾਹ ਨੂੰ ਲੁਕਾ ਸਕਦਾ ਹੈ ਜੋ ਬਾਅਦ ਦੀ ਸਾਰਣੀ ਦਿੰਦੀ। ਤੁਸੀਂ ਜੋੜੀ ਇੱਕ ਲਾਈਨ ਨਹੀਂ ਬਲਕਿ ਪੂਰੀ ਕ੍ਰਮਬੱਧ ਸੂਚੀ ਪੜ੍ਹੋ। ਜੋ ਨਿਯਮ ਕਦੇ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ ਉਸ ਦੀ ਕੋਈ ਕੀਮਤ ਨਹੀਂ, ਜਦਕਿ ਬਹੁਤ ਜਲਦੀ ਮੇਲ ਖਾਣ ਵਾਲਾ ਆਪਣੇ ਪਿੱਛੇ ਦਾ ਸਭ ਕੁਝ ਚੁੱਪਚਾਪ ਬਦਲ ਦਿੰਦਾ ਹੈ।

ਵਾਪਸੀ ਦਾ ਰਾਹ ਅਤੇ ਤੁਹਾਡੇ ਦੁਆਰਾ ਨਾ ਸੋਚਿਆ ਟ੍ਰੈਫਿਕ ਜਾਂਚੋ

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

ip rule show
ip route show table 100
ip route get 203.0.113.44 from 192.168.50.2
ss -ltnp '( sport = :443 )'

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

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

ਛੋਟ ਕਿੰਨੀ ਤੰਗ ਹੋ ਸਕਦੀ ਹੈ, ਇਹ ਤੈਅ ਕਰੋ

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

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

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