LAN ਹੋਸਟਨਾਮ VPN ਉੱਤੇ ਕੰਮ ਨਹੀਂ ਕਰਦਾ: ਸਫਿਕਸ, mDNS ਜਾਂ ਜ਼ੋਨ?
ਛੋਟਾ ਨਾਮ ਖੋਜ ਸਫਿਕਸ ਉੱਤੇ ਨਿਰਭਰ ਹੋ ਸਕਦਾ ਹੈ, .local ਨਾਮ ਮਲਟੀਕਾਸਟ ਉੱਤੇ ਅਤੇ ਕੰਪਨੀ ਦਾ ਨਾਮ ਨਿੱਜੀ ਜ਼ੋਨ ਉੱਤੇ। ਸਿਰਫ਼ ਰੂਟ ਕੋਈ ਨਾਮਕਰਨ ਸੇਵਾ ਨਹੀਂ ਦਿੰਦਾ।
ਡਿਵਾਈਸ ਦੇ ਕੋਲ ਪ੍ਰਿੰਟਰ ਇੱਕ ਛੋਟੇ ਨਾਮ ਉੱਤੇ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਅਤੇ ਫਾਈਲ ਸਰਵਰ ਇੱਕ ਉਪਨਾਮ ਉੱਤੇ। ਸੁਰੰਗ ਵਿੱਚੋਂ ਦੋਵੇਂ ਨਾਮ ਸਮਾਂ-ਸੀਮਾ ਪਾਰ ਕਰ ਜਾਂਦੇ ਹਨ, ਜਦੋਂ ਕਿ ਉਨ੍ਹਾਂ ਦੇ ਪਤੇ ਅਜੇ ਵੀ ਕੰਮ ਕਰਦੇ ਹਨ। ਰੂਟ ਆਪਣਾ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ; ਜਿਸ ਨਾਮਕਰਨ ਮਾਰਗ ਨੇ ਉਨ੍ਹਾਂ ਛੋਟੇ ਨਾਮਾਂ ਨੂੰ ਕੰਮ ਕਰਵਾਇਆ ਸੀ, ਉਹ ਕਦੇ ਸੁਰੰਗ ਪਾਰ ਨਹੀਂ ਕੀਤਾ। ਤਿੰਨ ਕਾਰਜਵਿਧੀਆਂ ਇਹ ਵਿਵਹਾਰ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਹਰ ਇੱਕ ਲਈ ਵੱਖਰਾ ਸੁਧਾਰ ਚਾਹੀਦਾ ਹੈ।
ਨਾਮ ਕਿਸ ਕਾਰਜਵਿਧੀ ਉੱਤੇ ਨਿਰਭਰ ਹੈ, ਇਹ ਪਛਾਣ ਕੇ ਸ਼ੁਰੂ ਕਰੋ।
ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਵਿਵਹਾਰ ਕਰਨ ਵਾਲੇ ਤਿੰਨ ਕਿਸਮ ਦੇ ਨਾਮ
fileserver ਵਰਗਾ ਇੱਕ-ਲੇਬਲ ਨਾਮ ਆਮ ਤੌਰ ਉੱਤੇ ਰਿਜ਼ੋਲਵਰ ਵੱਲੋਂ ਜੋੜੇ ਜਾਂਦੇ DNS ਖੋਜ ਸਫਿਕਸ ਉੱਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਉਹ ਸਫਿਕਸ ਅਕਸਰ ਸਥਾਨਕ DHCP ਲੀਜ਼ ਨਾਲ ਆਉਂਦਾ ਹੈ, ਇਸ ਲਈ VPN ਤੋਂ ਪਤਾ ਲੈਣ ਵਾਲੇ ਦੂਰਸਥ ਕਲਾਇੰਟ ਨੂੰ ਇਹ ਜਾਣਨ ਦਾ ਕੋਈ ਕਾਰਨ ਨਹੀਂ। ਰੂਟ ਜੋੜਨ ਨਾਲ ਸਫਿਕਸ ਨਹੀਂ ਪਹੁੰਚਦਾ। ਛੋਟਾ ਨਾਮ ਨਾਮ ਵਜੋਂ ਰਹਿਣਾ ਹੀ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ, ਭਾਵੇਂ ਇਸਦੇ ਪਿੱਛੇ ਦਾ ਪਤਾ ਪਹੁੰਚਯੋਗ ਹੋਵੇ।
.local ਨਾਲ ਖ਼ਤਮ ਹੋਣ ਵਾਲਾ ਨਾਮ ਆਮ ਤੌਰ ਉੱਤੇ ਸਥਾਨਕ ਲਿੰਕ ਉੱਤੇ ਮਲਟੀਕਾਸਟ DNS ਰਾਹੀਂ ਹੱਲ ਹੁੰਦਾ ਹੈ, ਜਿਵੇਂ RFC 6762 ਦੱਸਦਾ ਹੈ। ਮਲਟੀਕਾਸਟ ਰੂਟ ਕੀਤੀ ਸੁਰੰਗ ਪਾਰ ਨਹੀਂ ਕਰਦਾ, ਜਦੋਂ ਤੱਕ ਕੋਈ ਜਾਣ-ਬੁੱਝ ਕੇ ਇਸਨੂੰ ਬ੍ਰਿਜ ਜਾਂ ਪ੍ਰੌਕਸੀ ਨਾ ਕਰੇ, ਇਸ ਲਈ ਜਦੋਂ ਤੁਸੀਂ ਸੈਗਮੈਂਟ ਛੱਡਦੇ ਹੋ ਤਾਂ ਨਾਮ ਹੱਲ ਹੋਣਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ।
ਪੂਰੀ ਤਰ੍ਹਾਂ ਯੋਗ ਕੰਪਨੀ ਦਾ ਨਾਮ ਸੰਗਠਨ ਦੇ ਰਿਜ਼ੋਲਵਰਾਂ ਵੱਲੋਂ ਸੇਵਾ ਦਿੱਤੇ ਜਾਂਦੇ ਅੰਦਰੂਨੀ ਜ਼ੋਨ ਦਾ ਹੁੰਦਾ ਹੈ। VPN ਉਹ ਰਿਜ਼ੋਲਵਰ ਪੁਸ਼ ਕਰਦਾ ਹੈ ਅਤੇ ਕਲਾਇੰਟ ਉਨ੍ਹਾਂ ਨੂੰ ਵਰਤਣ ਲਈ ਸੰਰਚਿਤ ਹੋਵੇ ਤਾਂ ਇਹ ਦੂਰੋਂ ਕੰਮ ਕਰਦਾ ਹੈ। ਅਤੇ localhost RFC 6761 ਅਨੁਸਾਰ ਵਿਸ਼ੇਸ਼-ਵਰਤੋਂ ਦਾ ਹੈ: ਇਹ ਤੁਹਾਡੇ ਸਾਹਮਣੇ ਵਾਲੀ ਮਸ਼ੀਨ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, ਕਦੇ ਵੀ ਦੂਰਸਥ ਸੇਵਾ ਵੱਲ ਨਹੀਂ।
ਰੂਟ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਰਿਜ਼ੋਲਵਰ ਪੜ੍ਹੋ
ਪੁੱਛੋ ਕਿ ਕਿਹੜੇ ਨਾਮ ਸਰਵਰ ਨੇ ਜਵਾਬ ਦਿੱਤਾ ਅਤੇ ਕਿਹੜਾ ਸਫਿਕਸ ਜੋੜਿਆ ਗਿਆ। ਵੱਖਰੇ ਰਿਜ਼ੋਲਵਰਾਂ ਰਾਹੀਂ ਉਹੀ ਕਵੈਰੀ ਵੱਖਰੇ ਜਵਾਬ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਉਹੀ ਫ਼ਰਕ ਤੁਹਾਨੂੰ ਲੋੜੀਂਦਾ ਸਬੂਤ ਹੈ।
getent hosts fileserver getent hosts fileserver.corp.example.com nslookup fileserver.corp.example.com dig +search fileserver A resolvectl query fileserver.corp.example.com scutil --dns | head -30
ਜੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਯੋਗ ਕਵੈਰੀ ਹੱਲ ਹੁੰਦੀ ਹੈ ਪਰ ਛੋਟੀ ਨਹੀਂ, ਤਾਂ ਨਾਕਾਮੀ ਸਫਿਕਸ ਵਿੱਚ ਹੈ, ਸਰਵਰ ਵਿੱਚ ਨਹੀਂ। ਜੇ ਦੋਵੇਂ ਹੱਲ ਨਹੀਂ ਹੁੰਦੀਆਂ ਅਤੇ ਪਤਾ ਕੰਮ ਕਰਦਾ ਹੈ, ਤਾਂ ਕਲਾਇੰਟ ਅੰਦਰੂਨੀ ਰਿਜ਼ੋਲਵਰ ਬਿਲਕੁਲ ਨਹੀਂ ਵਰਤ ਰਿਹਾ। ਰਿਜ਼ੋਲਵਰ ਸੂਚੀ ਦੀ ਤੁਲਨਾ ਉਸ ਨਾਲ ਕਰੋ ਜੋ VPN ਨੂੰ ਪੁਸ਼ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਹਰ ਕਵੈਰੀ ਲਈ ਆਪਣਾ ਸਥਾਨਕ ਰਿਜ਼ੋਲਵਰ ਰੱਖਣ ਵਾਲਾ ਕਲਾਇੰਟ ਅੰਦਰੂਨੀ ਜ਼ੋਨ ਕਦੇ ਨਹੀਂ ਦੇਖੇਗਾ।
ਸਹੀ ਨਾਮ ਕਲਾਇੰਟ ਤੱਕ ਲਿਆਓ
ਪ੍ਰਸ਼ਾਸਕ ਤੋਂ ਦਸਤਾਵੇਜ਼ੀ ਦੂਰਸਥ-ਪਹੁੰਚ ਨਾਮ ਪੂਰਾ ਮੰਗੋ ਅਤੇ ਸਫਿਕਸ ਦਾ ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਦੀ ਬਜਾਏ ਪਰੋਫਾਈਲ ਵਿੱਚ ਉਹੀ ਵਰਤੋ। ਜੇ ਤੈਨਾਤੀ split DNS ਦਾ ਸਮਰਥਨ ਕਰਦੀ ਹੈ, ਤਾਂ ਅੰਦਰੂਨੀ ਡੋਮੇਨ ਨੂੰ ਅੰਦਰੂਨੀ ਸਰਵਰਾਂ ਰਾਹੀਂ ਹੱਲ ਕਰਨ ਲਈ ਸੰਰਚਿਤ ਕਰੋ, ਜਦੋਂ ਕਿ ਬਾਕੀ ਸਭ ਸਥਾਨਕ ਰਿਜ਼ੋਲਵਰ ਰੱਖੇ। ਜਿੱਥੇ ਕਲਾਇੰਟ ਸਮਰਥਨ ਕਰਦਾ ਹੈ ਉੱਥੇ VPN ਸੰਰਚਨਾ ਰਾਹੀਂ ਖੋਜ ਡੋਮੇਨ ਪੁਸ਼ ਕਰੋ।
ਨਤੀਜਾ ਕਲਾਇੰਟ ਉੱਤੇ ਜਾਂਚੋ, ਗੇਟਵੇ ਉੱਤੇ ਨਹੀਂ। ਸਰਵਰ ਉੱਤੇ ਲਾਗੂ ਕੀਤੀ ਅਤੇ ਕਲਾਇੰਟ ਤੱਕ ਕਦੇ ਨਾ ਪਹੁੰਚਣ ਵਾਲੀ ਸੈਟਿੰਗ ਕੁਝ ਵੀ ਨਹੀਂ ਬਦਲਦੀ।
ਪ੍ਰਮਾਣਪੱਤਰ ਦੀ ਪਛਾਣ ਅਟੱਲ ਰੱਖੋ
ਪ੍ਰਮਾਣਪੱਤਰ ਦੀ ਗਲਤੀ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨ ਵਾਲੀ ਪਤੇ-ਆਧਾਰਿਤ ਜਾਂਚ ਸਿਰਫ਼ ਇਹ ਸਾਬਤ ਕਰਦੀ ਹੈ ਕਿ ਸਾਕਟ ਖੁੱਲ੍ਹੀ ਸੀ। ਸੇਵਾ ਦਾ ਪ੍ਰਮਾਣਪੱਤਰ ਇੱਕ ਨਾਮ ਲਈ ਜਾਰੀ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਜਾਇਜ਼ ਕਾਰਨ ਨਾਲ ਬੇਮੇਲ ਨੂੰ ਰੱਦ ਕਰਦਾ ਰਹੇਗਾ। ਜੇ ਪ੍ਰਮਾਣਪੱਤਰ ਸਿਰਫ਼ ਅੰਦਰੂਨੀ ਨਾਮ ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ, ਤਾਂ ਉਹੀ ਨਾਮ ਵਰਤੋ ਅਤੇ ਹੱਲ ਸੁਧਾਰੋ, ਜਾਂ ਅਜਿਹਾ ਪ੍ਰਮਾਣਪੱਤਰ ਲਵੋ ਜੋ ਤੁਸੀਂ ਵਰਤਣ ਵਾਲੇ ਪਤੇ ਨੂੰ ਕਵਰ ਕਰੇ।
ਜਿਸ ਨਾਮ, ਰਿਜ਼ੋਲਵਰ ਅਤੇ ਸਫਿਕਸ ਨੇ ਸਫਲ ਕਨੈਕਸ਼ਨ ਦਿੱਤਾ, ਉਹ ਦਰਜ ਕਰੋ। ਉਹ ਰਿਕਾਰਡ ਅਗਲੇ ਵਿਅਕਤੀ ਨੂੰ ਸੱਚੀ ਸਮੱਸਿਆ ਲੁਕਾਉਣ ਵਾਲੇ ਪਤੇ-ਆਧਾਰਿਤ ਕੰਮ-ਚਲਾਊ ਹੱਲ ਨੂੰ ਦੁਹਰਾਉਣ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।