ਗੂਗਲ ਕਲਾਉਡ ਤਕਨੀਕੀ ਸਹਾਇਤਾ ਤੋਂ ਗੁੰਮ ਹੋਏ DNS ਪੈਕੇਟਾਂ ਬਾਰੇ ਇੱਕ ਕਹਾਣੀ

ਗੂਗਲ ਬਲੌਗ ਸੰਪਾਦਕ ਤੋਂ: ਕੀ ਤੁਸੀਂ ਕਦੇ ਸੋਚਿਆ ਹੈ ਕਿ ਗੂਗਲ ਕਲਾਉਡ ਤਕਨੀਕੀ ਹੱਲ (ਟੀਐਸਈ) ਇੰਜੀਨੀਅਰ ਤੁਹਾਡੀਆਂ ਸਹਾਇਤਾ ਬੇਨਤੀਆਂ ਨੂੰ ਕਿਵੇਂ ਸੰਭਾਲਦੇ ਹਨ? TSE ਤਕਨੀਕੀ ਸਹਾਇਤਾ ਇੰਜੀਨੀਅਰ ਸਮੱਸਿਆਵਾਂ ਦੇ ਉਪਭੋਗਤਾ ਦੁਆਰਾ ਰਿਪੋਰਟ ਕੀਤੇ ਸਰੋਤਾਂ ਦੀ ਪਛਾਣ ਕਰਨ ਅਤੇ ਠੀਕ ਕਰਨ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹਨ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੁਝ ਸਮੱਸਿਆਵਾਂ ਕਾਫ਼ੀ ਸਧਾਰਨ ਹਨ, ਪਰ ਕਈ ਵਾਰ ਤੁਹਾਨੂੰ ਇੱਕ ਟਿਕਟ ਮਿਲਦੀ ਹੈ ਜਿਸ ਲਈ ਇੱਕ ਵਾਰ ਵਿੱਚ ਕਈ ਇੰਜੀਨੀਅਰਾਂ ਦੇ ਧਿਆਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇਸ ਲੇਖ ਵਿੱਚ, ਇੱਕ TSE ਕਰਮਚਾਰੀ ਸਾਨੂੰ ਆਪਣੇ ਹਾਲੀਆ ਅਭਿਆਸ ਤੋਂ ਇੱਕ ਬਹੁਤ ਹੀ ਮੁਸ਼ਕਲ ਸਮੱਸਿਆ ਬਾਰੇ ਦੱਸੇਗਾ - DNS ਪੈਕੇਟ ਗੁੰਮ ਹੋਣ ਦਾ ਮਾਮਲਾ. ਇਸ ਕਹਾਣੀ ਵਿੱਚ, ਅਸੀਂ ਦੇਖਾਂਗੇ ਕਿ ਇੰਜੀਨੀਅਰਾਂ ਨੇ ਸਥਿਤੀ ਨੂੰ ਕਿਵੇਂ ਸੁਲਝਾਇਆ, ਅਤੇ ਗਲਤੀ ਨੂੰ ਠੀਕ ਕਰਦੇ ਸਮੇਂ ਉਹਨਾਂ ਨੇ ਕਿਹੜੀਆਂ ਨਵੀਆਂ ਚੀਜ਼ਾਂ ਸਿੱਖੀਆਂ। ਅਸੀਂ ਆਸ ਕਰਦੇ ਹਾਂ ਕਿ ਇਹ ਕਹਾਣੀ ਨਾ ਸਿਰਫ਼ ਤੁਹਾਨੂੰ ਡੂੰਘੇ-ਬੈਠਣ ਵਾਲੇ ਬੱਗ ਬਾਰੇ ਸਿੱਖਿਅਤ ਕਰੇਗੀ, ਸਗੋਂ ਤੁਹਾਨੂੰ ਉਹਨਾਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੀ ਸਮਝ ਵੀ ਦੇਵੇਗੀ ਜੋ Google ਕਲਾਉਡ ਨਾਲ ਇੱਕ ਸਹਾਇਤਾ ਟਿਕਟ ਦਾਇਰ ਕਰਨ ਲਈ ਜਾਂਦੀਆਂ ਹਨ।

ਸਮੱਸਿਆ ਨਿਪਟਾਰਾ ਇੱਕ ਵਿਗਿਆਨ ਅਤੇ ਇੱਕ ਕਲਾ ਦੋਵੇਂ ਹੈ। ਇਹ ਸਭ ਸਿਸਟਮ ਦੇ ਗੈਰ-ਮਿਆਰੀ ਵਿਵਹਾਰ ਦੇ ਕਾਰਨ ਬਾਰੇ ਇੱਕ ਕਲਪਨਾ ਬਣਾਉਣ ਦੇ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਜਿਸ ਤੋਂ ਬਾਅਦ ਇਸਦੀ ਤਾਕਤ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ. ਹਾਲਾਂਕਿ, ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਅਸੀਂ ਇੱਕ ਪਰਿਕਲਪਨਾ ਤਿਆਰ ਕਰੀਏ, ਸਾਨੂੰ ਸਮੱਸਿਆ ਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਪਰਿਭਾਸ਼ਿਤ ਅਤੇ ਸਹੀ ਰੂਪ ਵਿੱਚ ਤਿਆਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਸਵਾਲ ਬਹੁਤ ਅਸਪਸ਼ਟ ਲੱਗਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਹਰ ਚੀਜ਼ ਦਾ ਧਿਆਨ ਨਾਲ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨਾ ਪਵੇਗਾ; ਇਹ ਸਮੱਸਿਆ ਨਿਪਟਾਰੇ ਦੀ "ਕਲਾ" ਹੈ।

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

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

ਸਵਾਲ ਵਿੱਚ ਸਮੱਸਿਆ

ਅੱਜ ਸਾਡੇ ਕੋਲ ਇੱਕ ਵਧੀਆ ਅੰਤ ਵਾਲੀ ਕਹਾਣੀ ਹੈ। ਪ੍ਰਸਤਾਵਿਤ ਕੇਸ ਦੇ ਸਫਲ ਹੱਲ ਦੇ ਕਾਰਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਸਮੱਸਿਆ ਦਾ ਇੱਕ ਬਹੁਤ ਹੀ ਵਿਸਤ੍ਰਿਤ ਅਤੇ ਸਹੀ ਵਰਣਨ ਹੈ। ਹੇਠਾਂ ਤੁਸੀਂ ਪਹਿਲੀ ਟਿਕਟ ਦੀ ਇੱਕ ਕਾਪੀ ਦੇਖ ਸਕਦੇ ਹੋ (ਗੁਪਤ ਜਾਣਕਾਰੀ ਨੂੰ ਛੁਪਾਉਣ ਲਈ ਸੰਪਾਦਿਤ ਕੀਤਾ ਗਿਆ):

ਇਸ ਸੰਦੇਸ਼ ਵਿੱਚ ਸਾਡੇ ਲਈ ਬਹੁਤ ਸਾਰੀ ਉਪਯੋਗੀ ਜਾਣਕਾਰੀ ਸ਼ਾਮਲ ਹੈ:

• ਖਾਸ VM ਦਿੱਤਾ ਗਿਆ
• ਸਮੱਸਿਆ ਖੁਦ ਦਰਸਾਈ ਗਈ ਹੈ - DNS ਕੰਮ ਨਹੀਂ ਕਰਦਾ
• ਇਹ ਦਰਸਾਇਆ ਗਿਆ ਹੈ ਕਿ ਸਮੱਸਿਆ ਕਿੱਥੇ ਪ੍ਰਗਟ ਹੁੰਦੀ ਹੈ - VM ਅਤੇ ਕੰਟੇਨਰ
• ਉਪਭੋਗਤਾ ਦੁਆਰਾ ਸਮੱਸਿਆ ਦੀ ਪਛਾਣ ਕਰਨ ਲਈ ਚੁੱਕੇ ਗਏ ਕਦਮ ਦਰਸਾਏ ਗਏ ਹਨ।

ਬੇਨਤੀ ਨੂੰ "P1: ਗੰਭੀਰ ਪ੍ਰਭਾਵ - ਉਤਪਾਦਨ ਵਿੱਚ ਵਰਤੋਂਯੋਗ ਸੇਵਾ" ਦੇ ਤੌਰ 'ਤੇ ਰਜਿਸਟਰ ਕੀਤਾ ਗਿਆ ਸੀ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ "ਫੋਲੋ ਦ ਸਨ" ਸਕੀਮ ਦੇ ਅਨੁਸਾਰ ਸਥਿਤੀ ਦੀ 24/7 ਨਿਰੰਤਰ ਨਿਗਰਾਨੀ (ਤੁਸੀਂ ਇਸ ਬਾਰੇ ਹੋਰ ਪੜ੍ਹ ਸਕਦੇ ਹੋ ਉਪਭੋਗਤਾ ਬੇਨਤੀਆਂ ਦੀ ਤਰਜੀਹ), ਹਰ ਟਾਈਮ ਜ਼ੋਨ ਸ਼ਿਫਟ ਦੇ ਨਾਲ ਇੱਕ ਤਕਨੀਕੀ ਸਹਾਇਤਾ ਟੀਮ ਤੋਂ ਦੂਜੀ ਵਿੱਚ ਟ੍ਰਾਂਸਫਰ ਦੇ ਨਾਲ। ਵਾਸਤਵ ਵਿੱਚ, ਜਦੋਂ ਤੱਕ ਸਮੱਸਿਆ ਜ਼ਿਊਰਿਖ ਵਿੱਚ ਸਾਡੀ ਟੀਮ ਤੱਕ ਪਹੁੰਚੀ, ਇਹ ਪਹਿਲਾਂ ਹੀ ਪੂਰੀ ਦੁਨੀਆ ਵਿੱਚ ਚੱਕਰ ਲਗਾ ਚੁੱਕੀ ਸੀ। ਇਸ ਸਮੇਂ ਤੱਕ, ਉਪਭੋਗਤਾ ਨੇ ਘਟਾਉਣ ਦੇ ਉਪਾਅ ਕਰ ਲਏ ਸਨ, ਪਰ ਉਤਪਾਦਨ ਵਿੱਚ ਸਥਿਤੀ ਦੇ ਦੁਹਰਾਉਣ ਤੋਂ ਡਰਦਾ ਸੀ, ਕਿਉਂਕਿ ਮੂਲ ਕਾਰਨ ਅਜੇ ਤੱਕ ਖੋਜਿਆ ਨਹੀਂ ਗਿਆ ਸੀ.

ਟਿਕਟ ਜ਼ਿਊਰਿਖ ਪਹੁੰਚਣ ਤੱਕ, ਸਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਹੇਠ ਲਿਖੀ ਜਾਣਕਾਰੀ ਸੀ:

• ਸਮੱਗਰੀ /etc/hosts
• ਸਮੱਗਰੀ /etc/resolv.conf
• ਸਿੱਟਾ iptables-save
• ਟੀਮ ਵੱਲੋਂ ਇਕੱਤਰ ਕੀਤਾ ਗਿਆ ngrep pcap ਫਾਈਲ

ਇਸ ਡੇਟਾ ਦੇ ਨਾਲ, ਅਸੀਂ "ਜਾਂਚ" ਅਤੇ ਸਮੱਸਿਆ ਨਿਪਟਾਰਾ ਪੜਾਅ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਤਿਆਰ ਸੀ।

ਸਾਡੇ ਪਹਿਲੇ ਕਦਮ

ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਅਸੀਂ ਮੈਟਾਡੇਟਾ ਸਰਵਰ ਦੇ ਲੌਗਸ ਅਤੇ ਸਥਿਤੀ ਦੀ ਜਾਂਚ ਕੀਤੀ ਅਤੇ ਯਕੀਨੀ ਬਣਾਇਆ ਕਿ ਇਹ ਸਹੀ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ। ਮੈਟਾਡੇਟਾ ਸਰਵਰ IP ਐਡਰੈੱਸ 169.254.169.254 ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਅਤੇ, ਹੋਰ ਚੀਜ਼ਾਂ ਦੇ ਨਾਲ, ਡੋਮੇਨ ਨਾਮਾਂ ਨੂੰ ਕੰਟਰੋਲ ਕਰਨ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ। ਅਸੀਂ ਇਹ ਵੀ ਦੋ ਵਾਰ ਜਾਂਚ ਕੀਤੀ ਹੈ ਕਿ ਫਾਇਰਵਾਲ VM ਨਾਲ ਸਹੀ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰਦੀ ਹੈ ਅਤੇ ਪੈਕਟਾਂ ਨੂੰ ਬਲੌਕ ਨਹੀਂ ਕਰਦੀ ਹੈ।

ਇਹ ਕਿਸੇ ਕਿਸਮ ਦੀ ਅਜੀਬ ਸਮੱਸਿਆ ਸੀ: nmap ਜਾਂਚ ਨੇ UDP ਪੈਕੇਟਾਂ ਦੇ ਨੁਕਸਾਨ ਬਾਰੇ ਸਾਡੀ ਮੁੱਖ ਧਾਰਨਾ ਦਾ ਖੰਡਨ ਕੀਤਾ, ਇਸ ਲਈ ਅਸੀਂ ਮਾਨਸਿਕ ਤੌਰ 'ਤੇ ਕਈ ਹੋਰ ਵਿਕਲਪਾਂ ਅਤੇ ਉਹਨਾਂ ਦੀ ਜਾਂਚ ਕਰਨ ਦੇ ਤਰੀਕਿਆਂ ਨਾਲ ਆਏ:

• ਕੀ ਪੈਕੇਟ ਚੋਣਵੇਂ ਤੌਰ 'ਤੇ ਛੱਡੇ ਗਏ ਹਨ? => iptables ਨਿਯਮਾਂ ਦੀ ਜਾਂਚ ਕਰੋ
• ਕੀ ਇਹ ਬਹੁਤ ਛੋਟਾ ਨਹੀਂ ਹੈ? MTU? => ਆਉਟਪੁੱਟ ਦੀ ਜਾਂਚ ਕਰੋ ip a show
• ਕੀ ਸਮੱਸਿਆ ਸਿਰਫ਼ UDP ਪੈਕੇਟਾਂ ਜਾਂ TCP ਨੂੰ ਵੀ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀ ਹੈ? => ਦੂਰ ਚਲਾਓ dig +tcp
• ਕੀ ਡਿਗ ਦੁਆਰਾ ਤਿਆਰ ਕੀਤੇ ਪੈਕੇਟ ਵਾਪਸ ਕੀਤੇ ਗਏ ਹਨ? => ਦੂਰ ਚਲਾਓ tcpdump
• ਕੀ libdns ਸਹੀ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ? => ਦੂਰ ਚਲਾਓ strace ਦੋਵਾਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਪੈਕੇਟਾਂ ਦੇ ਪ੍ਰਸਾਰਣ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ

ਇੱਥੇ ਅਸੀਂ ਉਪਭੋਗਤਾ ਨੂੰ ਸਮੱਸਿਆਵਾਂ ਦਾ ਲਾਈਵ ਨਿਪਟਾਰਾ ਕਰਨ ਲਈ ਕਾਲ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕਰਦੇ ਹਾਂ।

ਕਾਲ ਦੇ ਦੌਰਾਨ ਅਸੀਂ ਕਈ ਚੀਜ਼ਾਂ ਦੀ ਜਾਂਚ ਕਰਨ ਦੇ ਯੋਗ ਹੁੰਦੇ ਹਾਂ:

• ਕਈ ਜਾਂਚਾਂ ਤੋਂ ਬਾਅਦ ਅਸੀਂ ਕਾਰਨਾਂ ਦੀ ਸੂਚੀ ਵਿੱਚੋਂ iptables ਨਿਯਮਾਂ ਨੂੰ ਬਾਹਰ ਕਰ ਦਿੰਦੇ ਹਾਂ
• ਅਸੀਂ ਨੈੱਟਵਰਕ ਇੰਟਰਫੇਸ ਅਤੇ ਰੂਟਿੰਗ ਟੇਬਲ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹਾਂ, ਅਤੇ ਦੋ ਵਾਰ ਜਾਂਚ ਕਰਦੇ ਹਾਂ ਕਿ MTU ਸਹੀ ਹੈ
• ਸਾਨੂੰ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ dig +tcp google.com (TCP) ਕੰਮ ਕਰਦਾ ਹੈ ਜਿਵੇਂ ਕਿ ਇਹ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਪਰ dig google.com (UDP) ਕੰਮ ਨਹੀਂ ਕਰਦਾ
• ਭਜਾ ਕੇ tcpdump ਇਹ ਅਜੇ ਵੀ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ dig, ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ ਕਿ UDP ਪੈਕੇਟ ਵਾਪਸ ਕੀਤੇ ਜਾ ਰਹੇ ਹਨ
• ਅਸੀਂ ਦੂਰ ਚਲਾਉਂਦੇ ਹਾਂ strace dig google.com ਅਤੇ ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ ਕਿ ਕਿਸ ਤਰ੍ਹਾਂ ਡਿਗ ਸਹੀ ਢੰਗ ਨਾਲ ਕਾਲ ਕਰਦਾ ਹੈ sendmsg() и recvms(), ਹਾਲਾਂਕਿ ਦੂਜਾ ਇੱਕ ਸਮਾਂ ਸਮਾਪਤੀ ਦੁਆਰਾ ਰੋਕਿਆ ਗਿਆ ਹੈ

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

from scapy.all import *

answer = sr1(IP(dst="169.254.169.254")/UDP(dport=53)/DNS(rd=1,qd=DNSQR(qname="google.com")),verbose=0)
print ("169.254.169.254", answer[DNS].summary())

ਇਹ ਟੁਕੜਾ ਇੱਕ DNS ਪੈਕੇਟ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਮੈਟਾਡੇਟਾ ਸਰਵਰ ਨੂੰ ਬੇਨਤੀ ਭੇਜਦਾ ਹੈ।

ਉਪਭੋਗਤਾ ਕੋਡ ਚਲਾਉਂਦਾ ਹੈ, DNS ਜਵਾਬ ਵਾਪਸ ਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਇਸਨੂੰ ਪ੍ਰਾਪਤ ਕਰਦੀ ਹੈ, ਇਹ ਪੁਸ਼ਟੀ ਕਰਦੀ ਹੈ ਕਿ ਨੈੱਟਵਰਕ ਪੱਧਰ 'ਤੇ ਕੋਈ ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ।

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

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

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

ਇੱਕ ਕਦਮ ਪਿੱਛੇ ਹਟ ਰਿਹਾ ਹੈ

ਸਿਸਟਮ ਇੰਜੀਨੀਅਰ ਅਹੁਦਿਆਂ ਲਈ ਸਭ ਤੋਂ ਪ੍ਰਸਿੱਧ ਇੰਟਰਵਿਊ ਸਵਾਲਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ: “ਜਦੋਂ ਤੁਸੀਂ ਪਿੰਗ ਕਰਦੇ ਹੋ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ www.google.com? ਸਵਾਲ ਬਹੁਤ ਵਧੀਆ ਹੈ, ਕਿਉਂਕਿ ਉਮੀਦਵਾਰ ਨੂੰ ਸ਼ੈੱਲ ਤੋਂ ਯੂਜ਼ਰ ਸਪੇਸ, ਸਿਸਟਮ ਕਰਨਲ ਅਤੇ ਫਿਰ ਨੈੱਟਵਰਕ ਤੱਕ ਸਭ ਕੁਝ ਵਰਣਨ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਮੈਂ ਮੁਸਕਰਾਉਂਦਾ ਹਾਂ: ਕਈ ਵਾਰ ਇੰਟਰਵਿਊ ਦੇ ਸਵਾਲ ਅਸਲ ਜ਼ਿੰਦਗੀ ਵਿੱਚ ਲਾਭਦਾਇਕ ਹੁੰਦੇ ਹਨ...

ਮੈਂ ਇਸ HR ਸਵਾਲ ਨੂੰ ਮੌਜੂਦਾ ਸਮੱਸਿਆ 'ਤੇ ਲਾਗੂ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕਰਦਾ ਹਾਂ। ਮੋਟੇ ਤੌਰ 'ਤੇ, ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ DNS ਨਾਮ ਨਿਰਧਾਰਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹੋ, ਤਾਂ ਇਹ ਵਾਪਰਦਾ ਹੈ:

1. ਐਪਲੀਕੇਸ਼ਨ ਇੱਕ ਸਿਸਟਮ ਲਾਇਬ੍ਰੇਰੀ ਨੂੰ ਕਾਲ ਕਰਦੀ ਹੈ ਜਿਵੇਂ ਕਿ libdns
2. libdns ਸਿਸਟਮ ਸੰਰਚਨਾ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ ਕਿ ਇਸਨੂੰ ਕਿਸ DNS ਸਰਵਰ ਨਾਲ ਸੰਪਰਕ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ (ਡਾਇਗਰਾਮ ਵਿੱਚ ਇਹ 169.254.169.254 ਹੈ, ਮੈਟਾਡੇਟਾ ਸਰਵਰ)
3. libdns ਇੱਕ UDP ਸਾਕਟ (SOKET_DGRAM) ਬਣਾਉਣ ਲਈ ਸਿਸਟਮ ਕਾਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ ਅਤੇ ਦੋਨਾਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਇੱਕ DNS ਪੁੱਛਗਿੱਛ ਨਾਲ UDP ਪੈਕੇਟ ਭੇਜਦਾ ਹੈ।
4. sysctl ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਤੁਸੀਂ UDP ਸਟੈਕ ਨੂੰ ਕਰਨਲ ਪੱਧਰ 'ਤੇ ਸੰਰਚਿਤ ਕਰ ਸਕਦੇ ਹੋ।
5. ਨੈੱਟਵਰਕ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਨੈੱਟਵਰਕ ਉੱਤੇ ਪੈਕੇਟਾਂ ਨੂੰ ਸੰਚਾਰਿਤ ਕਰਨ ਲਈ ਕਰਨਲ ਹਾਰਡਵੇਅਰ ਨਾਲ ਇੰਟਰਫੇਸ ਕਰਦਾ ਹੈ
6. ਹਾਈਪਰਵਾਈਜ਼ਰ ਇਸ ਨਾਲ ਸੰਪਰਕ ਕਰਨ 'ਤੇ ਪੈਕੇਟ ਨੂੰ ਮੈਟਾਡੇਟਾ ਸਰਵਰ ਨੂੰ ਫੜਦਾ ਅਤੇ ਸੰਚਾਰਿਤ ਕਰਦਾ ਹੈ
7. ਮੈਟਾਡੇਟਾ ਸਰਵਰ, ਇਸਦੇ ਜਾਦੂ ਦੁਆਰਾ, DNS ਨਾਮ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਅਤੇ ਉਸੇ ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਜਵਾਬ ਦਿੰਦਾ ਹੈ

ਆਓ ਮੈਂ ਤੁਹਾਨੂੰ ਯਾਦ ਕਰਾਵਾਂ ਕਿ ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਕਿਹੜੀਆਂ ਧਾਰਨਾਵਾਂ 'ਤੇ ਵਿਚਾਰ ਕਰ ਚੁੱਕੇ ਹਾਂ:

ਹਾਇਪੋਥੀਸਿਸ: ਟੁੱਟੀਆਂ ਲਾਇਬ੍ਰੇਰੀਆਂ

• ਟੈਸਟ 1: ਸਿਸਟਮ ਵਿੱਚ ਸਟ੍ਰੈਸ ਚਲਾਓ, ਜਾਂਚ ਕਰੋ ਕਿ ਡਿਗ ਸਹੀ ਸਿਸਟਮ ਕਾਲਾਂ ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ
• ਨਤੀਜਾ: ਸਹੀ ਸਿਸਟਮ ਕਾਲਾਂ ਨੂੰ ਬੁਲਾਇਆ ਜਾਂਦਾ ਹੈ
• ਟੈਸਟ 2: ਇਹ ਜਾਂਚ ਕਰਨ ਲਈ ਕਿ ਕੀ ਅਸੀਂ ਸਿਸਟਮ ਲਾਇਬ੍ਰੇਰੀਆਂ ਨੂੰ ਬਾਈਪਾਸ ਕਰਦੇ ਹੋਏ ਨਾਮ ਨਿਰਧਾਰਤ ਕਰ ਸਕਦੇ ਹਾਂ, srapy ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ
• ਨਤੀਜਾ: ਅਸੀਂ ਕਰ ਸਕਦੇ ਹਾਂ
• ਟੈਸਟ 3: libdns ਪੈਕੇਜ ਅਤੇ md5sum ਲਾਇਬ੍ਰੇਰੀ ਫਾਈਲਾਂ ਉੱਤੇ rpm –V ਚਲਾਓ
• ਨਤੀਜਾ: ਲਾਇਬ੍ਰੇਰੀ ਕੋਡ ਕੰਮ ਕਰ ਰਹੇ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਵਿੱਚ ਕੋਡ ਨਾਲ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਮਾਨ ਹੈ
• ਟੈਸਟ 4: ਉਪਭੋਗਤਾ ਦੇ ਰੂਟ ਸਿਸਟਮ ਚਿੱਤਰ ਨੂੰ ਇਸ ਵਿਵਹਾਰ ਤੋਂ ਬਿਨਾਂ VM 'ਤੇ ਮਾਊਂਟ ਕਰੋ, ਕ੍ਰੋਟ ਚਲਾਓ, ਦੇਖੋ ਕਿ ਕੀ DNS ਕੰਮ ਕਰਦਾ ਹੈ
• ਨਤੀਜਾ: DNS ਸਹੀ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ

ਟੈਸਟਾਂ ਦੇ ਅਧਾਰ ਤੇ ਸਿੱਟਾ: ਸਮੱਸਿਆ ਲਾਇਬ੍ਰੇਰੀਆਂ ਵਿੱਚ ਨਹੀਂ ਹੈ

ਕਲਪਨਾ: DNS ਸੈਟਿੰਗਾਂ ਵਿੱਚ ਇੱਕ ਗਲਤੀ ਹੈ

• ਟੈਸਟ 1: tcpdump ਦੀ ਜਾਂਚ ਕਰੋ ਅਤੇ ਦੇਖੋ ਕਿ ਕੀ DNS ਪੈਕੇਟ ਭੇਜੇ ਗਏ ਹਨ ਅਤੇ ਡਿਗ ਚਲਾਉਣ ਤੋਂ ਬਾਅਦ ਸਹੀ ਢੰਗ ਨਾਲ ਵਾਪਸ ਕੀਤੇ ਗਏ ਹਨ
• ਨਤੀਜਾ: ਪੈਕੇਟ ਸਹੀ ਢੰਗ ਨਾਲ ਪ੍ਰਸਾਰਿਤ ਕੀਤੇ ਗਏ ਹਨ
• ਟੈਸਟ 2: ਸਰਵਰ 'ਤੇ ਦੋ ਵਾਰ ਜਾਂਚ ਕਰੋ /etc/nsswitch.conf и /etc/resolv.conf
• ਨਤੀਜਾ: ਸਭ ਕੁਝ ਸਹੀ ਹੈ

ਟੈਸਟਾਂ ਦੇ ਅਧਾਰ ਤੇ ਸਿੱਟਾ: ਸਮੱਸਿਆ DNS ਸੰਰਚਨਾ ਨਾਲ ਨਹੀਂ ਹੈ

ਪਰਿਕਲਪਨਾ: ਕੋਰ ਨੁਕਸਾਨ

• ਟੈਸਟ: ਨਵਾਂ ਕਰਨਲ ਸਥਾਪਿਤ ਕਰੋ, ਦਸਤਖਤ ਦੀ ਜਾਂਚ ਕਰੋ, ਮੁੜ ਚਾਲੂ ਕਰੋ
• ਨਤੀਜਾ: ਸਮਾਨ ਵਿਵਹਾਰ

ਟੈਸਟਾਂ ਦੇ ਅਧਾਰ ਤੇ ਸਿੱਟਾ: ਕਰਨਲ ਨੂੰ ਨੁਕਸਾਨ ਨਹੀਂ ਹੋਇਆ ਹੈ

ਹਾਇਪੋਥੀਸਿਸ: ਉਪਭੋਗਤਾ ਨੈਟਵਰਕ (ਜਾਂ ਹਾਈਪਰਵਾਈਜ਼ਰ ਨੈਟਵਰਕ ਇੰਟਰਫੇਸ) ਦਾ ਗਲਤ ਵਿਵਹਾਰ

• ਟੈਸਟ 1: ਆਪਣੀਆਂ ਫਾਇਰਵਾਲ ਸੈਟਿੰਗਾਂ ਦੀ ਜਾਂਚ ਕਰੋ
• ਨਤੀਜਾ: ਫਾਇਰਵਾਲ ਹੋਸਟ ਅਤੇ GCP ਦੋਵਾਂ 'ਤੇ DNS ਪੈਕੇਟ ਪਾਸ ਕਰਦੀ ਹੈ
• ਟੈਸਟ 2: ਟ੍ਰੈਫਿਕ ਨੂੰ ਰੋਕੋ ਅਤੇ DNS ਬੇਨਤੀਆਂ ਦੇ ਪ੍ਰਸਾਰਣ ਅਤੇ ਵਾਪਸੀ ਦੀ ਸ਼ੁੱਧਤਾ ਦੀ ਨਿਗਰਾਨੀ ਕਰੋ
• ਨਤੀਜਾ: tcpdump ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ ਕਿ ਹੋਸਟ ਨੇ ਵਾਪਸੀ ਪੈਕੇਟ ਪ੍ਰਾਪਤ ਕੀਤੇ ਹਨ

ਟੈਸਟਾਂ ਦੇ ਅਧਾਰ ਤੇ ਸਿੱਟਾ: ਸਮੱਸਿਆ ਨੈੱਟਵਰਕ ਵਿੱਚ ਨਹੀਂ ਹੈ

ਕਲਪਨਾ: ਮੈਟਾਡੇਟਾ ਸਰਵਰ ਕੰਮ ਨਹੀਂ ਕਰ ਰਿਹਾ ਹੈ

• ਟੈਸਟ 1: ਗੜਬੜੀਆਂ ਲਈ ਮੈਟਾਡੇਟਾ ਸਰਵਰ ਲੌਗਸ ਦੀ ਜਾਂਚ ਕਰੋ
• ਨਤੀਜਾ: ਲੌਗਸ ਵਿੱਚ ਕੋਈ ਅਸੰਗਤੀਆਂ ਨਹੀਂ ਹਨ
• ਟੈਸਟ 2: ਦੁਆਰਾ ਮੈਟਾਡੇਟਾ ਸਰਵਰ ਨੂੰ ਬਾਈਪਾਸ ਕਰੋ dig @8.8.8.8
• ਨਤੀਜਾ: ਮੈਟਾਡੇਟਾ ਸਰਵਰ ਦੀ ਵਰਤੋਂ ਕੀਤੇ ਬਿਨਾਂ ਵੀ ਰੈਜ਼ੋਲਿਊਸ਼ਨ ਟੁੱਟ ਗਿਆ ਹੈ

ਟੈਸਟਾਂ ਦੇ ਅਧਾਰ ਤੇ ਸਿੱਟਾ: ਸਮੱਸਿਆ ਮੈਟਾਡੇਟਾ ਸਰਵਰ ਨਾਲ ਨਹੀਂ ਹੈ

ਨਤੀਜੇ: ਅਸੀਂ ਸਿਵਾਏ ਸਾਰੇ ਉਪ-ਸਿਸਟਮਾਂ ਦੀ ਜਾਂਚ ਕੀਤੀ ਰਨਟਾਈਮ ਸੈਟਿੰਗਾਂ!

ਕਰਨਲ ਰਨਟਾਈਮ ਸੈਟਿੰਗਾਂ ਵਿੱਚ ਗੋਤਾਖੋਰੀ

ਕਰਨਲ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਐਨਵਾਇਰਮੈਂਟ ਨੂੰ ਸੰਰਚਿਤ ਕਰਨ ਲਈ, ਤੁਸੀਂ ਕਮਾਂਡ ਲਾਈਨ ਚੋਣਾਂ (grub) ਜਾਂ sysctl ਇੰਟਰਫੇਸ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ। ਮੈਂ ਅੰਦਰ ਦੇਖਿਆ /etc/sysctl.conf ਅਤੇ ਜ਼ਰਾ ਸੋਚੋ, ਮੈਂ ਕਈ ਕਸਟਮ ਸੈਟਿੰਗਾਂ ਲੱਭੀਆਂ ਹਨ। ਇਹ ਮਹਿਸੂਸ ਕਰਦੇ ਹੋਏ ਜਿਵੇਂ ਮੈਂ ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਫੜ ਲਿਆ ਹੈ, ਮੈਂ ਪਹਾੜੀ ਸੈਟਿੰਗਾਂ ਦੇ ਨਾਲ ਬਾਕੀ ਸਾਰੀਆਂ ਗੈਰ-ਨੈੱਟਵਰਕ ਜਾਂ ਗੈਰ-tcp ਸੈਟਿੰਗਾਂ ਨੂੰ ਰੱਦ ਕਰ ਦਿੱਤਾ ਹੈ net.core. ਫਿਰ ਮੈਂ ਉੱਥੇ ਗਿਆ ਜਿੱਥੇ ਹੋਸਟ ਅਨੁਮਤੀਆਂ VM ਵਿੱਚ ਸਨ ਅਤੇ ਟੁੱਟੇ ਹੋਏ VM ਦੇ ਨਾਲ ਇੱਕ ਤੋਂ ਬਾਅਦ ਇੱਕ ਸੈਟਿੰਗਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ, ਜਦੋਂ ਤੱਕ ਮੈਨੂੰ ਦੋਸ਼ੀ ਨਹੀਂ ਮਿਲਿਆ:

net.core.rmem_default = 2147483647

ਇਹ ਇੱਥੇ ਹੈ, ਇੱਕ DNS-ਤੋੜਨ ਵਾਲੀ ਸੰਰਚਨਾ! ਮੈਨੂੰ ਕਤਲ ਦਾ ਹਥਿਆਰ ਮਿਲਿਆ ਹੈ। ਪਰ ਅਜਿਹਾ ਕਿਉਂ ਹੋ ਰਿਹਾ ਹੈ? ਮੈਨੂੰ ਅਜੇ ਵੀ ਇੱਕ ਮਨੋਰਥ ਦੀ ਲੋੜ ਸੀ।

ਮੂਲ DNS ਪੈਕੇਟ ਬਫਰ ਆਕਾਰ ਦੁਆਰਾ ਸੰਰਚਿਤ ਕੀਤਾ ਗਿਆ ਹੈ net.core.rmem_default. ਇੱਕ ਆਮ ਮੁੱਲ ਕਿਤੇ 200KiB ਦੇ ਆਸਪਾਸ ਹੁੰਦਾ ਹੈ, ਪਰ ਜੇਕਰ ਤੁਹਾਡੇ ਸਰਵਰ ਨੂੰ ਬਹੁਤ ਸਾਰੇ DNS ਪੈਕੇਟ ਪ੍ਰਾਪਤ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਬਫਰ ਦਾ ਆਕਾਰ ਵਧਾਉਣਾ ਚਾਹ ਸਕਦੇ ਹੋ। ਜੇਕਰ ਨਵਾਂ ਪੈਕੇਟ ਆਉਣ 'ਤੇ ਬਫਰ ਭਰ ਗਿਆ ਹੈ, ਉਦਾਹਰਨ ਲਈ ਕਿਉਂਕਿ ਐਪਲੀਕੇਸ਼ਨ ਇਸਦੀ ਤੇਜ਼ੀ ਨਾਲ ਪ੍ਰਕਿਰਿਆ ਨਹੀਂ ਕਰ ਰਹੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਪੈਕੇਟ ਗੁਆਉਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿਓਗੇ। ਸਾਡੇ ਕਲਾਇੰਟ ਨੇ ਸਹੀ ਢੰਗ ਨਾਲ ਬਫਰ ਦਾ ਆਕਾਰ ਵਧਾਇਆ ਕਿਉਂਕਿ ਉਹ ਡੇਟਾ ਦੇ ਨੁਕਸਾਨ ਤੋਂ ਡਰਦਾ ਸੀ, ਕਿਉਂਕਿ ਉਹ DNS ਪੈਕੇਟ ਦੁਆਰਾ ਮੈਟ੍ਰਿਕਸ ਇਕੱਠਾ ਕਰਨ ਲਈ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰ ਰਿਹਾ ਸੀ। ਉਸ ਦੁਆਰਾ ਸੈੱਟ ਕੀਤਾ ਮੁੱਲ ਵੱਧ ਤੋਂ ਵੱਧ ਸੰਭਵ ਸੀ: 231-1 (ਜੇਕਰ 231 'ਤੇ ਸੈੱਟ ਕੀਤਾ ਗਿਆ ਹੈ, ਤਾਂ ਕਰਨਲ "ਅਵੈਧ ਆਰਗੂਮੈਂਟ" ਵਾਪਸ ਕਰੇਗਾ)।

ਅਚਾਨਕ ਮੈਨੂੰ ਅਹਿਸਾਸ ਹੋਇਆ ਕਿ ਕਿਉਂ nmap ਅਤੇ scapy ਸਹੀ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਨ: ਉਹ ਕੱਚੇ ਸਾਕਟ ਵਰਤ ਰਹੇ ਸਨ! ਕੱਚੇ ਸਾਕਟ ਨਿਯਮਤ ਸਾਕਟਾਂ ਤੋਂ ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ: ਉਹ iptables ਨੂੰ ਬਾਈਪਾਸ ਕਰਦੇ ਹਨ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਬਫਰ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ!

ਪਰ "ਬਫਰ ਬਹੁਤ ਵੱਡਾ" ਸਮੱਸਿਆਵਾਂ ਕਿਉਂ ਪੈਦਾ ਕਰਦਾ ਹੈ? ਇਹ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਇਰਾਦੇ ਅਨੁਸਾਰ ਕੰਮ ਨਹੀਂ ਕਰਦਾ ਹੈ।

ਇਸ ਬਿੰਦੂ 'ਤੇ ਮੈਂ ਮਲਟੀਪਲ ਕਰਨਲ ਅਤੇ ਮਲਟੀਪਲ ਡਿਸਟਰੀਬਿਊਸ਼ਨਾਂ 'ਤੇ ਸਮੱਸਿਆ ਨੂੰ ਦੁਬਾਰਾ ਤਿਆਰ ਕਰ ਸਕਦਾ ਹਾਂ। ਸਮੱਸਿਆ ਪਹਿਲਾਂ ਹੀ 3.x ਕਰਨਲ 'ਤੇ ਦਿਖਾਈ ਦਿੱਤੀ ਹੈ ਅਤੇ ਹੁਣ ਇਹ 5.x ਕਰਨਲ 'ਤੇ ਵੀ ਦਿਖਾਈ ਦਿੱਤੀ ਹੈ।

ਦਰਅਸਲ, ਸ਼ੁਰੂਆਤ 'ਤੇ

sysctl -w net.core.rmem_default=$((2**31-1))

DNS ਨੇ ਕੰਮ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੱਤਾ।

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

ਮੈਂ ਸਥਾਪਿਤ ਕੀਤਾ ਹੈ ਡਰਾਪਵਾਚ, ਇੱਕ ਟੂਲ ਜੋ ਪਹਿਲਾਂ ਵਰਤਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਸੀ: ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਕਰਨਲ ਵਿੱਚ ਇੱਕ ਪੈਕੇਟ ਕਿੱਥੇ ਖਤਮ ਹੁੰਦਾ ਹੈ। ਦੋਸ਼ੀ ਫੰਕਸ਼ਨ ਸੀ udp_queue_rcv_skb. ਮੈਂ ਕਰਨਲ ਸਰੋਤਾਂ ਨੂੰ ਡਾਊਨਲੋਡ ਕੀਤਾ ਅਤੇ ਕੁਝ ਜੋੜਿਆ ਫੰਕਸ਼ਨ printk ਇਹ ਪਤਾ ਲਗਾਉਣ ਲਈ ਕਿ ਪੈਕੇਟ ਕਿੱਥੇ ਖਤਮ ਹੁੰਦਾ ਹੈ। ਮੈਨੂੰ ਜਲਦੀ ਸਹੀ ਸਥਿਤੀ ਮਿਲ ਗਈ if, ਅਤੇ ਬਸ ਕੁਝ ਸਮੇਂ ਲਈ ਇਸ ਨੂੰ ਵੇਖਦਾ ਰਿਹਾ, ਕਿਉਂਕਿ ਇਹ ਉਦੋਂ ਸੀ ਜਦੋਂ ਅੰਤ ਵਿੱਚ ਸਭ ਕੁਝ ਇੱਕ ਪੂਰੀ ਤਸਵੀਰ ਵਿੱਚ ਆ ਗਿਆ ਸੀ: 231-1, ਇੱਕ ਅਰਥਹੀਣ ਸੰਖਿਆ, ਇੱਕ ਗੈਰ-ਕਾਰਜਸ਼ੀਲ ਡੋਮੇਨ... ਇਹ ਕੋਡ ਦਾ ਇੱਕ ਟੁਕੜਾ ਸੀ __udp_enqueue_schedule_skb:

if (rmem > (size + sk->sk_rcvbuf))
		goto uncharge_drop;

ਕਿਰਪਾ ਕਰਕੇ ਨੋਟ ਕਰੋ:

• rmem int ਦੀ ਕਿਸਮ ਹੈ
• size u16 (ਅਨ-ਹਸਤਾਖਰਿਤ ਸੋਲ੍ਹਾਂ-ਬਿੱਟ ਇੰਟ) ਦੀ ਕਿਸਮ ਹੈ ਅਤੇ ਪੈਕੇਟ ਦਾ ਆਕਾਰ ਸਟੋਰ ਕਰਦਾ ਹੈ
• sk->sk_rcybuf int ਕਿਸਮ ਦਾ ਹੈ ਅਤੇ ਬਫਰ ਆਕਾਰ ਨੂੰ ਸਟੋਰ ਕਰਦਾ ਹੈ ਜੋ, ਪਰਿਭਾਸ਼ਾ ਅਨੁਸਾਰ, ਵਿੱਚ ਮੁੱਲ ਦੇ ਬਰਾਬਰ ਹੈ net.core.rmem_default

ਕਦੋਂ sk_rcvbuf 231 ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ, ਪੈਕੇਟ ਦੇ ਆਕਾਰ ਦਾ ਸਾਰ ਕਰਨ ਦਾ ਨਤੀਜਾ ਹੋ ਸਕਦਾ ਹੈ ਪੂਰਨ ਅੰਕ ਓਵਰਫਲੋ. ਅਤੇ ਕਿਉਂਕਿ ਇਹ ਇੱਕ ਇੰਟ ਹੈ, ਇਸਦਾ ਮੁੱਲ ਨਕਾਰਾਤਮਕ ਬਣ ਜਾਂਦਾ ਹੈ, ਇਸਲਈ ਸਥਿਤੀ ਸਹੀ ਬਣ ਜਾਂਦੀ ਹੈ ਜਦੋਂ ਇਹ ਗਲਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ (ਤੁਸੀਂ ਇਸ ਬਾਰੇ ਹੋਰ ਪੜ੍ਹ ਸਕਦੇ ਹੋ ਲਿੰਕ ਨੂੰ).

ਗਲਤੀ ਨੂੰ ਮਾਮੂਲੀ ਤਰੀਕੇ ਨਾਲ ਠੀਕ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ: ਕਾਸਟਿੰਗ ਦੁਆਰਾ unsigned int. ਮੈਂ ਫਿਕਸ ਨੂੰ ਲਾਗੂ ਕੀਤਾ ਅਤੇ ਸਿਸਟਮ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕੀਤਾ ਅਤੇ DNS ਨੇ ਦੁਬਾਰਾ ਕੰਮ ਕੀਤਾ।

ਜਿੱਤ ਦਾ ਸਵਾਦ

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

ਇਹ ਪਛਾਣਨ ਯੋਗ ਹੈ ਕਿ ਕੇਸ ਬਹੁਤ ਘੱਟ ਨਿਕਲਿਆ, ਅਤੇ ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ ਸਾਨੂੰ ਉਪਭੋਗਤਾਵਾਂ ਤੋਂ ਅਜਿਹੀਆਂ ਗੁੰਝਲਦਾਰ ਬੇਨਤੀਆਂ ਘੱਟ ਹੀ ਮਿਲਦੀਆਂ ਹਨ।

ਸਰੋਤ: www.habr.com