OpenWrt ਪਾਲਿਸੀ ਰਾਊਟਿੰਗ: ਸਥਾਨਕ DNS ਫੜਨ ਵਾਲੀ ਚੇਨ

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

ਦੋ ਫਲੋ, ਇੱਕ ਰਿਜ਼ਾਲਵਰ ਪਤਾ

ਪਹਿਲਾ ਫਲੋ ਉਹ ਹੈ ਜੋ ਲੋਕ ਕਲਪਨਾ ਕਰਦੇ ਹਨ। ਕਲਾਇੰਟ ਰਾਊਟਰ ਦੇ ਰਿਜ਼ਾਲਵਰ ਨੂੰ ਪੁੱਛਦਾ ਹੈ, ਰਿਜ਼ਾਲਵਰ ਉੱਪਰ ਵੱਲ ਫਾਰਵਰਡ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਹ ਫਾਰਵਰਡ ਕੀਤਾ ਪੈਕਟ ਬਾਹਰ ਜਾਂਦਿਆਂ ਰਾਊਟਰ ਵਿੱਚੋਂ ਲੰਘਦਾ ਹੈ। ਉਹ ਪੈਕਟ ਫਾਰਵਰਡ ਕੀਤੇ ਟ੍ਰੈਫ਼ਿਕ ਨੂੰ ਦੇਖਣ ਵਾਲੀ ਹਰ ਚੀਜ਼ ਲਈ ਦਿਖਦਾ ਹੈ।

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

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

ਫਾਰਵਰਡ ਕੀਤੇ ਅਤੇ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਬਣੇ ਪੈਕਟ ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਦਾਖਲ ਹੁੰਦੇ ਹਨ

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

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

ਇਹ ਇਸ ਗੱਲ ਦਾ ਗੁਣ ਹੈ ਕਿ ਪੈਕਟ ਕਿੱਥੇ ਜੰਮਦੇ ਹਨ, ਕਿਸੇ ਖ਼ਾਸ ਪੈਕੇਜ ਦਾ ਨਹੀਂ। ਇੱਕ ਚੇਨ ਲਈ ਲਿਖੇ ਨਿਯਮ ਦੀ ਦੂਜੇ ਬਾਰੇ ਬੱਸ ਕੋਈ ਰਾਏ ਨਹੀਂ ਹੁੰਦੀ। ਕੋਈ ਵੀ ਨਿਯਮ ਟਿਊਨਿੰਗ ਇਸਨੂੰ ਨਹੀਂ ਬਦਲਦੀ।

ਆਉਟਪੁੱਟ ਚੇਨ ਚੁਣੋ, ਫਿਰ ਮੇਲ ਨੂੰ ਤੰਗ ਕਰੋ

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

ਫਿਰ ਤੰਗ ਕਰੋ ਕਿ ਨਿਯਮ ਕਿਸ ਨਾਲ ਮਿਲਦਾ ਹੈ। ਰਿਜ਼ਾਲਵਰ ਜੋ ਪੋਰਟ ਅਸਲ ਵਿੱਚ ਵਰਤਦਾ ਹੈ ਉਸ ਉੱਤੇ ਮੰਜ਼ਿਲ ਰਿਜ਼ਾਲਵਰ ਪਤੇ, ਰਾਊਟਰ ਜੋ ਕੁਝ ਬਣਾਉਂਦਾ ਹੈ ਸਭ ਟਨਲ ਵਿੱਚ ਭੇਜਣ ਨਾਲੋਂ ਕਿਤੇ ਛੋਟਾ ਫ਼ੈਸਲਾ ਹਨ।

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

ਟਨਲ ਦਾ ਆਪਣਾ ਟਰਾਂਸਪੋਰਟ ਨਿਯਮ ਤੋਂ ਬਾਹਰ ਰੱਖੋ

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

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

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

ਇੱਕ ਨਹੀਂ, ਦੋਵੇਂ ਆਬਾਦੀਆਂ ਦੀ ਜਾਂਚ ਕਰੋ

ਰਾਊਟਰ ਨੂੰ ਆਪਣੀ ਕਿਊਰੀ ਕਰਦਿਆਂ ਦੇਖੋ ਅਤੇ ਨੋਟ ਕਰੋ ਕਿ ਕਿਹੜੇ ਇੰਟਰਫ਼ੇਸ ਨੇ ਇਸਨੂੰ ਢੋਇਆ। LAN ਹੋਸਟ ਤੋਂ ਲੁਕਅੱਪ ਦੁਹਰਾਓ ਅਤੇ ਨੋਟ ਕਰੋ ਕਿ ਇਸਨੇ ਕਿਹੜਾ ਰਾਹ ਲਿਆ। ਪਾਲਿਸੀ ਨਿਯਮਾਂ ਦੇ ਕਾਊਂਟਰ ਅੰਦਾਜ਼ੇ ਬਿਨਾਂ ਦੋਵੇਂ ਜਵਾਬ ਦਿਖਾ ਦਿੰਦੇ ਹਨ।

ਨਤੀਜਿਆਂ ਨੂੰ ਦੋ ਅਲੱਗ ਖੋਜਾਂ ਵਾਂਗ ਲਓ। ਟਨਲ ਰਾਹੀਂ ਹੱਲ ਕਰਨ ਵਾਲਾ ਕਲਾਇੰਟ ਰਾਊਟਰ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ, ਅਤੇ ਸਹੀ ਹੱਲ ਕਰਨ ਵਾਲਾ ਰਾਊਟਰ ਕਿਸੇ ਹੋਰ ਲਿਸਨਰ ਉੱਤੇ ਬੈਠੇ ਕਲਾਇੰਟ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ। ਉਨ੍ਹਾਂ ਨੂੰ ਤਬਦੀਲੀ ਰਿਕਾਰਡ ਵਿੱਚ ਅਲੱਗ ਲਾਈਨਾਂ ਵਜੋਂ ਲਿਖੋ।

ਪੋਰਟ ਵੀ ਜਾਂਚੋ: ਮੰਜ਼ਿਲ ਪੋਰਟ 53 ਨਾਲ ਮਿਲਣ ਵਾਲਾ ਨਿਯਮ 853 ਉੱਤੇ DNS over TLS ਜਾਂ HTTPS ਅੰਤ ਬਿੰਦੂ ਰਾਹੀਂ ਪਹੁੰਚਣ ਵਾਲੇ ਰਿਜ਼ਾਲਵਰ ਨੂੰ ਖੁੰਝਾ ਦਿੰਦਾ ਹੈ। ਕਨਫਿਗਰ ਕੀਤੇ ਅਪਸਟਰੀਮ ਵੱਲੋਂ ਅਸਲ ਵਿੱਚ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਟਰਾਂਸਪੋਰਟ ਨਾਲ ਮਿਲਾਓ, ਅਤੇ ਲੀਕ ਸਹੀ ਕਾਰਨ ਨਾਲ ਬੰਦ ਹੁੰਦੀ ਹੈ।