VPN ਅੰਦਰ mDNS: .local ਨਾਮ ਕਿਉਂ ਹੱਲ ਨਹੀਂ ਹੁੰਦੇ

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

ਜਾਂਚੋ ਕਿ ਅੱਜ ਕੀ ਹੱਲ ਹੁੰਦਾ ਹੈ ਅਤੇ ਕੀ ਸਿਰਫ਼ ਹੱਲ ਹੋਇਆ ਦਿਖਦਾ ਹੈ

ਪਹਿਲਾਂ ਦੋ ਸਵਾਲ ਵੱਖ ਕਰੋ: ਹੋਸਟਨਾਮ ਲਈ unicast ਕਿਉਰੀ ਰਿਜ਼ੌਲਵਰ ਨੂੰ ਪੁੱਛਦੀ ਹੈ, ਜਦਕਿ _ipp._tcp ਲਈ ਬ੍ਰਾਊਜ਼ ਸਥਾਨਕ ਲਿੰਕ ਨੂੰ ਪੁੱਛਦਾ ਹੈ। Linux ਤੇ, avahi-browse -a ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਮਲਟੀਕਾਸਟ DNS ਕੀ ਦੇਖ ਸਕਦਾ ਹੈ, ਅਤੇ resolvectl query name.local ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਰਿਜ਼ੌਲਵਰ ਸਟੈਕ ਉਸ ਨਾਮ ਨਾਲ ਕੀ ਕਰਦਾ ਹੈ। macOS ਤੇ, dns-sd -B _ipp._tcp ਪਹਿਲਾਂ ਪਤੇ ਦੀ ਲੋੜ ਤੋਂ ਬਿਨਾਂ ਖੋਜੀਆਂ ਸੇਵਾਵਾਂ ਦੀ ਸੂਚੀ ਬਣਾਉਂਦਾ ਹੈ।

ਜੇ ਪਤਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਅਤੇ ਨਾਮ ਨਹੀਂ, ਤਾਂ ਰੂਟਿੰਗ ਕੰਮ ਕਰਦੀ ਹੈ ਅਤੇ ਖੋਜ ਨਹੀਂ ਕਰਦੀ। .local ਨਾਮ ਹੋਸਟ ਉੱਤੇ ਹੀ nss-mdns ਰਾਹੀਂ ਜਵਾਬ ਦਿੱਤਾ ਜਾ ਸਕਦਾ ਹੈ ਭਾਵੇਂ avahi-browse ਇੰਸਟਾਲ ਨਾ ਹੋਵੇ, ਇਸ ਲਈ ਉਸ ਨਾਮ ਨੂੰ ਸਫਲ getent ਜਾਂ ਪਿੰਗ ਇਸ ਦਾ ਸਬੂਤ ਨਹੀਂ ਕਿ ਖੋਜ ਨੇ ਸੁਰੰਗ ਪਾਰ ਕੀਤੀ; ਬ੍ਰਾਊਜ਼ ਨਤੀਜਾ ਅਤੇ ਰਿਜ਼ੌਲਵਰ ਨਤੀਜਾ ਵੱਖਰੇ ਸਬੂਤ ਹਨ। ਐਪਾਂ ਜੋ ਖੋਜਿਆ ਉਸਨੂੰ ਕੈਸ਼ ਕਰਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਨੁਕਸ ਅਕਸਰ ਕਨੈਕਟ ਹੋਣ ਤੋਂ ਘੰਟਿਆਂ ਬਾਅਦ ਦਿਖਦਾ ਹੈ, ਕਨੈਕਟ ਹੁੰਦਿਆਂ ਨਹੀਂ। ਐਪ ਬੰਦ ਕਰਕੇ ਦੁਬਾਰਾ ਖੋਲ੍ਹੋ, ਫਿਰ ਵੇਖੋ ਕਿ ਕੈਸ਼ ਕੀਤੀ ਐਂਟਰੀ ਵਿੱਚ ਨਾਮ ਹੈ ਜਾਂ ਪਤਾ, ਕਿਉਂਕਿ ਖੋਜ ਰੁਕਣ ਤੋਂ ਬਾਅਦ ਵੀ ਪਤਾ ਲੰਬਾ ਸਮਾਂ ਕੰਮ ਕਰਦਾ ਹੈ।

ਕਿਉਰੀ ਕਦੇ ਸੁਰੰਗ ਪਾਰ ਕਿਉਂ ਨਹੀਂ ਕਰਦੀ

ਮਲਟੀਕਾਸਟ DNS ਕਿਉਰੀਆਂ 224.0.0.251 ਤੇ, ਸਥਾਨਕ ਨੈੱਟਵਰਕ ਕੰਟਰੋਲ ਬਲਾਕ ਦੇ ਅੰਦਰ, UDP ਪੋਰਟ 5353 ਉੱਤੇ ਭੇਜਦਾ ਹੈ। ਰਾਊਟਰ ਉਸ ਬਲਾਕ ਦੇ ਪਤੇ ਫਾਰਵਰਡ ਨਹੀਂ ਕਰਦੇ, ਇਸ ਲਈ ਕਿਉਰੀ ਉਸੇ ਲਿੰਕ ਤੇ ਰਹਿੰਦੀ ਹੈ ਜਿੱਥੇ ਭੇਜੀ ਗਈ ਸੀ। ਭੇਜਣ ਵਾਲੇ IP TTL ਜਾਂ IPv6 ਹੌਪ ਸੀਮਾ ਨੂੰ 255 ਤੇ ਸੈੱਟ ਕਰਦੇ ਹਨ ਤਾਂ ਜੋ ਪ੍ਰਾਪਤਕਰਤਾ ਪਹਿਲਾਂ ਹੀ ਰਾਊਟਰ ਪਾਰ ਕਰ ਚੁੱਕੇ ਪੈਕੇਟ ਨੂੰ ਰੱਦ ਕਰ ਸਕੇ; ਪ੍ਰੋਟੋਕੋਲ ਲਿੰਕ ਤੋਂ ਬਾਹਰ ਦੀ ਜਾਅਲਸਾਜ਼ੀ ਇੰਝ ਪਛਾਣਦਾ ਹੈ, ਇੰਝ ਨਹੀਂ ਕਿ ਉਹ ਸਥਾਨਕ ਰਹਿੰਦਾ ਹੈ। ਸਥਾਨਕਤਾ ਮੰਜ਼ਿਲ ਪਤੇ ਤੋਂ ਆਉਂਦੀ ਹੈ, ਇੱਕ-ਹੌਪ TTL ਤੋਂ ਨਹੀਂ।

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

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

ਅਜਿਹਾ ਨਾਮਕਰਨ ਡਿਜ਼ਾਈਨ ਚੁਣੋ ਜੋ ਤੁਸੀਂ ਸਾਂਭ ਸਕੋ

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

ਇੱਕ ਡਿਸਕਵਰੀ ਪ੍ਰੌਕਸੀ ਜਾਂ mDNS ਰਿਫਲੈਕਟਰ ਇਸ ਖਾਲੀ ਥਾਂ ਨੂੰ ਪੁਲ ਬਣਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਹ ਆਪਣੇ ਹੋਸਟ, ਆਪਣੇ ਐਕਸਪੋਜ਼ਰ ਅਤੇ ਆਪਣੀਆਂ ਕਲਾਇੰਟ ਲੋੜਾਂ ਵਾਲਾ ਅਸਲੀ ਡਿਜ਼ਾਈਨ ਹੈ। ਤੁਸੀਂ ਰੂਟ ਜੋੜਿਆ ਇਸ ਲਈ ਇਹ ਦਿਖਦਾ ਨਹੀਂ। .local ਕਿਉਰੀਆਂ ਕਦੇ ਵੀ ਸਾਰਵਜਨਿਕ ਰਿਜ਼ੌਲਵਰ ਨੂੰ ਫਾਰਵਰਡ ਨਾ ਕਰੋ: ਡੋਮੇਨ RFC 6762 ਵੱਲੋਂ ਸਥਾਨਕ ਮਲਟੀਕਾਸਟ ਵਰਤੋਂ ਲਈ ਰਾਖਵਾਂ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਬਾਹਰ ਭੇਜਣ ਨਾਲ ਹੌਲੀ ਅਸਫਲਤਾਵਾਂ ਅਤੇ ਬੇਲੋੜਾ ਡੇਟਾ ਖੁਲਾਸਾ ਹੁੰਦਾ ਹੈ।

ਨਾਮ ਨਹੀਂ, ਸੇਵਾ ਜਾਂਚੋ

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

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