127.0.0.1 ਵੱਲ DNAT ਨੂੰ ਖ਼ਾਸ ਸਾਵਧਾਨੀ ਕਿਉਂ ਲੋੜੀਂਦੀ ਹੈ

ਇੱਕ ਸੇਵਾ 127.0.0.1:1080 ਉੱਤੇ ਸੁਣ ਰਹੀ ਹੈ। DNAT ਨਿਯਮ ਆਉਂਦੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਉਸ ਪਤੇ ਵੱਲ ਭੇਜਦਾ ਹੈ, ਪਰ ਕਨੈਕਸ਼ਨ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ। ਸੇਵਾ ਸਿਹਤਮੰਦ ਹੋ ਸਕਦੀ ਹੈ ਅਤੇ NAT ਨਿਯਮ ਮੇਲ ਵੀ ਖਾ ਸਕਦਾ ਹੈ: IPv4 ਲੂਪਬੈਕ ਪਤਿਆਂ ਨੂੰ ਰੂਟਿੰਗ ਵਿੱਚ ਖ਼ਾਸ ਵਿਵਹਾਰ ਮਿਲਦਾ ਹੈ।

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

ਇਸੇ ਲਈ ਕਿਸੇ ਹੋਰ ਮਸ਼ੀਨ ਦਾ ਕੰਮ ਕਰਦਾ ਨਿਯਮ ਉਸ sysctl ਉੱਤੇ ਨਿਰਭਰ ਹੋ ਸਕਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਕਾਪੀ ਨਹੀਂ ਕੀਤਾ। ਪਰ ਇਹ ਇਸ ਵਿਕਲਪ ਨੂੰ ਹਰ ਥਾਂ ਚਾਲੂ ਕਰਨ ਦਾ ਜਾਇਜ਼ ਨਹੀਂ ਬਣਾਉਂਦਾ।

ਸੁਰੱਖਿਆ ਧਾਰਨਾ ਰਾਹ ਨਾਲ ਬਦਲਦੀ ਹੈ

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

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

rp_filter ਸਰੋਤ-ਰਾਹ ਪੜਤਾਲ ਬਾਰੇ ਇੱਕ ਵੱਖਰੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਇਸਨੂੰ ਦੁਨੀਆ ਭਰ ਵਿੱਚ ਬੰਦ ਕਰਨਾ ਲੂਪਬੈਕ ਰੂਟਿੰਗ ਸਮਝਣ ਦਾ ਆਮ ਬਦਲ ਨਹੀਂ ਹੈ। ਇਸੇ ਤਰ੍ਹਾਂ ip_nonlocal_bind ਸਾਕਟਾਂ ਨੂੰ ਗੈਰ-ਸਥਾਨਕ ਪਤਿਆਂ ਨਾਲ ਬੰਨ੍ਹਣ ਬਾਰੇ ਹੈ, ਇਸ DNAT ਰਾਹ ਨੂੰ ਸਹੀ ਬਣਾਉਣ ਬਾਰੇ ਨਹੀਂ।

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