Linux VPN ਦੇ ਜਵਾਬ ਗਾਇਬ ਹੋ ਰਹੇ ਹਨ? rp_filter ਅਤੇ ਰੂਟ ਜਾਂਚੋ

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

ਸਰੋਤ ਪ੍ਰਮਾਣਿਕਤਾ ਕੀ ਤੈਅ ਕਰਦੀ ਹੈ

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

ਮਹੱਤਵਪੂਰਨ ਸ਼ਬਦ ਭਰੋਸੇਯੋਗ ਹੈ। ਪੈਕਟ ਪੂਰੀ ਤਰ੍ਹਾਂ ਜਾਇਜ਼ ਹੋ ਕੇ ਵੀ ਜਾਂਚ ਵਿੱਚ ਫੇਲ ਹੋ ਸਕਦਾ ਹੈ, ਕਿਉਂਕਿ ਜਾਇਜ਼ਤਾ ਜਾਂਚੀ ਨਹੀਂ ਜਾਂਦੀ।

ਪ੍ਰਭਾਵੀ ਮੋਡ ਪੜ੍ਹੋ, ਇੱਕ ਫੀਲਡ ਨਹੀਂ

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

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.<iface>.rp_filter
ip route get <source-of-the-reply>

ਤੀਜੀ ਲਾਈਨ ਵਿੱਚ ਰੂਟ ਦੀ ਖੋਜ ਉਹ ਹਿੱਸਾ ਹੈ ਜੋ ਲੋਕ ਛੱਡ ਦਿੰਦੇ ਹਨ। ਇਹ ਦੱਸਦੀ ਹੈ ਕਿ ਕਰਨਲ ਸਰੋਤ ਬਾਰੇ ਕੀ ਮੰਨਦਾ ਹੈ, ਅਤੇ ਇਹੀ ਜਾਂਚ ਦਾ ਇਨਪੁਟ ਹੈ।

ਜਾਂਚ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਅਸੰਗਤੀ ਲੱਭੋ

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

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

ਪਹਿਲੀ ਪ੍ਰਤੀਕਿਰਿਆ ਵਜੋਂ ਸਰੋਤ ਜਾਂਚਾਂ ਗਲੋਬਲ ਤੌਰ ਉੱਤੇ ਬੰਦ ਨਾ ਕਰੋ। ਇਹ ਇੱਕ ਠੋਸ ਨਿਦਾਨ ਦੇ ਬਦਲੇ ਵਿਆਪਕ ਵਿਵਹਾਰ ਬਦਲਾਅ ਦਿੰਦਾ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਬਾਅਦ ਵਿੱਚ ਯਾਦ ਰੱਖਣਾ ਪਵੇਗਾ।

ਇੱਕ ਚੁਣਿਆ ਹੋਇਆ ਸਮਾਯੋਜਨ ਜਿਸਦਾ ਤੁਸੀਂ ਬਚਾਅ ਕਰ ਸਕਦੇ ਹੋ

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

ਅਜੇ ਵੀ ਰੱਦ ਹੋਣਾ ਚਾਹੀਦਾ ਕੇਸ ਸ਼ਾਮਲ ਕਰੋ। ਜੇ ਉਹ ਕੇਸ ਹੁਣ ਸਫਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਸਮਾਯੋਜਨ ਨੇ ਉਸ ਇੱਕ ਮਾਰਗ ਨਾਲੋਂ ਵੱਧ ਕਮਜ਼ੋਰ ਕੀਤਾ ਜਿਸਨੂੰ ਤੁਸੀਂ ਠੀਕ ਕਰਨਾ ਚਾਹੁੰਦੇ ਸੀ।

IPv4 ਅਤੇ IPv6 ਨੂੰ ਵੱਖਰੇ ਰੱਖੋ

ਜਾਣਿਆ-ਪਛਾਣਿਆ ਦਿਖਣ ਵਾਲਾ sysctl ਹਰ ਪਤਾ-ਪਰਿਵਾਰ ਲਈ ਨੀਤੀ ਨਹੀਂ ਹੈ। IPv6 ਦਾ ਆਪਣਾ ਵਿਵਹਾਰ ਅਤੇ ਆਪਣੀਆਂ ਸੈਟਿੰਗਾਂ ਹਨ, ਅਤੇ ਇੱਕ ਮਸ਼ੀਨ ਇੱਕ ਪਰਿਵਾਰ ਵਿੱਚ ਸਖ਼ਤ ਅਤੇ ਦੂਜੇ ਵਿੱਚ ਨਰਮ ਹੋ ਸਕਦੀ ਹੈ, ਜਦੋਂ ਤੱਕ ਕੋਈ ਖ਼ਾਸ ਮੰਜ਼ਿਲ ਫੇਲ ਨਾ ਹੋਵੇ ਕਿਸੇ ਨੂੰ ਪਤਾ ਨਹੀਂ ਲੱਗਦਾ। ਜੇ ਵਰਕਲੋਡ ਦੋਵੇਂ ਵਰਤਦਾ ਹੈ ਤਾਂ ਦੋਵੇਂ ਜਾਂਚੋ।

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