ಉತ್ತರವಿಲ್ಲದ ಹೊರಹೋಗುವ ESP ಎಂದರೆ VPN ಸತ್ತಿದೆ ಎಂದಲ್ಲ
ESP ಪ್ರತಿ ಸಂಘಕ್ಕೆ ಒಂದು ದಿಕ್ಕನ್ನು ರಕ್ಷಿಸುತ್ತದೆ ಮತ್ತು ಯಾವುದನ್ನೂ ಒಪ್ಪಿಕೊಳ್ಳುವುದಿಲ್ಲ. ಸರ್ವರ್ ಅನ್ನು ಪ್ರತಿಕ್ರಿಯೆರಹಿತ ಎಂದು ಕರೆಯುವ ಮೊದಲು ಒಳ ಸಂಭಾಷಣೆ ಮತ್ತು ಒಳಬರುವ SA ಅನ್ನು ಹೊಂದಿಸಿ.
ನೀವು IPsec ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಟ್ರಾಫಿಕ್ ಸೆರೆಹಿಡಿದಿರಿ, ESP ಪ್ಯಾಕೆಟ್‌ಗಳು ಹೊರಹೋಗುವುದನ್ನು ನೋಡಿದಿರಿ, ಏನೂ ಹಿಂತಿರುಗಿ ಬರುವುದನ್ನು ನೋಡಲಿಲ್ಲ ಮತ್ತು ದೂರದ ಬದಿ ಕೆಟ್ಟಿದೆ ಎಂದು ತೀರ್ಮಾನಿಸಿದಿರಿ. ಸೆರೆಹಿಡಿಯುವಿಕೆ ಆ ತೀರ್ಮಾನವನ್ನು ಬೆಂಬಲಿಸುವುದಿಲ್ಲ. ESP ಸಂಭಾಷಣೆಯ ಒಂದು ದಿಕ್ಕನ್ನು ರಕ್ಷಿಸುತ್ತದೆ ಮತ್ತು IP ಪದರದಲ್ಲಿ ಯಾವುದನ್ನೂ ಒಪ್ಪಿಕೊಳ್ಳುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಹಿಂತಿರುಗುವ ESP ಇಲ್ಲದಿರುವುದು ಅನ್ವಯಕ್ಕೆ ಹೇಳಲು ಏನೂ ಇರಲಿಲ್ಲ ಎಂದೂ ಸುಲಭವಾಗಿ ಅರ್ಥವಾಗಬಹುದು, ಸುರಂಗ ಸತ್ತಿದೆ ಎಂದೂ ಅರ್ಥವಾಗಬಹುದು. ಯಾವುದೇ ತುದಿಯನ್ನು ದೂಷಿಸುವ ಮೊದಲು ಒಳ ವಿನಿಮಯ ಮತ್ತು ಸ್ವೀಕರಿಸುವ ಬದಿಯ ಸ್ಥಿತಿಯನ್ನು ಓದಿ.
ಪುರಾಣ: ಪ್ರತಿ ಸಂರಕ್ಷಿತ ಪ್ಯಾಕೆಟ್ ಉತ್ತರಕ್ಕೆ ಅರ್ಹ
ESP ವಿನಂತಿ-ಪ್ರತಿಕ್ರಿಯೆ ಪ್ರೋಟೋಕಾಲ್ ಅಲ್ಲ. ನೀತಿ ಆಯ್ಕೆಮಾಡುವ ಎಲ್ಲವನ್ನೂ ಅದು ಗೂಢಲಿಪೀಕರಿಸಿ ದೃಢೀಕರಿಸುತ್ತದೆ, ಮತ್ತು ಸ್ವೀಕರಿಸುವವನು ತನ್ನದೇ ಪ್ಯಾಕೆಟ್ ರಚಿಸದೆ ಆ ಒಳ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಪರಿಶೀಲಿಸಿ, ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡಿ ಮತ್ತು ತಲುಪಿಸುತ್ತಾನೆ. ಗಮ್ಯಸ್ಥಾನ ನಿರ್ಲಕ್ಷಿಸುವ UDP ಪ್ರಶ್ನೆ, ಅಥವಾ ಒಳಬರುವ ನೀತಿ ತಳ್ಳಿಹಾಕುವ ICMP ಪ್ರತಿಧ್ವನಿ, ಸರಿಯಾದ ಫಲಿತಾಂಶವಾಗಿ ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಮೌನವನ್ನು ಉಂಟುಮಾಡುತ್ತವೆ. ಆ ಮೌನವನ್ನು ಸಾಗಣೆ ವೈಫಲ್ಯ ಎಂದು ಪರಿಗಣಿಸಿದರೆ ಎಂದಿಗೂ ಇರದ ನೆಟ್‌ವರ್ಕ್ ದೋಷವನ್ನು ಹುಡುಕಲು ನೀವು ಹೋಗುತ್ತೀರಿ.
ಏಕಮುಖ ಸೆರೆಹಿಡಿಯುವಿಕೆ ನಿಜವಾಗಿ ಸಾಬೀತುಪಡಿಸುವುದು ಏನೆಂದರೆ ಕಳುಹಿಸುವವನ ಸ್ಟಾಕ್ ಆ ವೀಕ್ಷಣಾ ಬಿಂದುವಿನಲ್ಲಿ ಏನನ್ನೋ ಗೂಢಲಿಪೀಕರಿಸಿದೆ. ಆಗಮನದ ಬಗ್ಗೆ ಏನೂ ಇಲ್ಲ, ಉತ್ತರಿಸುವ ಉದ್ದೇಶದ ಬಗ್ಗೆ ಏನೂ ಇಲ್ಲ. ಉಪಯುಕ್ತ ಪ್ರಶ್ನೆ "ಏಕೆ ಉತ್ತರವಿಲ್ಲ" ಅಲ್ಲ, ಬದಲಿಗೆ "ಒಳ ಸಂಭಾಷಣೆ ಏನನ್ನು ಉತ್ಪಾದಿಸಬೇಕಿತ್ತು" ಎಂಬುದು.
ಎರಡು SA, ಎರಡು SPI, ಒಂದು ಸಂಭಾಷಣೆ
IPsec ಭದ್ರತಾ ಸಂಘಗಳು ಏಕಮುಖೀಯ, ಆದ್ದರಿಂದ ಸಾಮಾನ್ಯ ಸಂರಕ್ಷಿತ ವಿನಿಮಯದಲ್ಲಿ ಪ್ರತ್ಯೇಕ ಗುರುತುಗಳು ಮತ್ತು ಸ್ವತಂತ್ರ ಸ್ಥಿತಿಯೊಂದಿಗೆ ಒಳಬರುವ ಮತ್ತು ಹೊರಹೋಗುವ ಸಂಘಗಳಿರುತ್ತವೆ. ಹೊರಹೋಗುವ ಪ್ಯಾಕೆಟ್‌ನ SPI ಗಾಗಿ ಹಿಂತಿರುಗುವ ಟ್ರಾಫಿಕ್ ಹುಡುಕುವುದು ಆದ್ದರಿಂದ ವರ್ಗ ದೋಷ, ಏಕೆಂದರೆ ಯಾವುದೇ ಉತ್ತರ ಸಹಚರನ ತನ್ನದೇ ಹೊರಹೋಗುವ SA ಅಡಿಯಲ್ಲಿ ತನ್ನದೇ SPI ಯೊಂದಿಗೆ ಹೋಗುತ್ತದೆ. ಬದಲಿಗೆ ಜೋಡಿಯನ್ನು ಟ್ರಾಫಿಕ್ ಆಯ್ಕೆಕಾರರು ಮತ್ತು ಸಹಚರನ ವಿಳಾಸಗಳಿಂದ ಹೊಂದಿಸಿ.
ಕೀ ಪುನರುತ್ಪಾದನೆ ಒಂದು ಸಲಕ್ಕೆ ಕೆಲವು ಸೆಕೆಂಡುಗಳ ಕಾಲ ಚಿತ್ರವನ್ನು ಸಂಕೀರ್ಣಗೊಳಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಹಳೆಯ ಮತ್ತು ಬದಲಿ ಸ್ಥಿತಿ ಅತಿಕ್ರಮಿಸಬಹುದು. ಲಕ್ಷಣವು ಕೀ ಪುನರುತ್ಪಾದನೆಯ ಸುತ್ತಮುತ್ತ ಪ್ರಾರಂಭವಾಗಿದ್ದರೆ, ಸಂಪರ್ಕದ ಹೆಸರು ಮಾತ್ರವಲ್ಲ, ಸಂಘದ ಗುರುತುಗಳು ಮತ್ತು ಸಮಯ ಚಿಹ್ನೆಗಳನ್ನು ಒಟ್ಟಿಗೆ ಸಂಗ್ರಹಿಸಿ.
ಏನಾದರೂ ಉತ್ತರಿಸುವ ಮೊದಲು ಸ್ವೀಕರಿಸುವವನು ಏನು ಮಾಡಬೇಕು
| Stage | What to look at | Wrong conclusion if skipped |
|---|---|---|
| Sender encrypts | outbound SA packet counter | "the tunnel is up" |
| Peer receives | inbound SA counter and replay window | "the peer is down" |
| Inner delivery | target host or service logs | "routing is broken" |
| Application replies | the app's own trace | "the reply was dropped" |
| Protected return | the peer's outbound SA | "ESP only works one way" |
ಪ್ರತಿ ಸಾಲು ಸ್ವತಂತ್ರವಾಗಿ ವಿಫಲವಾಗುತ್ತದೆ ಮತ್ತು ಪ್ರತಿ ವೈಫಲ್ಯಕ್ಕೆ ಬೇರೆ ಮಾಲೀಕನಿರುತ್ತಾನೆ, ಆದ್ದರಿಂದ ಒಂದು ಸೆರೆಹಿಡಿಯುವಿಕೆ ಅವನ್ನು ಪ್ರತ್ಯೇಕಿಸಲಾರದು. ಒಳಬರುವ ಕೌಂಟರ್ ಆಗಮನದ ಏಕೈಕ ನೇರ ಸಾಕ್ಷಿ, ಏಕೆಂದರೆ ದೃಢೀಕರಣ ಅಥವಾ ಮರುಪಂದ್ಯ ಪರಿಶೀಲನೆಯಲ್ಲಿ ವಿಫಲವಾಗುವ ಪ್ಯಾಕೆಟ್ ಯಾವುದೇ ಪ್ರತಿಕ್ರಿಯೆಯಿಲ್ಲದೆ ತಳ್ಳಿಹಾಕಲ್ಪಡುತ್ತದೆ. ಒಳಬರುವ ಕೌಂಟರ್ ಚಲಿಸದಿರುವ ಸಹಚರನು ನಿಮಗೆ ತನ್ನ ನೀತಿಯ ಬಗ್ಗೆ ಏನನ್ನೂ ತಿಳಿಸುತ್ತಿಲ್ಲ.
ತಲುಪಿಸುವಿಕೆ ಡೀಕ್ರಿಪ್ಷನ್‌ನಿಂದ ಪ್ರತ್ಯೇಕ ಹಂತ. ಸ್ಥಿತಿ ಮಾನ್ಯವಾಗಿರಬಹುದು ಮತ್ತು ಪ್ಯಾಕೆಟ್ ನಂತರ ಒಳಬರುವ ನೀತಿ ಅಥವಾ ಒಳ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಒಳಗೊಳ್ಳದ ಮಾರ್ಗದಿಂದ ತಳ್ಳಿಹಾಕಲ್ಪಡಬಹುದು, ಆದ್ದರಿಂದ ಸ್ವಚ್ಛ ಕೌಂಟರ್ ಎಂದರೆ ಪ್ಯಾಕೆಟ್ ನೀವು ಬಯಸಿದಲ್ಲಿಗೆ ಹೋಯಿತು ಎಂದು ಭಾವಿಸುವ ಬದಲು ಗುರಿ ಹೋಸ್ಟ್ ಸ್ಪಷ್ಟ ಪಠ್ಯವನ್ನು ನೋಡಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ.
ಸ್ಥಳೀಯ ESP UDP ಅಲ್ಲ
ಸ್ಥಳೀಯ ESP ಎಂದರೆ IP ಪ್ರೋಟೋಕಾಲ್ 50, ಅದು TCP ಅಲ್ಲ UDP ಅಲ್ಲ ಮತ್ತು ಅದಕ್ಕೆ ಯಾವುದೇ ಪೋರ್ಟ್‌ಗಳಿಲ್ಲ. ಆದ್ದರಿಂದ UDP 500 ನಲ್ಲಿ IKE ಗೆ ಅನುಮತಿ ನೀಡುವ ಫೈರ್‌ವಾಲ್ ನಿಯಮ ಡೇಟಾ ಮಾರ್ಗದ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ, ಮತ್ತು ಪೋರ್ಟ್‌ಗಳ ಸುತ್ತ ಬರೆದ ಫಿಲ್ಟರ್ ಸುರಂಗವನ್ನು ಮಾತುಕತೆ ನಡೆಸಲು ಬಿಟ್ಟು ನಂತರ ಅದರೊಳಗೆ ಸಾಗಿಸುವ ಎಲ್ಲವನ್ನೂ ತಳ್ಳಿಹಾಕಬಹುದು. ಡೇಟಾ ಮಾರ್ಗವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ, ನೀವು ನಿಜವಾಗಿ ಗಮನಿಸಿದ ಮೋಡ್‌ನಲ್ಲಿ ಪರೀಕ್ಷಿಸಿ.
NAT ಹಿಂದೆ ಆಕಾರ ಬದಲಾಗುತ್ತದೆ: ಸಂರಕ್ಷಿತ ಪೇಲೋಡ್ UDP ಒಳಗೆ ಚಲಿಸುತ್ತದೆ, ಸಾಮಾನ್ಯವಾಗಿ 4500 ಪೋರ್ಟ್‌ನಲ್ಲಿ, RFC 3948 ವ್ಯಾಖ್ಯಾನಿಸಿದಂತೆ. ಯಾವುದೇ ನಿಯಮ ಬರೆಯುವ ಮೊದಲು ಸಕ್ರಿಯ ಮೋಡ್ ಅನ್ನು ದಾಖಲಿಸಿ, ಏಕೆಂದರೆ ಮಾರ್ಗದಲ್ಲಿರುವ ಸಾಧನ ಸ್ಥಳೀಯ ESP ಮತ್ತು UDP-ಎನ್‌ಕ್ಯಾಪ್ಸುಲೇಟೆಡ್ ESP ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬೇರೆ ರೀತಿಯಲ್ಲಿ ನಡೆಸಿಕೊಳ್ಳಬಹುದು, ಮತ್ತು ಕೆಲವು ಮಧ್ಯವರ್ತಿ ಪೆಟ್ಟಿಗೆಗಳು ಒಂದನ್ನು ಅನುಮತಿಸಿ ಇನ್ನೊಂದನ್ನು ತಳ್ಳಿಹಾಕುತ್ತವೆ.
ಈ ಘಟನೆಗೆ ಸೇರಿದ ಕೌಂಟರ್‌ಗಳನ್ನು ಓದಿ
strongSwan ಹೋಸ್ಟ್‌ನಲ್ಲಿ, swanctl --list-sas ಪ್ರತಿ ಸಂಘಕ್ಕೆ ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಪ್ಯಾಕೆಟ್ ಮತ್ತು ಬೈಟ್ ಕೌಂಟರ್‌ಗಳನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ, ಇದು "ಎಂದೂ ಬರಲಿಲ್ಲ" ಮತ್ತು "ಬಂತು ಆದರೆ ಉತ್ತರಿಸಲಿಲ್ಲ" ಅನ್ನು ಪ್ರತ್ಯೇಕಿಸಲು ಸಾಕು. Linux ನಲ್ಲಿ, /proc/net/xfrm_stat ಕಾಣೆಯಾದ ಸ್ಥಿತಿ, ಕಾಣೆಯಾದ ನೀತಿ ಮತ್ತು ಪ್ರೋಟೋಕಾಲ್ ದೋಷಗಳಂತಹ ಒಟ್ಟು ವೈಫಲ್ಯಗಳನ್ನು ಎಣಿಸುತ್ತದೆ. ಆ ಮೊತ್ತಗಳು ಬೂಟ್‌ನಿಂದ ಸಂಗ್ರಹವಾಗುತ್ತವೆ ಮತ್ತು ಒಂದೇ ನೆಟ್‌ವರ್ಕ್ ನಾಮಸ್ಥಳಕ್ಕೆ ಸೇರಿವೆ, ಆದ್ದರಿಂದ ದೊಡ್ಡ ಸಂಖ್ಯೆ ಆರೋಪಣೆಯಲ್ಲ.
ಸರಿಯಾದ ನಾಮಸ್ಥಳದಲ್ಲಿ ಘಟನೆಯ ಕಿಟಕಿಯ ಸುತ್ತ ಎರಡು ಓದಿಕೆಗಳನ್ನು ತೆಗೆದುಕೊಂಡು ವ್ಯತ್ಯಾಸಗಳನ್ನು ಹೋಲಿಸಿ, ಇಲ್ಲದಿದ್ದರೆ ಕಳೆದ ವಾರದ ದೋಷಗಳನ್ನು ಇಂದಿನ ಮಧ್ಯಾಹ್ನದ ಟಿಕೆಟ್‌ಗೆ ಅಂಟಿಸುತ್ತೀರಿ. ನಾಮಸ್ಥಳ ಮತ್ತು ಎರಡೂ ಸಮಯ ಚಿಹ್ನೆಗಳನ್ನು ಟಿಕೆಟ್‌ನಲ್ಲಿ ಬರೆಯಿರಿ, ಇದರಿಂದ ಮುಂದಿನ ಓದುಗ ಮೊತ್ತವನ್ನು ನಂಬುವ ಬದಲು ಹೋಲಿಕೆಯನ್ನು ಮರುಸೃಷ್ಟಿಸಬಹುದು.
ಹಂತವನ್ನು ಹೆಸರಿಸಿ, ಶಂಕಿತನನ್ನಲ್ಲ
ಉಪಯುಕ್ತ ತೀರ್ಮಾನ ಪ್ಯಾಕೆಟ್ ಎಲ್ಲಿ ನಿಂತಿತು ಎಂದು ಹೇಳುತ್ತದೆ: ಎಂದೂ ಸ್ವೀಕರಿಸಲಿಲ್ಲ, ಸ್ವೀಕರಿಸಿ ತಳ್ಳಿಹಾಕಲಾಯಿತು, ತಲುಪಿಸಲಾಯಿತು ಆದರೆ ಉತ್ತರಿಸಲಿಲ್ಲ, ಅಥವಾ ಉತ್ತರಿಸಿ ಹಿಂತಿರುಗುವ ದಾರಿಯಲ್ಲಿ ಕಳೆದುಹೋಯಿತು. ಇವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದೂ ಬೇರೆ ಮಾಲೀಕ ಮತ್ತು ಬೇರೆ ಮುಂದಿನ ಆದೇಶವನ್ನು ಸೂಚಿಸುತ್ತದೆ. "VPN ಸರ್ವರ್‌ನಿಂದ ಯಾವುದೇ ಪ್ರತಿಕ್ರಿಯೆ ಇಲ್ಲ" ಎಂಬುದು ನಾಲ್ಕು ಬೇರೆ ಬೇರೆ ದೋಷಗಳನ್ನು ಸೆರೆಹಿಡಿಯುವಿಕೆ ಎಂದಿಗೂ ಸಮರ್ಥಿಸದ ಒಂದು ವಾಕ್ಯಕ್ಕೆ ತುರುಕುತ್ತದೆ.
ಸೆರೆಹಿಡಿಯುವಿಕೆಗಳನ್ನು ಸಂಕುಚಿತವಾಗಿಡಿ, ಮತ್ತು ಕಚ್ಚಾ ಕರ್ನಲ್ ಸ್ಥಿತಿಯನ್ನು ಟಿಕೆಟ್‌ಗಳಿಂದ ಹೊರಗಿಡಿ, ಏಕೆಂದರೆ ಅದು ಹೋಸ್ಟ್‌ನಿಂದ ಹೊರಹೋಗಬಾರದ ಕೀ ಸಾಮಗ್ರಿಯನ್ನು ಒಯ್ಯಬಹುದು. ಕೌಂಟರ್ ವ್ಯತ್ಯಾಸಗಳು ಮತ್ತು ಸಮಯ ಚಿಹ್ನೆಗಳೇ ಮುಂದಿನ ವ್ಯಕ್ತಿಗೆ ನೀಡಲು ಯೋಗ್ಯವಾದ ಭಾಗಗಳು.