nsswitch ਕ੍ਰਮ ਕਾਰਨ ਤੁਹਾਡਾ CIFS ਮਾਊਂਟ VPN ਉੱਤੇ ਫੇਲ ਹੁੰਦਾ ਹੈ

ਟਨਲ ਚੱਲ ਰਿਹਾ ਹੈ। ਫਾਈਲ ਸਰਵਰ ping ਨੂੰ ਪਤੇ ਨਾਲ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਫਿਰ mount.cifs ਹੋਸਟਨਾਮ ਨਾਲ ਕੁਝ ਸਮਾਂ ਉੱਥੇ ਬੈਠਦਾ ਹੈ ਅਤੇ ਦੱਸਦਾ ਹੈ ਕਿ ਹੋਸਟ ਪਹੁੰਚਯੋਗ ਨਹੀਂ, ਅਤੇ ਤੁਸੀਂ ਉਹ VPN ਪਰੋਫਾਈਲ ਦੁਬਾਰਾ ਬਣਾਉਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੇ ਹੋ ਜੋ ਕਦੇ ਸਮੱਸਿਆ ਨਹੀਂ ਸੀ। Linux ਉੱਤੇ ਕੋਈ ਵੀ SMB ਪੈਕਟ ਮੌਜੂਦ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ glibc ਨਾਮ ਦਾ ਹੱਲ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਸ ਰਿਜ਼ੌਲਵਰ ਦਾ ਕ੍ਰਮ DNS ਨੂੰ ਪੁੱਛਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਖੋਜ ਖਤਮ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਮੇਰਾ ਤੁਰਨ ਦਾ ਰਾਹ ਹੈ, ਕਲਾਇੰਟ ਤੋਂ ਨਹੀਂ, ਫੇਲ ਹੋਈ ਕਮਾਂਡ ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ।

ਫੇਲਤਾ ਨੂੰ ਸਹੀ ਥਾਂ ਪੜ੍ਹੋ

ਦੋ ਸਾਧਨ ਇੱਕੋ ਨਾਮ ਤੱਕ ਵੱਖਰੇ ਰਾਹਾਂ ਨਾਲ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਉਨ੍ਹਾਂ ਦੀ ਤੁਲਨਾ ਲਈ ਇੱਕ ਕਮਾਂਡ ਕਾਫੀ ਹੈ। getent ਸੰਰਚਿਤ ਨਾਮ ਸੇਵਾ ਸਟੈਕ ਵਿੱਚੋਂ ਲੰਘਦਾ ਹੈ; host ਅਤੇ dig DNS ਨੂੰ ਸਿੱਧਾ ਪੁੱਛਦੇ ਹਨ ਅਤੇ ਉਸ ਸਟੈਕ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦੇ ਹਨ। ਜੇ ਸਿੱਧੀ ਕਵੈਰੀ ਪਤਾ ਵਾਪਸ ਕਰਦੀ ਹੈ ਅਤੇ getent ਕੁਝ ਨਹੀਂ, ਤਾਂ DNS ਸਰਵਰ ਪਹੁੰਚਯੋਗ ਹੈ ਅਤੇ ਤੁਹਾਡਾ ਰਿਜ਼ੌਲਵਰ ਸੰਰਚਨਾ ਹੀ ਫੇਲ ਹੋ ਰਿਹਾ ਹੈ।

getent hosts fileserver.corp.example
host fileserver.corp.example 10.61.0.1
getent -s dns hosts fileserver.corp.example

ਤੀਜੀ ਕਮਾਂਡ ਨਿਰਣਾਇਕ ਹੈ: ਇਹ DNS ਸਰੋਤ ਨੂੰ ਮਜਬੂਰ ਕਰਦੀ ਹੈ ਅਤੇ ਬਾਕੀ ਸਟੈਕ ਛੱਡ ਦਿੰਦੀ ਹੈ। ਜਦੋਂ ਇਹ ਚੱਲਦੀ ਹੈ ਅਤੇ ਸਧਾਰਨ getent ਨਹੀਂ ਚੱਲਦੀ, ਤਾਂ ਤੁਸੀਂ ਸਾਬਤ ਕਰ ਦਿੱਤਾ ਕਿ ਕਸੂਰ ਕ੍ਰਮ ਵਿੱਚ ਹੈ, ਟਨਲ ਵਿੱਚ ਨਹੀਂ ਅਤੇ ਸਰਵਰ ਵਿੱਚ ਨਹੀਂ।

hosts ਲਾਈਨ ਇੱਕ ਅਜਿਹਾ ਕ੍ਰਮ ਹੈ ਜੋ ਜਲਦੀ ਰੁਕ ਜਾਂਦਾ ਹੈ

glibc ਰਿਜ਼ੌਲਵਰ /etc/nsswitch.conf ਪੜ੍ਹਦਾ ਹੈ ਅਤੇ hosts: ਐਂਟਰੀ ਨੂੰ ਖੱਬੇ ਤੋਂ ਸੱਜੇ ਲੰਘਦਾ ਹੈ। ਬਹੁਤ ਸਾਰੀਆਂ ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨਾਂ ਅਜਿਹੀ ਲਾਈਨ ਭੇਜਦੀਆਂ ਹਨ ਜਿਸ ਵਿੱਚ multicast ਖੋਜ ਪਹਿਲਾਂ ਆਉਂਦੀ ਹੈ ਅਤੇ ਉਸ ਨਾਲ ਜਲਦੀ ਵਾਪਸੀ ਦੀ ਕਿਰਿਆ ਜੁੜੀ ਹੁੰਦੀ ਹੈ। ਉਹ ਕਿਰਿਆ ਸਜਾਵਟ ਨਹੀਂ: ਜਦੋਂ mDNS “not found” ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, [NOTFOUND=return] ਪੂਰੀ ਖੋਜ ਖਤਮ ਕਰ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਕਾਰਪੋਰੇਟ ਨਾਮ VPN ਵੱਲੋਂ ਥੋਪੇ ਰਿਜ਼ੌਲਵਰ ਕੋਲ ਕਦੇ ਨਹੀਂ ਭੇਜਿਆ ਜਾਂਦਾ। ਕੁਝ ਵੀ ਇਸ ਨੂੰ ਲੌਗ ਨਹੀਂ ਕਰਦਾ, ਕਿਉਂਕਿ ਰਿਜ਼ੌਲਵਰ ਦੇ ਰੱਦ ਕਰਨ ਯੋਗ ਕੋਈ ਕਵੈਰੀ ਹੀ ਨਹੀਂ ਭੇਜੀ ਗਈ। ਇਸੇ ਲਈ ਮਾਊਂਟ ਲਟਕਦਾ ਜਾਪਦਾ ਹੈ ਅਤੇ ਫਿਰ ਹੋਸਟ ਪਹੁੰਚਯੋਗ ਨਹੀਂ ਦੱਸਦਾ।

cat /etc/nsswitch.conf | grep '^hosts:'
# illustrative repair: dns before the early-return action
hosts: files myhostname mdns4_minimal dns [NOTFOUND=return] wins mdns4

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

ਰਿਜ਼ੌਲਵਰ ਖੋਜ ਡੋਮੇਨ ਨਹੀਂ ਹੈ

ਹੱਲ ਲਈ ਨਾਮ ਦੀ ਕੋਸ਼ਿਸ਼ ਵੀ ਲਾਜ਼ਮੀ ਹੈ। fileserver ਵਰਗਾ ਅਧੂਰਾ ਨਾਮ ਕਵੈਰੀ ਲਿਜਾਣ ਵਾਲੇ ਇੰਟਰਫੇਸ ਨਾਲ ਖੋਜ ਡੋਮੇਨ ਜੁੜਨ ’ਤੇ ਹੀ fileserver.corp.example ਬਣਦਾ ਹੈ। ਖੋਜ ਸੂਚੀ ਤੋਂ ਬਿਨਾਂ DNS ਸਰਵਰ ਥੋਪਣ ਵਾਲਾ VPN ਬਹੁਤ ਖਾਸ ਵੰਡ ਪੈਦਾ ਕਰਦਾ ਹੈ: ਪੂਰੀ ਤਰ੍ਹਾਂ ਯੋਗ ਨਾਮ ਹੱਲ ਹੁੰਦਾ ਹੈ ਅਤੇ ਹਰ ਛੋਟਾ ਨਾਮ ਫੇਲ ਹੁੰਦਾ ਹੈ.

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

resolvectl status
resolvectl query fileserver.corp.example
resolvectl dns
resolvectl domain

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

ਕੰਟੇਨਰ ਆਪਣੇ ਜਵਾਬ ਦੀ ਕਾਪੀ ਲੈ ਕੇ ਤੁਰਦੇ ਹਨ

ਆਮ image ਤੋਂ ਬਣਾਇਆ ਕੰਟੇਨਰ ਆਮ ਤੌਰ ’ਤੇ ਸਥਿਰ resolv.conf ਲਿਆਉਂਦਾ ਹੈ। ਹੋਸਟ ਉੱਤੇ ਕੀਤੇ ਰਿਜ਼ੌਲਵਰ ਬਦਲਾਅ ਉੱਥੇ ਨਹੀਂ ਪਹੁੰਚਦੇ, ਅਤੇ ਨਾ ਹੀ ਖੋਜ ਡੋਮੇਨ, ਇਸ ਲਈ ਟਨਲ ਰਾਹੀਂ ਸ਼ੇਅਰ ਮਾਊਂਟ ਕਰਨ ਵਾਲਾ build ਕੰਮ ਫੇਲ ਹੁੰਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਉਹੀ ਕਮਾਂਡ ਕੰਟੇਨਰ ਤੋਂ ਬਾਹਰ ਚੱਲਦੀ ਹੈ। ਕੰਟੇਨਰ ਨੂੰ ਆਪਣੀਆਂ DNS ਅਤੇ ਖੋਜ ਸੈਟਿੰਗਾਂ compose ਫਾਈਲ ਜਾਂ run ਆਰਗਿਊਮੈਂਟਾਂ ਵਿੱਚ ਦਿਓ, ਸਿਰਫ ਹੋਸਟ ਪਰੋਫਾਈਲ ਵਿੱਚ ਨਹੀਂ।

image ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਕੰਟੇਨਰ ਦੇ ਅੰਦਰ ਜਾਂਚੋ। ਦੋ ਕਮਾਂਡਾਂ ਪੂਰੀ ਨਿਦਾਨ ਕੁਝ ਸਕਿੰਟਾਂ ਵਿੱਚ ਦੁਬਾਰਾ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਦੂਜੀ ਸਾਬਤ ਕਰਦੀ ਹੈ ਕਿ ਕਿਹੜਾ ਰਿਜ਼ੌਲਵਰ ਅਸਲ ਵਿੱਚ ਜਵਾਬ ਦੇਣ ਵਾਲਾ ਸੀ।

ਫਿਰ ਹੀ ਸ਼ੇਅਰ ਅਤੇ ਫਿਲਟਰ ਵੱਲ ਦੇਖੋ

ਨਾਮ ਹੱਲ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਬਾਕੀ ਫੇਲਤਾਵਾਂ ਆਮ ਨੈੱਟਵਰਕ ਸਮੱਸਿਆਵਾਂ ਹਨ। SMB ਨੂੰ ਸਰਵਰ ਤੱਕ TCP 445 ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਵਰਕਗਰੁੱਪ ਸੂਚੀ ਬ੍ਰਾਊਜ਼ ਕਰਨਾ ਉਨ੍ਹਾਂ ਨਾਮ ਸੇਵਾਵਾਂ ਉੱਤੇ ਨਿਰਭਰ ਹੈ ਜੋ ਟਨਲ ਸ਼ਾਇਦ ਅੱਗੇ ਨਹੀਂ ਭੇਜਦਾ। ਸੂਚੀ ਭਰਨ ਦੀ ਉਡੀਕ ਕਰਨ ਦੀ ਬਜਾਏ ਹੋਸਟਨਾਮ ਨਾਲ ਮੈਪ ਕਰੋ, ਅਤੇ ਕਲਾਇੰਟ ਨੂੰ ਦੱਸਣ ਦਿਓ ਕਿ ਉਹ ਕਿਹੜੇ ਪੜਾਅ ਤੱਕ ਪਹੁੰਚਿਆ। ਰੱਦ ਕੀਤਾ ਕਨੈਕਸ਼ਨ ਅਤੇ ਚੁੱਪ timeout ਵੀ ਵੱਖਰੇ ਕਰਨ ਯੋਗ ਹਨ, ਕਿਉਂਕਿ ਪਹਿਲਾ ਆਮ ਤੌਰ ’ਤੇ ਕੁਝ ਜਵਾਬ ਦੇਣ ਦਾ ਅਤੇ ਦੂਜਾ ਕੁਝ ਵੀ ਜਵਾਬ ਨਾ ਦੇਣ ਦਾ ਮਤਲਬ ਹੁੰਦਾ ਹੈ।

getent hosts fileserver.corp.example
nc -vz fileserver.corp.example 445
mount -t cifs //fileserver.corp.example/share /mnt/share \
  -o vers=3.1.1,username=svc_mount,uid=1000

ਹੱਲ ਹੋਏ ਪਤੇ ’ਤੇ 445 ਪੋਰਟ ਰੱਦ ਜਾਂ ਸਮਾਂ ਖਤਮ ਹੋਣਾ ਪਾਰਲੇ ਪਾਸੇ ਦੀ firewall ਜਾਂ listener ਸਮੱਸਿਆ ਹੈ। ਨਾ ਹੱਲ ਹੋਇਆ ਨਾਮ ਰਿਜ਼ੌਲਵਰ ਸਮੱਸਿਆ ਹੈ। ਅਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਹੋ ਕੇ ਅਨੁਮਤੀ ਗਲਤੀਆਂ ਵਾਪਸ ਕਰਨ ਵਾਲਾ ਮਾਊਂਟ ਦੋਵੇਂ ਨਹੀਂ, ਇਸ ਲਈ ਸੈਸ਼ਨ ਬਣਨ ਤੋਂ ਬਾਅਦ ਨੈੱਟਵਰਕ ਸਵਾਲ ਦੁਬਾਰਾ ਨਾ ਖੋਲ੍ਹੋ।

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