ACK ಪ್ಯಾಕೆಟ್ನಲ್ಲಿ conntrack NEW: ಅದು ಏನನ್ನು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ

ಫೈರ್‌ವಾಲ್ ಲಾಗ್‌ನಲ್ಲಿ ನೀವು ನಿರೀಕ್ಷಿಸದ ಒಂದು ಸಾಲಿದೆ: ಒಂದು ACK ಪ್ಯಾಕೆಟ್, conntrack ಸ್ಥಿತಿ NEW, ನಿಮ್ಮದಲ್ಲದ ಮೂಲ ವಿಳಾಸ, ಗಮ್ಯಸ್ಥಾನ ಪೋರ್ಟ್ ತೆರೆದಿದೆ. ಯಾರೂ ಅನುಮೋದಿಸದ ಹೊಸ ಒಳಬರುವ ಸಂಪರ್ಕ ಎಂದು ಓದುವ ಪ್ರಲೋಭನೆ ಇದೆ. ಸಾಲು ವಾಸ್ತವವಾಗಿ ಹೇಳುವುದು ಸಂಕುಚಿತವಾಗಿದೆ: ಆ ಪ್ಯಾಕೆಟ್ ಈ hook ತಲುಪಿದಾಗ ಟ್ರ್ಯಾಕರ್ಗೆ ಹೊಂದುವ ಯಾವ ಸ್ಥಿತಿಯೂ ಇರಲಿಲ್ಲ, ಮತ್ತು ಪ್ಯಾಕೆಟ್ ACK ಹೊತ್ತಿತ್ತು. ಇವು ಎರಡು ವಿಭಿನ್ನ ವಿಷಯಗಳ ಬಗ್ಗೆ ಎರಡು ಸತ್ಯಗಳು, ಮತ್ತು ಎರಡೂ ಪೂರ್ಣ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ದಾಖಲೆ ಅಲ್ಲ. ತೀರ್ಮಾನಕ್ಕೆ ಬರುವ ಮೊದಲು ನಾನು ಅನುಸರಿಸುವ ಕ್ರಮ ಇದು.

ತೀರ್ಪಿನಿಂದಲ್ಲ, ಪ್ಯಾಕೆಟ್‌ನಿಂದ ಪ್ರಾರಂಭಿಸಿ

ವ್ಯಾಖ್ಯಾನಿಸುವ ಮೊದಲು ಅವಲೋಕನಗಳನ್ನು ಬೇರ್ಪಡಿಸಿ. TCP ಫ್ಲ್ಯಾಗ್‌ಗಳು ಈ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ವಿವರಿಸುತ್ತವೆ, ಟ್ರ್ಯಾಕರ್ನ ಸ್ಥಿತಿ ಆ hook ನಲ್ಲಿ ಅದಕ್ಕೆ ಏನು ಗೊತ್ತಿತ್ತು ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತದೆ, ಮತ್ತು ನಿಮ್ಮ ಕ್ಯಾಪ್ಚರ್ ನೀವು ದಾಖಲಿಸಿದ ವಿಂಡೋವನ್ನು ಮಾತ್ರ ವಿವರಿಸುತ್ತದೆ.

ಈ ಮೂರನ್ನು ಬೆರೆಸುವುದೇ ACK “ಪ್ರೊವೈಡರ್ ಯಾರನ್ನೋ ಒಳಗೆ ಬಿಟ್ಟರು” ಆಗುವ ದಾರಿ.

hook ನಲ್ಲಿ NEW ನಿಜವಾಗಿ ಏನನ್ನು ಅರ್ಥೈಸುತ್ತದೆ

iptables conntrack ಹೊಂದಾಣಿಕೆ NEW ಅನ್ನು ಸಂಪರ್ಕ ಪ್ರಾರಂಭಿಸುವ ಪ್ಯಾಕೆಟ್ ಎಂದು, ಅಥವಾ ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಸಂಚಾರವನ್ನು ಇನ್ನೂ ಕಾಣದ ಸಂಪರ್ಕಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ಪ್ಯಾಕೆಟ್ ಎಂದು ದಾಖಲಿಸುತ್ತದೆ. ESTABLISHED ಎಂದರೆ ಟ್ರ್ಯಾಕರ್ ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ನೋಡಿದೆ ಎಂದು. ಎರಡೂ ವ್ಯಾಖ್ಯಾನಗಳು ಪ್ಯಾಕೆಟ್ SYN ಆಗಿತ್ತು ಎಂದಾಗಲೀ, ಅದು ಇತಿಹಾಸವಿಲ್ಲದೆ ಬಂತು ಎಂದಾಗಲೀ ಹೇಳುವುದಿಲ್ಲ.

ಹರಿವನ್ನು ಮಧ್ಯದಿಂದ ಗಮನಿಸಲು ಪ್ರಾರಂಭಿಸುವ ಟ್ರ್ಯಾಕರ್ ಮುಂದಿನ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ತನಗೆ ತಿಳಿದಿರುವ ಆಧಾರದಲ್ಲಿ ವರ್ಗೀಕರಿಸುತ್ತದೆ, ಮತ್ತು ಅದು ಏನೂ ಇಲ್ಲದಿರಬಹುದು. ಇದು ಟ್ರ್ಯಾಕರ್ನ ಸ್ಮರಣೆಯ ಬಗ್ಗೆ ಹೇಳಿಕೆ, ದೂರದ ಹೋಸ್ಟ್‌ನ ಉದ್ದೇಶದ ಬಗ್ಗೆ ಅಲ್ಲ.

ಸಡಿಲ ಟ್ರ್ಯಾಕಿಂಗ್ ಬಹುಪಾಲು ACK ಅಚ್ಚರಿಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ

ಕರ್ನಲ್ ದಾಖಲಿಸುತ್ತದೆ nf_conntrack_tcp_loose, ಇದು ಟ್ರ್ಯಾಕರ್ಗೆ ಪ್ರಾರಂಭವನ್ನು ಕಾಣದ TCP ಸಂಪರ್ಕಗಳನ್ನು ಎತ್ತಿಕೊಳ್ಳಲು ಅವಕಾಶ ನೀಡುತ್ತದೆ. ಸೆಟ್ಟಿಂಗ್ ಅದರ ಡೀಫಾಲ್ಟ್ ಮೌಲ್ಯದಲ್ಲಿದ್ದಾಗ, ಹರಿವಿನ ಮಧ್ಯದಿಂದ ಬಂದ ACK ಸ್ಥಾಪಿತ ಹರಿವಾಗಿ ಸ್ವೀಕರಿಸಬಹುದು. ಅದನ್ನು ಆಫ್ ಮಾಡಿ, ಅದೇ ಪ್ಯಾಕೆಟ್ NEW ಬದಲು INVALID ಎಂದು ವರ್ಗೀಕರಿಸುವ ಸಾಧ್ಯತೆ ಹೆಚ್ಚು. ಎರಡೂ ಫಲಿತಾಂಶಗಳು ಟ್ರ್ಯಾಕರ್ನ ನಿಯಮಗಳನ್ನು ವಿವರಿಸುತ್ತವೆ, ಅಪ್ಲಿಕೇಶನ್‌ನ ಇತಿಹಾಸವನ್ನಲ್ಲ.

ಆದ್ದರಿಂದ ಲೇಬಲ್ ಮೇಲೆ ಸಿದ್ಧಾಂತ ಕಟ್ಟುವ ಮೊದಲು ಆ ಸೆಟ್ಟಿಂಗ್ ಪರಿಶೀಲಿಸಿ.

ನೀರಸ ಕಾರಣಗಳನ್ನು ಈ ಕ್ರಮದಲ್ಲಿ ಹೊರಗಿಡಿ

ನಾನು ಬೆನ್ನಟ್ಟಿದ NEW-on-ACK ಘಟನೆಗಳಲ್ಲಿ ಬಹುಪಾಲು ಇವುಗಳಲ್ಲಿ ಒಂದರಲ್ಲಿ ಕೊನೆಗೊಂಡವು, ಮತ್ತು ಎಲ್ಲವನ್ನೂ ಪರಿಶೀಲಿಸುವುದು ಅಗ್ಗ:

• conntrack ಕೋಷ್ಟಕ ಫ್ಲಶ್ ಆಯಿತು, ಅಥವಾ ಟ್ರ್ಯಾಕರ್ ಮರುಪ್ರಾರಂಭವಾಯಿತು.
• ಹೋಸ್ಟ್ ಮರುಬೂಟ್ ಆಯಿತು, ಅಥವಾ ಹರಿವು ಬೇರೆ namespace ಅಥವಾ ಸಾಧನಕ್ಕೆ ಸರಿಯಿತು.
• ಅಸಮಮಿತ ರೂಟಿಂಗ್ SYN ಅನ್ನು ನೀವು ಸೆರೆಹಿಡಿಯದ ಮಾರ್ಗದಲ್ಲಿ ಕಳುಹಿಸಿತು.
• NAT tuple ಅನ್ನು ಮರುಬರೆದಿದೆ, ಆದ್ದರಿಂದ ನಮೂದು ಇನ್ನು ನೀವು ಓದಿದ್ದಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ.
• ಕ್ಯಾಪ್ಚರ್ ತಡವಾಗಿ ಪ್ರಾರಂಭವಾಯಿತು ಮತ್ತು ಆರಂಭವನ್ನು ಎಂದೂ ಕಾಣಲಿಲ್ಲ.

ಇವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದೂ ಹಿಂದಿನ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಟ್ರ್ಯಾಕರ್ನ ದೃಷ್ಟಿಯಿಂದ ತೆಗೆದು, ನಂತರದವನ್ನು ಅಚ್ಚುಕಟ್ಟಾಗಿ ಬಿಡುತ್ತದೆ. ಮರುಬೂಟ್ ಅಥವಾ ಕೋಷ್ಟಕ ಫ್ಲಶ್ uptime ಮತ್ತು ಲಾಗ್‌ಗಳಿಂದ ಪರಿಶೀಲಿಸಲು ಸುಲಭ. ಅಸಮಮಿತ ರೂಟಿಂಗ್ ಏಕಮುಖ ಕ್ಯಾಪ್ಚರ್ ಆಗಿ ಕಾಣಿಸುತ್ತದೆ. NAT ಮೋಸಗಾರ, ಏಕೆಂದರೆ ಟ್ರ್ಯಾಕರ್ ಉಳಿಸಿದ tuple ಲಾಗ್‌ನಲ್ಲಿ ಮುದ್ರಿತ tuple ಅಲ್ಲ.

ಮುಂದುವರಿಯುವ ಮೊದಲು ಇವುಗಳಲ್ಲಿ ಯಾವುದನ್ನು ಹೊರಗಿಟ್ಟಿರಿ ಮತ್ತು ಹೇಗೆ ಎಂದು ಬರೆಯಿರಿ.

tuple, ಇಂಟರ್‌ಫೇಸ್ ಮತ್ತು hook ಓದಿ

conntrack ನಮೂದು ವಿಳಾಸಗಳು, ಪೋರ್ಟ್‌ಗಳು ಮತ್ತು ಪ್ರೋಟೋಕಾಲ್‌ನಿಂದ ಕೀಲಿಯಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಯಾವುದೇ ಅನುವಾದ ಯಾವ ನಮೂದು ಹೊಂದುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಿಸುತ್ತದೆ. ಇಂಟರ್‌ಫೇಸ್ ಮತ್ತು hook ಅನ್ನೂ ದಾಖಲಿಸಿ, ಏಕೆಂದರೆ ತಪ್ಪು ಇಂಟರ್‌ಫೇಸ್‌ನಲ್ಲಿ ಅಥವಾ ಬೇರೆ ಸರಪಳಿಯ ನಂತರ ಕಂಡ ಪ್ಯಾಕೆಟ್ ಮಾರ್ಗ ರೇಖಾಚಿತ್ರದಲ್ಲಿರುವಂತೆ ಅಲ್ಲ ಎಂದು ಹೇಳುತ್ತದೆ. ಘಟನೆ VPNಗೆ ಸಂಬಂಧಿಸಿದಾಗ, ನೀವು ಒಳಗಿನ ಪ್ಯಾಕೆಟ್ ನೋಡುತ್ತಿದ್ದೀರಾ ಅಥವಾ ಹೊರಗಿನ ವಾಹಕ ಎಂದು ನಿರ್ಧರಿಸಿ. ನಂತರ ಅದೇ ಐದು-ಭಾಗ tupleಗೆ ಗೇಟ್‌ವೇ ದಾಖಲಿಸಿದ್ದನ್ನು ಹೋಲಿಸಿ.

ಒಂದೇ ಹರಿವಿನ ಎರಡು ವಿರುದ್ಧ ದೃಶ್ಯಗಳು ಯಾವುದೇ ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಮಾಹಿತಿ ನೀಡುತ್ತವೆ.

ಯಾವಾಗ ಎಸ್ಕಲೇಟ್ ಮಾಡುವುದು ಯೋಗ್ಯ

ತಲುಪಬಹುದಾದ ಮತ್ತು ಇರಬಾರದ ಸೇವೆಯನ್ನು ಹರಿವು, ಅದನ್ನು ಅನುಮತಿಸಿದ ನೀತಿ ಮತ್ತು ಎರಡೂ ತುದಿಗಳ ಸಾಕ್ಷ್ಯಗಳೊಂದಿಗೆ ತೋರಿಸಬಹುದಾದಾಗ ಎಸ್ಕಲೇಟ್ ಮಾಡಿ. ಒಂದೇ ಸ್ಥಿತಿ ಲೇಬಲ್ ಅಥವಾ ಒಂದು ಭಾಗಶಃ ಕ್ಯಾಪ್ಚರ್ ಆಧರಿಸಿ ಪ್ರೊವೈಡರ್ ದೋಷ ವರದಿ ಮಾಡಬೇಡಿ, ಏಕೆಂದರೆ ಆ ವರದಿ ನೀವು ಈಗಷ್ಟೇ ಓದಿದ ವಿವರಣೆಯಿಂದ ಮುಚ್ಚಲ್ಪಡುತ್ತದೆ. ಸೇವೆ ನಿಜವಾಗಿ ತೆರೆದಿದ್ದರೆ, ಆ ಗಡಿಯ ಮಾಲೀಕರೇ ಅದನ್ನು ಸರಿಪಡಿಸುವ ಸರಿಯಾದ ವ್ಯಕ್ತಿ, ಮತ್ತು ಬಗ್‌ಗಿಂತ ನಿಯೋಜಿತ ಪೋರ್ಟ್ ಮ್ಯಾಪಿಂಗ್ ಅಥವಾ ಅನುದ್ದೇಶಿತ ಶ್ರೋತೃ ಹೆಚ್ಚು ಸಂಭಾವ್ಯ ಕಾರಣ.

ನಂತರ ಒಂದು ಪ್ಯಾಕೆಟ್ ಇಡೀ ಸೆಷನ್ ತರಹ ಕಾಣಲು ಬಿಟ್ಟ ಗೋಚರತೆಯ ಕೊರತೆಯನ್ನು ಮುಚ್ಚಿ.