Google ಕ್ಲೌಡ್ ತಾಂತ್ರಿಕ ಬೆಂಬಲದಿಂದ ಕಾಣೆಯಾದ DNS ಪ್ಯಾಕೆಟ್‌ಗಳ ಕುರಿತಾದ ಕಥೆ

Google ಬ್ಲಾಗ್ ಸಂಪಾದಕದಿಂದ: Google ಕ್ಲೌಡ್ ಟೆಕ್ನಿಕಲ್ ಸೊಲ್ಯೂಷನ್ಸ್ (TSE) ಎಂಜಿನಿಯರ್‌ಗಳು ನಿಮ್ಮ ಬೆಂಬಲ ವಿನಂತಿಗಳನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸುತ್ತಾರೆ ಎಂದು ನೀವು ಎಂದಾದರೂ ಯೋಚಿಸಿದ್ದೀರಾ? TSE ತಾಂತ್ರಿಕ ಬೆಂಬಲ ಎಂಜಿನಿಯರ್‌ಗಳು ಬಳಕೆದಾರ-ವರದಿ ಮಾಡಿದ ಸಮಸ್ಯೆಗಳ ಮೂಲಗಳನ್ನು ಗುರುತಿಸಲು ಮತ್ತು ಸರಿಪಡಿಸಲು ಜವಾಬ್ದಾರರಾಗಿರುತ್ತಾರೆ. ಈ ಕೆಲವು ಸಮಸ್ಯೆಗಳು ತುಂಬಾ ಸರಳವಾಗಿದೆ, ಆದರೆ ಕೆಲವೊಮ್ಮೆ ನೀವು ಏಕಕಾಲದಲ್ಲಿ ಹಲವಾರು ಎಂಜಿನಿಯರ್‌ಗಳ ಗಮನ ಅಗತ್ಯವಿರುವ ಟಿಕೆಟ್ ಅನ್ನು ನೋಡುತ್ತೀರಿ. ಈ ಲೇಖನದಲ್ಲಿ, TSE ಉದ್ಯೋಗಿಗಳಲ್ಲಿ ಒಬ್ಬರು ತಮ್ಮ ಇತ್ತೀಚಿನ ಅಭ್ಯಾಸದಿಂದ ಒಂದು ಅತ್ಯಂತ ಟ್ರಿಕಿ ಸಮಸ್ಯೆಯ ಬಗ್ಗೆ ನಮಗೆ ತಿಳಿಸುತ್ತಾರೆ - ಕಾಣೆಯಾದ DNS ಪ್ಯಾಕೆಟ್‌ಗಳ ಪ್ರಕರಣ. ಈ ಕಥೆಯಲ್ಲಿ, ಎಂಜಿನಿಯರ್‌ಗಳು ಪರಿಸ್ಥಿತಿಯನ್ನು ಹೇಗೆ ಪರಿಹರಿಸಿದರು ಮತ್ತು ದೋಷವನ್ನು ಸರಿಪಡಿಸುವಾಗ ಅವರು ಯಾವ ಹೊಸ ವಿಷಯಗಳನ್ನು ಕಲಿತರು ಎಂಬುದನ್ನು ನಾವು ನೋಡುತ್ತೇವೆ. ಈ ಕಥೆಯು ನಿಮಗೆ ಆಳವಾದ ದೋಷದ ಕುರಿತು ಶಿಕ್ಷಣ ನೀಡುವುದಲ್ಲದೆ, Google ಕ್ಲೌಡ್‌ನೊಂದಿಗೆ ಬೆಂಬಲ ಟಿಕೆಟ್ ಅನ್ನು ಸಲ್ಲಿಸುವ ಪ್ರಕ್ರಿಯೆಗಳ ಕುರಿತು ಒಳನೋಟವನ್ನು ನೀಡುತ್ತದೆ ಎಂದು ನಾವು ಭಾವಿಸುತ್ತೇವೆ.

ದೋಷನಿವಾರಣೆ ಒಂದು ವಿಜ್ಞಾನ ಮತ್ತು ಕಲೆ ಎರಡೂ ಆಗಿದೆ. ಸಿಸ್ಟಮ್ನ ಪ್ರಮಾಣಿತವಲ್ಲದ ನಡವಳಿಕೆಯ ಕಾರಣದ ಬಗ್ಗೆ ಒಂದು ಊಹೆಯನ್ನು ನಿರ್ಮಿಸುವುದರೊಂದಿಗೆ ಇದು ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, ನಂತರ ಅದನ್ನು ಶಕ್ತಿಗಾಗಿ ಪರೀಕ್ಷಿಸಲಾಗುತ್ತದೆ. ಆದಾಗ್ಯೂ, ನಾವು ಊಹೆಯನ್ನು ರೂಪಿಸುವ ಮೊದಲು, ನಾವು ಸಮಸ್ಯೆಯನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಬೇಕು ಮತ್ತು ನಿಖರವಾಗಿ ರೂಪಿಸಬೇಕು. ಪ್ರಶ್ನೆಯು ತುಂಬಾ ಅಸ್ಪಷ್ಟವಾಗಿದ್ದರೆ, ನೀವು ಎಲ್ಲವನ್ನೂ ಎಚ್ಚರಿಕೆಯಿಂದ ವಿಶ್ಲೇಷಿಸಬೇಕಾಗುತ್ತದೆ; ಇದು ದೋಷನಿವಾರಣೆಯ "ಕಲೆ".

Google ಕ್ಲೌಡ್ ಅಡಿಯಲ್ಲಿ, ಅಂತಹ ಪ್ರಕ್ರಿಯೆಗಳು ಘಾತೀಯವಾಗಿ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗುತ್ತವೆ, ಏಕೆಂದರೆ Google ಕ್ಲೌಡ್ ತನ್ನ ಬಳಕೆದಾರರ ಗೌಪ್ಯತೆಯನ್ನು ಖಾತರಿಪಡಿಸಲು ಅತ್ಯುತ್ತಮವಾಗಿ ಪ್ರಯತ್ನಿಸುತ್ತದೆ. ಈ ಕಾರಣದಿಂದಾಗಿ, TSE ಇಂಜಿನಿಯರ್‌ಗಳು ನಿಮ್ಮ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ಸಂಪಾದಿಸಲು ಪ್ರವೇಶವನ್ನು ಹೊಂದಿಲ್ಲ, ಅಥವಾ ಬಳಕೆದಾರರು ಮಾಡುವಂತೆ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳನ್ನು ವಿಶಾಲವಾಗಿ ವೀಕ್ಷಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ, ನಮ್ಮ ಯಾವುದೇ ಊಹೆಗಳನ್ನು ಪರೀಕ್ಷಿಸಲು, ನಾವು (ಎಂಜಿನಿಯರ್‌ಗಳು) ವ್ಯವಸ್ಥೆಯನ್ನು ತ್ವರಿತವಾಗಿ ಮಾರ್ಪಡಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.

ಕಾರ್ ಸೇವೆಯಲ್ಲಿ ಮೆಕ್ಯಾನಿಕ್ಸ್‌ನಂತಹ ಎಲ್ಲವನ್ನೂ ನಾವು ಸರಿಪಡಿಸುತ್ತೇವೆ ಮತ್ತು ವರ್ಚುವಲ್ ಯಂತ್ರದ ಐಡಿಯನ್ನು ನಮಗೆ ಕಳುಹಿಸುತ್ತೇವೆ ಎಂದು ಕೆಲವು ಬಳಕೆದಾರರು ನಂಬುತ್ತಾರೆ, ಆದರೆ ವಾಸ್ತವದಲ್ಲಿ ಪ್ರಕ್ರಿಯೆಯು ಸಂವಾದಾತ್ಮಕ ಸ್ವರೂಪದಲ್ಲಿ ನಡೆಯುತ್ತದೆ: ಮಾಹಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸುವುದು, ರೂಪಿಸುವುದು ಮತ್ತು ದೃಢೀಕರಿಸುವುದು (ಅಥವಾ ನಿರಾಕರಿಸುವುದು) ಕಲ್ಪನೆಗಳು, ಮತ್ತು, ಕೊನೆಯಲ್ಲಿ, ನಿರ್ಧಾರದ ಸಮಸ್ಯೆಗಳು ಕ್ಲೈಂಟ್‌ನೊಂದಿಗಿನ ಸಂವಹನವನ್ನು ಆಧರಿಸಿವೆ.

ಪ್ರಶ್ನೆಯಲ್ಲಿ ಸಮಸ್ಯೆ

ಇಂದು ನಾವು ಉತ್ತಮ ಅಂತ್ಯವನ್ನು ಹೊಂದಿರುವ ಕಥೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಪ್ರಸ್ತಾವಿತ ಪ್ರಕರಣದ ಯಶಸ್ವಿ ಪರಿಹಾರಕ್ಕೆ ಒಂದು ಕಾರಣವೆಂದರೆ ಸಮಸ್ಯೆಯ ವಿವರವಾದ ಮತ್ತು ನಿಖರವಾದ ವಿವರಣೆಯಾಗಿದೆ. ಕೆಳಗೆ ನೀವು ಮೊದಲ ಟಿಕೆಟ್‌ನ ನಕಲನ್ನು ನೋಡಬಹುದು (ಗೌಪ್ಯ ಮಾಹಿತಿಯನ್ನು ಮರೆಮಾಡಲು ಸಂಪಾದಿಸಲಾಗಿದೆ):

ಈ ಸಂದೇಶವು ನಮಗೆ ಸಾಕಷ್ಟು ಉಪಯುಕ್ತ ಮಾಹಿತಿಯನ್ನು ಒಳಗೊಂಡಿದೆ:

• ನಿರ್ದಿಷ್ಟ VM ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಲಾಗಿದೆ
• ಸಮಸ್ಯೆಯನ್ನು ಸ್ವತಃ ಸೂಚಿಸಲಾಗುತ್ತದೆ - DNS ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ
• ವಿಎಂ ಮತ್ತು ಕಂಟೇನರ್ - ಸಮಸ್ಯೆಯು ಎಲ್ಲಿ ಪ್ರಕಟವಾಗುತ್ತದೆ ಎಂದು ಸೂಚಿಸಲಾಗುತ್ತದೆ
• ಸಮಸ್ಯೆಯನ್ನು ಗುರುತಿಸಲು ಬಳಕೆದಾರರು ತೆಗೆದುಕೊಂಡ ಕ್ರಮಗಳನ್ನು ಸೂಚಿಸಲಾಗುತ್ತದೆ.

ವಿನಂತಿಯನ್ನು "P1: ಕ್ರಿಟಿಕಲ್ ಇಂಪ್ಯಾಕ್ಟ್ - ಉತ್ಪಾದನೆಯಲ್ಲಿ ಬಳಸಲಾಗದ ಸೇವೆ" ಎಂದು ನೋಂದಾಯಿಸಲಾಗಿದೆ, ಅಂದರೆ "ಸೂರ್ಯನನ್ನು ಅನುಸರಿಸಿ" ಯೋಜನೆಯ ಪ್ರಕಾರ 24/7 ಪರಿಸ್ಥಿತಿಯ ನಿರಂತರ ಮೇಲ್ವಿಚಾರಣೆ (ನೀವು ಇದರ ಬಗ್ಗೆ ಇನ್ನಷ್ಟು ಓದಬಹುದು ಬಳಕೆದಾರರ ವಿನಂತಿಗಳ ಆದ್ಯತೆಗಳು), ಪ್ರತಿ ಸಮಯ ವಲಯ ಬದಲಾವಣೆಯೊಂದಿಗೆ ಒಂದು ತಾಂತ್ರಿಕ ಬೆಂಬಲ ತಂಡದಿಂದ ಇನ್ನೊಂದಕ್ಕೆ ಅದರ ವರ್ಗಾವಣೆಯೊಂದಿಗೆ. ವಾಸ್ತವವಾಗಿ, ಸಮಸ್ಯೆಯು ಜ್ಯೂರಿಚ್‌ನಲ್ಲಿರುವ ನಮ್ಮ ತಂಡವನ್ನು ತಲುಪುವ ಹೊತ್ತಿಗೆ, ಅದು ಈಗಾಗಲೇ ಜಗತ್ತನ್ನು ಸುತ್ತಿತ್ತು. ಈ ಹೊತ್ತಿಗೆ, ಬಳಕೆದಾರರು ಉಪಶಮನದ ಕ್ರಮಗಳನ್ನು ತೆಗೆದುಕೊಂಡರು, ಆದರೆ ಉತ್ಪಾದನೆಯಲ್ಲಿನ ಪರಿಸ್ಥಿತಿಯ ಪುನರಾವರ್ತನೆಗೆ ಹೆದರುತ್ತಿದ್ದರು, ಏಕೆಂದರೆ ಮೂಲ ಕಾರಣವನ್ನು ಇನ್ನೂ ಕಂಡುಹಿಡಿಯಲಾಗಿಲ್ಲ.

ಟಿಕೆಟ್ ಜ್ಯೂರಿಚ್ ತಲುಪುವ ಹೊತ್ತಿಗೆ, ನಾವು ಈಗಾಗಲೇ ಈ ಕೆಳಗಿನ ಮಾಹಿತಿಯನ್ನು ಕೈಯಲ್ಲಿ ಹೊಂದಿದ್ದೇವೆ:

• ವಿಷಯ /etc/hosts
• ವಿಷಯ /etc/resolv.conf
• ತೀರ್ಮಾನಕ್ಕೆ iptables-save
• ತಂಡದಿಂದ ಜೋಡಿಸಲಾಗಿದೆ ngrep pcap ಫೈಲ್

ಈ ಡೇಟಾದೊಂದಿಗೆ, ನಾವು "ತನಿಖೆ" ಮತ್ತು ದೋಷನಿವಾರಣೆ ಹಂತವನ್ನು ಪ್ರಾರಂಭಿಸಲು ಸಿದ್ಧರಿದ್ದೇವೆ.

ನಮ್ಮ ಮೊದಲ ಹೆಜ್ಜೆಗಳು

ಮೊದಲನೆಯದಾಗಿ, ನಾವು ಮೆಟಾಡೇಟಾ ಸರ್ವರ್‌ನ ಲಾಗ್‌ಗಳು ಮತ್ತು ಸ್ಥಿತಿಯನ್ನು ಪರಿಶೀಲಿಸಿದ್ದೇವೆ ಮತ್ತು ಅದು ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಂಡಿದ್ದೇವೆ. ಮೆಟಾಡೇಟಾ ಸರ್ವರ್ IP ವಿಳಾಸ 169.254.169.254 ಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ ಮತ್ತು ಇತರ ವಿಷಯಗಳ ಜೊತೆಗೆ, ಡೊಮೇನ್ ಹೆಸರುಗಳನ್ನು ನಿಯಂತ್ರಿಸುವ ಜವಾಬ್ದಾರಿಯನ್ನು ಹೊಂದಿದೆ. ಫೈರ್‌ವಾಲ್ VM ನೊಂದಿಗೆ ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ನಿರ್ಬಂಧಿಸುವುದಿಲ್ಲ ಎಂದು ನಾವು ಎರಡು ಬಾರಿ ಪರಿಶೀಲಿಸಿದ್ದೇವೆ.

ಇದು ಒಂದು ರೀತಿಯ ವಿಚಿತ್ರ ಸಮಸ್ಯೆಯಾಗಿದೆ: nmap ಪರಿಶೀಲನೆಯು UDP ಪ್ಯಾಕೆಟ್‌ಗಳ ನಷ್ಟದ ಬಗ್ಗೆ ನಮ್ಮ ಮುಖ್ಯ ಊಹೆಯನ್ನು ನಿರಾಕರಿಸಿದೆ, ಆದ್ದರಿಂದ ನಾವು ಮಾನಸಿಕವಾಗಿ ಹಲವಾರು ಆಯ್ಕೆಗಳು ಮತ್ತು ಅವುಗಳನ್ನು ಪರಿಶೀಲಿಸುವ ವಿಧಾನಗಳೊಂದಿಗೆ ಬಂದಿದ್ದೇವೆ:

• ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಆಯ್ದವಾಗಿ ಬಿಡಲಾಗಿದೆಯೇ? => iptables ನಿಯಮಗಳನ್ನು ಪರಿಶೀಲಿಸಿ
• ಇದು ತುಂಬಾ ಚಿಕ್ಕದಲ್ಲವೇ? ಎಂಟಿಯು? => ಔಟ್‌ಪುಟ್ ಪರಿಶೀಲಿಸಿ ip a show
• ಸಮಸ್ಯೆಯು ಕೇವಲ UDP ಪ್ಯಾಕೆಟ್‌ಗಳು ಅಥವಾ TCP ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆಯೇ? => ಓಡಿಸಿ dig +tcp
• ಅಗೆಯುವ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಹಿಂತಿರುಗಿಸಲಾಗಿದೆಯೇ? => ಓಡಿಸಿ tcpdump
• ಲಿಬ್ಡಿನ್ಸ್ ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆಯೇ? => ಓಡಿಸಿ strace ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಪ್ಯಾಕೆಟ್‌ಗಳ ಪ್ರಸರಣವನ್ನು ಪರಿಶೀಲಿಸಲು

ಸಮಸ್ಯೆಗಳನ್ನು ಲೈವ್ ಆಗಿ ಪರಿಹರಿಸಲು ಬಳಕೆದಾರರನ್ನು ಕರೆ ಮಾಡಲು ನಾವು ಇಲ್ಲಿ ನಿರ್ಧರಿಸುತ್ತೇವೆ.

ಕರೆಯ ಸಮಯದಲ್ಲಿ ನಾವು ಹಲವಾರು ವಿಷಯಗಳನ್ನು ಪರಿಶೀಲಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ:

• ಹಲವಾರು ಪರಿಶೀಲನೆಗಳ ನಂತರ ನಾವು iptables ನಿಯಮಗಳನ್ನು ಕಾರಣಗಳ ಪಟ್ಟಿಯಿಂದ ಹೊರಗಿಡುತ್ತೇವೆ
• ನಾವು ನೆಟ್‌ವರ್ಕ್ ಇಂಟರ್‌ಫೇಸ್‌ಗಳು ಮತ್ತು ರೂಟಿಂಗ್ ಟೇಬಲ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತೇವೆ ಮತ್ತು MTU ಸರಿಯಾಗಿದೆಯೇ ಎಂದು ಎರಡು ಬಾರಿ ಪರಿಶೀಲಿಸುತ್ತೇವೆ
• ನಾವು ಅದನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತೇವೆ dig +tcp google.com (TCP) ಕೆಲಸ ಮಾಡಬೇಕು, ಆದರೆ dig google.com (ಯುಡಿಪಿ) ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ
• ಓಡಿಸಿದ ನಂತರ 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. UDP ಸಾಕೆಟ್ (SOKET_DGRAM) ರಚಿಸಲು ಮತ್ತು ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ DNS ಪ್ರಶ್ನೆಯೊಂದಿಗೆ UDP ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಕಳುಹಿಸಲು libdns ಸಿಸ್ಟಮ್ ಕರೆಗಳನ್ನು ಬಳಸುತ್ತದೆ.
4. sysctl ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ನೀವು UDP ಸ್ಟಾಕ್ ಅನ್ನು ಕರ್ನಲ್ ಮಟ್ಟದಲ್ಲಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು
5. ನೆಟ್ವರ್ಕ್ ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ರವಾನಿಸಲು ಕರ್ನಲ್ ಹಾರ್ಡ್ವೇರ್ನೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುತ್ತದೆ
6. ಹೈಪರ್ವೈಸರ್ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಮೆಟಾಡೇಟಾ ಸರ್ವರ್ ಅನ್ನು ಸಂಪರ್ಕಿಸಿದಾಗ ಅದನ್ನು ಕ್ಯಾಚ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ರವಾನಿಸುತ್ತದೆ
7. ಮೆಟಾಡೇಟಾ ಸರ್ವರ್, ಅದರ ಮ್ಯಾಜಿಕ್ ಮೂಲಕ, DNS ಹೆಸರನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ ಮತ್ತು ಅದೇ ವಿಧಾನವನ್ನು ಬಳಸಿಕೊಂಡು ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ನೀಡುತ್ತದೆ

ನಾವು ಈಗಾಗಲೇ ಪರಿಗಣಿಸಿರುವ ಊಹೆಗಳನ್ನು ನಾನು ನಿಮಗೆ ನೆನಪಿಸುತ್ತೇನೆ:

ಕಲ್ಪನೆ: ಮುರಿದ ಗ್ರಂಥಾಲಯಗಳು

• ಪರೀಕ್ಷೆ 1: ಸಿಸ್ಟಂನಲ್ಲಿ ಸ್ಟ್ರೇಸ್ ಅನ್ನು ರನ್ ಮಾಡಿ, ಡಿಗ್ ಸರಿಯಾದ ಸಿಸ್ಟಮ್ ಕರೆಗಳನ್ನು ಕರೆಯುತ್ತದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ
• ಫಲಿತಾಂಶ: ಸರಿಯಾದ ಸಿಸ್ಟಮ್ ಕರೆಗಳನ್ನು ಕರೆಯಲಾಗುತ್ತದೆ
• ಪರೀಕ್ಷೆ 2: ಸಿಸ್ಟಮ್ ಲೈಬ್ರರಿಗಳನ್ನು ಬೈಪಾಸ್ ಮಾಡುವ ಹೆಸರುಗಳನ್ನು ನಾವು ನಿರ್ಧರಿಸಬಹುದೇ ಎಂದು ಪರಿಶೀಲಿಸಲು ಸ್ರ್ಯಾಪಿಯನ್ನು ಬಳಸುವುದು
• ಫಲಿತಾಂಶ: ನಾವು ಮಾಡಬಹುದು
• ಪರೀಕ್ಷೆ 3: libdns ಪ್ಯಾಕೇಜ್ ಮತ್ತು md5sum ಲೈಬ್ರರಿ ಫೈಲ್‌ಗಳಲ್ಲಿ rpm -V ಅನ್ನು ರನ್ ಮಾಡಿ
• ಫಲಿತಾಂಶ: ಲೈಬ್ರರಿ ಕೋಡ್ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿರುವ ಕೋಡ್‌ಗೆ ಸಂಪೂರ್ಣವಾಗಿ ಹೋಲುತ್ತದೆ
• ಪರೀಕ್ಷೆ 4: ಈ ನಡವಳಿಕೆಯಿಲ್ಲದೆ ಬಳಕೆದಾರರ ರೂಟ್ ಸಿಸ್ಟಮ್ ಇಮೇಜ್ ಅನ್ನು VM ನಲ್ಲಿ ಆರೋಹಿಸಿ, chroot ಅನ್ನು ರನ್ ಮಾಡಿ, 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 ಮತ್ತು ಯೋಚಿಸಿ, ನಾನು ಹಲವಾರು ಕಸ್ಟಮ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಕಂಡುಹಿಡಿದಿದ್ದೇನೆ. ನಾನು ಏನನ್ನಾದರೂ ಹಿಡಿದಿದ್ದೇನೆ ಎಂದು ಭಾವಿಸಿ, ನಾನು ಎಲ್ಲಾ ನೆಟ್‌ವರ್ಕ್ ಅಲ್ಲದ ಅಥವಾ ಟಿಸಿಪಿ ಅಲ್ಲದ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ತ್ಯಜಿಸಿದೆ, ಪರ್ವತ ಸೆಟ್ಟಿಂಗ್‌ಗಳೊಂದಿಗೆ ಉಳಿದಿದೆ net.core. ನಂತರ ನಾನು VM ನಲ್ಲಿ ಹೋಸ್ಟ್ ಅನುಮತಿಗಳು ಇರುವ ಸ್ಥಳಕ್ಕೆ ಹೋದೆ ಮತ್ತು ನಾನು ಅಪರಾಧಿಯನ್ನು ಕಂಡುಹಿಡಿಯುವವರೆಗೆ ಮುರಿದ VM ನೊಂದಿಗೆ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಒಂದೊಂದಾಗಿ ಅನ್ವಯಿಸಲು ಪ್ರಾರಂಭಿಸಿದೆ:

net.core.rmem_default = 2147483647

ಇಲ್ಲಿದೆ, DNS ಬ್ರೇಕಿಂಗ್ ಕಾನ್ಫಿಗರೇಶನ್! ನಾನು ಕೊಲೆಯ ಆಯುಧವನ್ನು ಕಂಡುಕೊಂಡೆ. ಆದರೆ ಇದು ಏಕೆ ನಡೆಯುತ್ತಿದೆ? ನನಗೆ ಇನ್ನೂ ಒಂದು ಪ್ರೇರಣೆ ಬೇಕಿತ್ತು.

ಮೂಲ DNS ಪ್ಯಾಕೆಟ್ ಬಫರ್ ಗಾತ್ರವನ್ನು ಇದರ ಮೂಲಕ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ net.core.rmem_default. ಒಂದು ವಿಶಿಷ್ಟವಾದ ಮೌಲ್ಯವು ಎಲ್ಲೋ 200KiB ಆಗಿದೆ, ಆದರೆ ನಿಮ್ಮ ಸರ್ವರ್ ಬಹಳಷ್ಟು DNS ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸಿದರೆ, ನೀವು ಬಫರ್ ಗಾತ್ರವನ್ನು ಹೆಚ್ಚಿಸಲು ಬಯಸಬಹುದು. ಹೊಸ ಪ್ಯಾಕೆಟ್ ಬಂದಾಗ ಬಫರ್ ತುಂಬಿದ್ದರೆ, ಉದಾಹರಣೆಗೆ ಅಪ್ಲಿಕೇಶನ್ ಅದನ್ನು ಸಾಕಷ್ಟು ವೇಗವಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸದ ಕಾರಣ, ನೀವು ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸುತ್ತೀರಿ. ನಮ್ಮ ಕ್ಲೈಂಟ್ ಬಫರ್ ಗಾತ್ರವನ್ನು ಸರಿಯಾಗಿ ಹೆಚ್ಚಿಸಿದೆ ಏಕೆಂದರೆ ಅವರು ಡೇಟಾ ನಷ್ಟದ ಬಗ್ಗೆ ಹೆದರುತ್ತಿದ್ದರು, ಏಕೆಂದರೆ ಅವರು DNS ಪ್ಯಾಕೆಟ್‌ಗಳ ಮೂಲಕ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಬಳಸುತ್ತಿದ್ದರು. ಅವರು ಸೆಟ್ ಮಾಡಿದ ಮೌಲ್ಯವು ಗರಿಷ್ಠ ಸಾಧ್ಯ: 231-1 (231 ಗೆ ಹೊಂದಿಸಿದರೆ, ಕರ್ನಲ್ "ಅಮಾನ್ಯ ವಾದ" ಅನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ).

nmap ಮತ್ತು ಸ್ಕೇಪಿ ಏಕೆ ಸರಿಯಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತವೆ ಎಂದು ನಾನು ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಅರಿತುಕೊಂಡೆ: ಅವರು ಕಚ್ಚಾ ಸಾಕೆಟ್‌ಗಳನ್ನು ಬಳಸುತ್ತಿದ್ದಾರೆ! ಕಚ್ಚಾ ಸಾಕೆಟ್‌ಗಳು ಸಾಮಾನ್ಯ ಸಾಕೆಟ್‌ಗಳಿಗಿಂತ ಭಿನ್ನವಾಗಿರುತ್ತವೆ: ಅವು ಐಪ್ಟೇಬಲ್‌ಗಳನ್ನು ಬೈಪಾಸ್ ಮಾಡುತ್ತವೆ ಮತ್ತು ಅವು ಬಫರ್ ಆಗಿರುವುದಿಲ್ಲ!

ಆದರೆ "ಬಫರ್ ತುಂಬಾ ದೊಡ್ಡದು" ಏಕೆ ಸಮಸ್ಯೆಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ? ಇದು ಸ್ಪಷ್ಟವಾಗಿ ಉದ್ದೇಶಿಸಿದಂತೆ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ.

ಈ ಹಂತದಲ್ಲಿ ನಾನು ಬಹು ಕರ್ನಲ್‌ಗಳು ಮತ್ತು ಬಹು ವಿತರಣೆಗಳಲ್ಲಿ ಸಮಸ್ಯೆಯನ್ನು ಪುನರುತ್ಪಾದಿಸಬಹುದು. ಸಮಸ್ಯೆಯು ಈಗಾಗಲೇ 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 ಇಂಟ್ ಪ್ರಕಾರವಾಗಿದೆ
• size u16 ಪ್ರಕಾರವಾಗಿದೆ (ಸಹಿ ಮಾಡದ ಹದಿನಾರು-ಬಿಟ್ ಇಂಟ್) ಮತ್ತು ಪ್ಯಾಕೆಟ್ ಗಾತ್ರವನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ
• sk->sk_rcybuf ಇಂಟ್ ಪ್ರಕಾರವಾಗಿದೆ ಮತ್ತು ಬಫರ್ ಗಾತ್ರವನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ, ಇದು ವ್ಯಾಖ್ಯಾನದಿಂದ, ಮೌಲ್ಯಕ್ಕೆ ಸಮಾನವಾಗಿರುತ್ತದೆ net.core.rmem_default

ಯಾವಾಗ sk_rcvbuf 231 ಅನ್ನು ತಲುಪುತ್ತದೆ, ಪ್ಯಾಕೆಟ್ ಗಾತ್ರವನ್ನು ಒಟ್ಟುಗೂಡಿಸುವುದು ಕಾರಣವಾಗಬಹುದು ಪೂರ್ಣಾಂಕ ಉಕ್ಕಿ. ಮತ್ತು ಇದು ಒಂದು ಇಂಟ್ ಆಗಿರುವುದರಿಂದ, ಅದರ ಮೌಲ್ಯವು ಋಣಾತ್ಮಕವಾಗಿರುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದು ತಪ್ಪಾಗಿರುವಾಗ ಸ್ಥಿತಿಯು ನಿಜವಾಗುತ್ತದೆ (ನೀವು ಇದರ ಬಗ್ಗೆ ಇನ್ನಷ್ಟು ಓದಬಹುದು ಲಿಂಕ್).

ದೋಷವನ್ನು ಕ್ಷುಲ್ಲಕ ರೀತಿಯಲ್ಲಿ ಸರಿಪಡಿಸಬಹುದು: ಎರಕದ ಮೂಲಕ unsigned int. ನಾನು ಫಿಕ್ಸ್ ಅನ್ನು ಅನ್ವಯಿಸಿದೆ ಮತ್ತು ಸಿಸ್ಟಮ್ ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿದೆ ಮತ್ತು DNS ಮತ್ತೆ ಕೆಲಸ ಮಾಡಿದೆ.

ಗೆಲುವಿನ ರುಚಿ

ನಾನು ನನ್ನ ಸಂಶೋಧನೆಗಳನ್ನು ಕ್ಲೈಂಟ್‌ಗೆ ರವಾನಿಸಿದೆ ಮತ್ತು ಕಳುಹಿಸಿದೆ ಎಲ್ಕೆಎಂಎಲ್ ಕರ್ನಲ್ ಪ್ಯಾಚ್. ನನಗೆ ಸಂತೋಷವಾಗಿದೆ: ಪ್ರತಿಯೊಂದು ಒಗಟುಗಳು ಒಟ್ಟಿಗೆ ಹೊಂದಿಕೊಳ್ಳುತ್ತವೆ, ನಾವು ಗಮನಿಸಿದ್ದನ್ನು ನಾವು ಏಕೆ ಗಮನಿಸಿದ್ದೇವೆ ಎಂಬುದನ್ನು ನಾನು ನಿಖರವಾಗಿ ವಿವರಿಸಬಲ್ಲೆ, ಮತ್ತು ಮುಖ್ಯವಾಗಿ, ನಮ್ಮ ತಂಡದ ಕೆಲಸದಿಂದಾಗಿ ಸಮಸ್ಯೆಗೆ ಪರಿಹಾರವನ್ನು ಕಂಡುಹಿಡಿಯಲು ನಮಗೆ ಸಾಧ್ಯವಾಯಿತು!

ಪ್ರಕರಣವು ಅಪರೂಪವಾಗಿದೆ ಎಂದು ಗುರುತಿಸುವುದು ಯೋಗ್ಯವಾಗಿದೆ ಮತ್ತು ಅದೃಷ್ಟವಶಾತ್ ನಾವು ಬಳಕೆದಾರರಿಂದ ಅಂತಹ ಸಂಕೀರ್ಣ ವಿನಂತಿಗಳನ್ನು ವಿರಳವಾಗಿ ಸ್ವೀಕರಿಸುತ್ತೇವೆ.

ಮೂಲ: www.habr.com