tcpdump IPsec ಸ್ಪಷ್ಟ ಪಠ್ಯವನ್ನು ಒಂದೇ ದಿಕ್ಕಿನಲ್ಲಿ ಮಾತ್ರ ಏಕೆ ತೋರಿಸುತ್ತದೆ

ನೀವು Linux IPsec ಗೇಟ್‌ವೇಯ ಹೊರ ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ tcpdump ಚಲಾಯಿಸುತ್ತೀರಿ ಮತ್ತು ಒಂದೇ ಸಮಯದಲ್ಲಿ ಎರಡು ವಿಷಯಗಳನ್ನು ನೋಡುತ್ತೀರಿ: ಒಳಬರುವ ESP ಫ್ರೇಮ್‌ಗಳು ಮತ್ತು ಅವುಗಳ ನಂತರ ತಕ್ಷಣ ಡೀಕ್ರಿಪ್ಟ್ ಆದ ಒಳ ಪ್ಯಾಕೆಟ್‌ಗಳು. ಹೊರಹೋಗುವ ದಿಕ್ಕಿನಲ್ಲಿ ESP ಮಾತ್ರ ಕಾಣಿಸುತ್ತದೆ. ಸಹಜ ತೀರ್ಮಾನವೆಂದರೆ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಕಳುಹಿಸುತ್ತಿಲ್ಲ ಅಥವಾ IPsec ಒಂದು ದಿಕ್ಕನ್ನು ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಿ ಇನ್ನೊಂದನ್ನು ಮರೆತಿದೆ. ಎರಡೂ ಸರಿಯಲ್ಲ.

ನೀವು ನೋಡುತ್ತಿರುವುದು ಕ್ಯಾಪ್ಚರ್ ಬಿಂದು. ಸಾಧನದ ಪ್ರಸಾರ ಮಾರ್ಗವು ಪ್ಯಾಕೆಟ್ ಸಾಕೆಟ್‌ಗೆ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ನೀಡುವ ಮೊದಲೇ ಕರ್ನಲ್ ಹೊರಹೋಗುವ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ರೂಪಾಂತರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಸಾಕೆಟ್ ಹೊರಹೋಗುವ ಒಳ ರೂಪವನ್ನು ಎಂದಿಗೂ ನೋಡುವುದಿಲ್ಲ. ಒಳಬರುವಾಗ ಪ್ಯಾಕೆಟ್ ಮೊದಲು ESP ಆಗಿ ಸೆರೆಹಿಡಿಯಲ್ಪಡುತ್ತದೆ ಮತ್ತು ಡೀಕ್ಯಾಪ್ಸುಲೇಟ್ ಆದ ಪ್ರತಿಯು ಅದು ಮತ್ತೆ ಸ್ಟಾಕ್‌ಗೆ ಪ್ರವೇಶಿಸಿದಾಗ ಕಾಣಿಸುತ್ತದೆ. ಅದೇ ಸಂಚಾರ, ಎರಡು ಬೇರೆ ಬೇರೆ ವೀಕ್ಷಣಾ ಕಿಟಕಿಗಳು.

ಕ್ಯಾಪ್ಚರ್ ಬಿಂದುವೇ ನೀವು ಏನನ್ನು ನೋಡುತ್ತೀರಿ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ

ಸಾಮಾನ್ಯ ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ AF_PACKET ಸಾಕೆಟ್ ಸಾಧನ ಪದರದ ಹತ್ತಿರ ಕುಳಿತುಕೊಳ್ಳುತ್ತದೆ. ಹೋಸ್ಟ್ ಬಿಡುವ ಪ್ಯಾಕೆಟ್‌ಗಳು ಮೊದಲು IPsec ಔಟ್‌ಪುಟ್ ಸಂಸ್ಕರಣೆಯ ಮೂಲಕ ಹೋಗುತ್ತವೆ, ಅದು ಒಳ TCP ವಿಭಾಗವನ್ನು ESP ಅಥವಾ UDP-4500 ಡೇಟಾಗ್ರಾಮ್ ಆಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ, ಮತ್ತು ನಂತರವೇ ಆ ಪದರವನ್ನು ತಲುಪುತ್ತವೆ. ಬರುವ ಪ್ಯಾಕೆಟ್‌ಗಳು ತಂತಿಯಿಂದ ಬರುತ್ತಿದ್ದಂತೆ, ಇನ್ನೂ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಆಗಿರುವ ಸ್ಥಿತಿಯಲ್ಲಿ ಸಾಕೆಟ್‌ಗೆ ನಕಲಿಸಲ್ಪಡುತ್ತವೆ, ಮತ್ತು ಡೀಕ್ರಿಪ್ಟ್ ಆದ ಫಲಿತಾಂಶವು ಸ್ಟಾಕ್ ಅದನ್ನು ಸ್ಥಳೀಯವಾಗಿ ತಲುಪಿಸಿದಾಗ ಅಥವಾ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸಿದಾಗ ನಂತರ ಕಾಣಿಸುತ್ತದೆ.

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

ನೀವು ಉದ್ದೇಶಿಸಿದ ಪದರಕ್ಕೆ ಫಿಲ್ಟರ್ ಹೊಂದಿಸಿ

tcp port 443 ನಂತಹ ಅಭಿವ್ಯಕ್ತಿ ಒಳ TCP ಸಂಪರ್ಕವನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ. ಹೊರಹೋಗುವ ದಿಕ್ಕಿನಲ್ಲಿ ಸಾಕೆಟ್ ಕೇಳಿದಾಗ ಆ ಸಂಪರ್ಕ ಈಗಾಗಲೇ ESP ಆಗಿದೆ, ಆದ್ದರಿಂದ ಫಿಲ್ಟರ್ ಯಾವುದಕ್ಕೂ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ. ನೀವು ಸಂರಕ್ಷಿತ ಸಂಚಾರವನ್ನು ಎಣಿಸಲು ಬಯಸಿದರೆ, ಬದಲಿಗೆ ಹೊರ ರೂಪದ ಮೇಲೆ ಫಿಲ್ಟರ್ ಮಾಡಿ: ಕಚ್ಚಾ ESP ಗೆ ಪ್ರೋಟೋಕಾಲ್ 50, ಅಥವಾ NAT ಟ್ರಾವರ್ಸಲ್ ಇದ್ದಾಗ UDP ಪೋರ್ಟ್ 4500. ಎರಡೂ ಫಿಲ್ಟರ್‌ಗಳು ಎರಡು ಪೀರ್‌ಗಳ ನಡುವೆ ಹೋಲಿಸಬಹುದಾದ ಪ್ಯಾಕೆಟ್ ಸಂಖ್ಯೆಯನ್ನು ನೀಡುತ್ತವೆ, ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಎಣಿಸುವ ಕಾರಣವೂ ಅದೇ. ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ ಒಳ ವಿನಂತಿಗೆ ಉತ್ತರ ಸಿಕ್ಕಿತೇ ಎಂದು ಹೇಳುವುದಿಲ್ಲ.

UDP 4500 ಎಣಿಕೆಯನ್ನು ESP ಪ್ಯಾಕೆಟ್ ಎಣಿಕೆಯಾಗಿ ಪರಿಗಣಿಸಬೇಡಿ. IKE ಆ ಪೋರ್ಟ್ ಅನ್ನು NAT-T ಕೀಪ್‌ಅಲೈವ್ ಮತ್ತು ಎನ್‌ಕ್ಯಾಪ್ಸುಲೇಟೆಡ್ ವಿನಿಮಯಕ್ಕೂ ಬಳಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಸಂಖ್ಯೆಯು ನೀವು ಅಳೆಯಲು ಬಯಸಿದ ಡೇಟಾ ಅಲ್ಲದ ಸಂಚಾರವನ್ನೂ ಒಳಗೊಂಡಿದೆ. UDP 500 ನಲ್ಲಿನ ಆರಂಭಿಕ IKE ವಿನಿಮಯಕ್ಕೆ ಅದೇ ಪ್ರಶ್ನೆಯಾಗಿದ್ದರೆ ಅದರದೇ ಫಿಲ್ಟರ್ ಬೇಕು. ನಿಯಂತ್ರಣ ಸಂಚಾರವನ್ನು ಡೇಟಾದೊಂದಿಗೆ ಬೆರೆಸುವ ಸಂಖ್ಯೆಯು ಯಾವುದೇ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಅಂದಾಜನ್ನೂ ಅಜ್ಞಾತ ಅಂಚಿನಲ್ಲಿ ತಪ್ಪಾಗಿಸುತ್ತದೆ. ಬೇರೆ ಬೇರೆ ಎಣಿಕೆಗಳು ಬೇರೆ ಬೇರೆ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತವೆ.

ಫಿಲ್ಟರ್ ಉತ್ತರಿಸುವ ಪ್ರಶ್ನೆಯ ಪಕ್ಕದಲ್ಲಿ ಅದನ್ನು ಬರೆಯಿರಿ. «ಪೆಟ್ಟಿಗೆಯಿಂದ ಎಷ್ಟು ESP ಹೊರಟಿತು» ಮತ್ತು «ವೆಬ್ ವಿನಂತಿ ಪೆಟ್ಟಿಗೆಯಿಂದ ಹೊರಟಿತೇ» ಬೇರೆ ಫಿಲ್ಟರ್‌ಗಳಿರುವ ಬೇರೆ ಅಳತೆಗಳು, ಮತ್ತು ಒಂದು ಕ್ಯಾಪ್ಚರ್ ಎರಡನ್ನೂ ನಿರ್ಣಯಿಸಲಾರದು. ಆ ಟಿಪ್ಪಣಿ ಇಲ್ಲದೆ ಇಬ್ಬರು ಜನ ಯಾವತ್ತೂ ಒಂದೇ ವಿಷಯವನ್ನು ಎಣಿಸದ ಸಂಖ್ಯೆಗಳನ್ನು ಹೋಲಿಸುತ್ತಾರೆ.

ರೂಪಾಂತರದ ಮೊದಲು ಗಮನಿಸಿ, ನಂತರವಲ್ಲ

ನೀವು ಹೊರಹೋಗುವ ಸ್ಪಷ್ಟ ಪಠ್ಯವನ್ನು ನೋಡಬೇಕಾದರೆ, ವೀಕ್ಷಣಾ ಬಿಂದುವನ್ನು ಹಿಂದಕ್ಕೆ, IPsec ಔಟ್‌ಪುಟ್ ಸಂಸ್ಕರಣೆಗೆ ಮೊದಲು ಸರಿಸಿ. NFLOG ನಿಮಗೆ Netfilter ಕೊಕ್ಕನ್ನು ನೀಡುತ್ತದೆ, ಅಲ್ಲಿ ನಿಯಮವು ಆಯ್ದ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಬಳಕೆದಾರ ಜಾಗದ ಸಾಕೆಟ್‌ಗೆ ನಕಲಿಸಬಹುದು, ಅದನ್ನು tcpdump ಓದಬಲ್ಲದು. strongSwan ನ ಸಂಚಾರ ಡಂಪ್ ಮಾರ್ಗದರ್ಶಿ ಈ ವಿಧಾನವನ್ನು ಅದೇ ಕಾರಣಕ್ಕೆ ದಾಖಲಿಸುತ್ತದೆ.

ನೀತಿ ಹೊಂದಾಣಿಕೆ ನಿಯಮವನ್ನು ಸುರಂಗಕ್ಕೆ ಪ್ರವೇಶಿಸಲಿರುವ ಸಂಚಾರಕ್ಕೆ ಮಾತ್ರ ಸೀಮಿತಗೊಳಿಸುತ್ತದೆ. -m policy --pol ipsec --dir out ಪೆಟ್ಟಿಗೆ ಕಳುಹಿಸುವ ಪ್ರತಿ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಲಾಗ್ ಮಾಡುವ ಬದಲು ನಿಯಮವನ್ನು ನಿರ್ದಿಷ್ಟಗೊಳಿಸುತ್ತದೆ. ನಂತರ ಲಾಗ್ ಗುಂಪನ್ನು ಸೀಮಿತ ಕ್ಯಾಪ್ಚರ್‌ನೊಂದಿಗೆ ಓದಿ: ಸಣ್ಣ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್ ಸಂಖ್ಯೆ ಮತ್ತು ಗಾತ್ರ ಮಿತಿಯು ರೋಗನಿರ್ಣಯವು ಸಂಚಾರ ದಾಖಲಾಗಿ ಮಾರ್ಪಡದಂತೆ ತಡೆಯುತ್ತದೆ. ಸೀಮಿತ ಕ್ಯಾಪ್ಚರ್ ಅನ್ನು ಪರಿಶೀಲಕರಿಗೆ ನೀಡುವುದೂ ಸುಲಭ, ಅಸಂಬದ್ಧ ಪೇಲೋಡ್ ಎಳೆಯದೆ. ಎಷ್ಟು ಬಂದಿತೆಂದು ನೋಡಿದ ನಂತರವಲ್ಲ, ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು ಸಂಖ್ಯೆಯನ್ನು ನಿರ್ಧರಿಸಿ.

iptables -I OUTPUT 1 -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5
tcpdump -ni nflog:5 -s 128 -c 20 'host 10.83.0.44 and tcp port 8443'

ಹರಿವಿಗೆ ಹೊಂದುವ ಕೊಕ್ಕನ್ನು ಆಯ್ಕೆ ಮಾಡಿ. OUTPUT ಗೇಟ್‌ವೇ ಸ್ವತಃ ಉತ್ಪಾದಿಸುವ ಸಂಚಾರವನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ; LAN ಕ್ಲೈಂಟ್‌ನಿಂದ ಸಾಗಣೆ ಬದಲಿಗೆ FORWARD ಸರಪಣಿಯ ಮೂಲಕ ಹೋಗುತ್ತದೆ, ಮತ್ತು OUTPUT ನಲ್ಲಿನ ನಿಯಮವು ಅದನ್ನು ಎಂದಿಗೂ ನೋಡುವುದಿಲ್ಲ. ಮೇಲಿನ ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್ ಅನುಮೋದಿತ ಪರೀಕ್ಷಾ ಗಮ್ಯಸ್ಥಾನಕ್ಕಾಗಿ ಪ್ಲೇಸ್‌ಹೋಲ್ಡರ್‌ಗಳು.

ವೀಕ್ಷಣೆ ಏನನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ

NFLOG ಲಾಗಿಂಗ್ ಗುರಿ, ಸ್ವೀಕಾರದ ನಿರ್ಣಯವಲ್ಲ. ಅಲ್ಲಿ ಕಾಣಿಸುವ ಪ್ಯಾಕೆಟ್ ಅದು ಕೊಕ್ಕನ್ನು ತಲುಪಿ ನಿಯಮಕ್ಕೆ ಹೊಂದಿಕೆಯಾಯಿತು ಎಂದು ತೋರಿಸುತ್ತದೆ. ನಂತರದ ಫಿಲ್ಟರ್ ಅದನ್ನು ಅನುಮತಿಸಿತು, ಸಾಧನವು ಅದನ್ನು ರವಾನಿಸಿತು, ಅಥವಾ ಪೀರ್ ಏನನ್ನಾದರೂ ಸ್ವೀಕರಿಸಿತು ಎಂದು ಅದು ತೋರಿಸುವುದಿಲ್ಲ.

ಖಾಲಿ ಲಾಗ್ ಕೂಡ ಅಷ್ಟೇ ಅಸ್ಪಷ್ಟ. ನಿಯಮದ ಪ್ಯಾಕೆಟ್ ಕೌಂಟರ್ ಪರಿಶೀಲಿಸಿ, ದಿಕ್ಕನ್ನು ದೃಢೀಕರಿಸಿ, ಹರಿವು ನಿಜವಾಗಿಯೂ IPsec ನೀತಿಗೆ ಹೊಂದಿಕೆಯಾಯಿತೇ ಎಂದು ದೃಢೀಕರಿಸಿ, ಮತ್ತು ಗಮ್ಯಸ್ಥಾನವನ್ನು ದೃಢೀಕರಿಸಿ. ಎರಡೂ ಪೀರ್‌ಗಳಲ್ಲಿ ಹೊಂದುವ ಕೌಂಟರ್ ಮಾತ್ರ ವೀಕ್ಷಣೆಯನ್ನು ತೀರ್ಮಾನವಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ. ನಂತರ ಅದೇ ನಿಯಂತ್ರಿತ ಪ್ರಯತ್ನಕ್ಕಾಗಿ ಎರಡೂ ಪೀರ್‌ಗಳಲ್ಲಿನ ಭದ್ರತಾ ಸಂಘದ ಕೌಂಟರ್‌ಗಳನ್ನು ಹೋಲಿಸಿ, ಏಕೆಂದರೆ SA ಕೌಂಟರ್‌ಗಳು ಏನು ಸಂರಕ್ಷಿಸಲ್ಪಟ್ಟು ಕಳುಹಿಸಲ್ಪಟ್ಟಿತು ಎಂಬುದರ ಅಧಿಕೃತ ದಾಖಲೆ.

ಇನ್ನೊಂದು ಬಲೆ: ಈ ಸಂದರ್ಭದಲ್ಲಿ «ಸ್ಪಷ್ಟ ಪಠ್ಯ» ಎಂದರೆ IPsec ಎನ್‌ಕ್ರಿಪ್ಷನ್ ಪದರದ ಹೊರಗೆ. ಒಳ HTTPS ಅಧಿವೇಶನಕ್ಕೆ ಇನ್ನೂ ತನ್ನದೇ TLS ಇರುತ್ತದೆ. ಡೀಕ್ಯಾಪ್ಸುಲೇಟ್ ಆದ ಪ್ಯಾಕೆಟ್ ಸೆರೆಹಿಡಿಯುವುದು ಅಪ್ಲಿಕೇಶನ್‌ನ TLS ಅನ್ನು ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡುವುದಿಲ್ಲ, ಮತ್ತು ಅಲ್ಲಿ ಓದಬಹುದಾದ HTTP ಕಂಡರೆ ಅಪ್ಲಿಕೇಶನ್ ಆರಂಭದಿಂದಲೂ HTTPS ಬಳಸಿರಲಿಲ್ಲ ಎಂದರ್ಥ.

ಸ್ವಚ್ಛಗೊಳಿಸಿ ಮತ್ತು ಎರಡೂ ತುದಿಗಳನ್ನು ಹೋಲಿಸಿ

ವೀಕ್ಷಣೆ ಮುಗಿದ ಕೂಡಲೇ ನೀವು ಸೇರಿಸಿದ ನಿಖರವಾದ ನಿಯಮವನ್ನು ಅದರ ಮಾಲೀಕರ ಪ್ರಕಾರ ತೆಗೆದುಹಾಕಿ. ಲಾಗಿಂಗ್ ನಿಯಮವನ್ನು ಬಿಟ್ಟರೆ ಪ್ರತಿ ಹೊಂದುವ ಪ್ಯಾಕೆಟ್‌ಗೆ CPU ವೆಚ್ಚವಾಗುತ್ತದೆ ಮತ್ತು ಮೌನವಾಗಿ ಡೇಟಾ ಧಾರಣೆಯ ಸಮಸ್ಯೆ ಉಂಟಾಗುತ್ತದೆ. ನಿಮ್ಮದಲ್ಲದ ಸರಪಣಿಯನ್ನು ಫ್ಲಶ್ ಮಾಡುವ ಬದಲು -D ನೊಂದಿಗೆ ನಿಯಮವನ್ನು ಪುನರಾವರ್ತಿಸಿ ಅಳಿಸಿ.

iptables -D OUTPUT -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5

ನಿಯೋಜನೆ ಬಳಕೆದಾರ ಜಾಗದ IPsec, XFRM ಇಂಟರ್ಫೇಸ್ ಅಥವಾ ಹಾರ್ಡ್‌ವೇರ್ ಆಫ್‌ಲೋಡ್ ಬಳಸಿದರೆ, ವೀಕ್ಷಣಾ ಬಿಂದುಗಳು ಸರಿಯುತ್ತವೆ ಮತ್ತು ಈ ಪಾಕವಿಧಾನ ಸಂಪೂರ್ಣವಾಗಿ ಅನ್ವಯಿಸದೇ ಇರಬಹುದು. libipsec ನೊಂದಿಗೆ ಒಳ ಸಂಚಾರವನ್ನು ನೋಡುವ ದಾಖಲಿತ ಸ್ಥಳ TUN ಸಾಧನ. ಮೊದಲು ಮಾರ್ಗವನ್ನು ಗುರುತಿಸಿ, ನಂತರ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುವ ಬಿಂದುವನ್ನು ಆಯ್ಕೆ ಮಾಡಿ, ಮತ್ತು ರೂಪಾಂತರದ ತಪ್ಪು ಬದಿಯನ್ನು ನೋಡಿದಾಗ ಮಾತ್ರ ಎರಡು ದಿಕ್ಕುಗಳು ಬೇರೆಯಾಗಿ ಕಾಣುತ್ತವೆ ಎಂದು ನಿರೀಕ್ಷಿಸಿ.