ESP ಸರಿಯಾಗಿ ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಒಳಗಿನ ಪ್ಯಾಕೆಟ್ ಇನ್ನೂ ಎಲ್ಲಿಗೂ ಹೋಗುವುದಿಲ್ಲ

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

ಲೇಬಲ್ ಸುಳ್ಳು ಹೇಳಿದಾಗ ಏನು ಕಾಣುತ್ತದೆ

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

ಏರುತ್ತಿರುವ ರಿಸೀವ್ ಕೌಂಟರ್ ನಿಜವಾಗಿಯೂ ಒಳ್ಳೆಯ ಸುದ್ದಿ: ಪ್ಯಾಕೆಟ್‌ಗಳು ಬರುತ್ತಿವೆ ಮತ್ತು ದೃಢೀಕರಿಸಲ್ಪಡುತ್ತಿವೆ. ಆದರೆ ಒಳಗಿನ ಪ್ಯಾಕೆಟ್ ಕ್ರಿಪ್ಟೋ ಪದರದ ಮೇಲಿನ ಯಾವುದಕ್ಕೂ ಅರ್ಥಪೂರ್ಣವಾಗಿತ್ತು ಎಂಬುದಕ್ಕೆ ಇದು ಸಾಕ್ಷ್ಯವಲ್ಲ.

ಪ್ರಕಾರ ಟ್ರೇಲರ್‌ನಲ್ಲಿ ವಾಸಿಸುತ್ತದೆ

ಸಾಮಾನ್ಯ IPsec ಟನಲ್ ಮೋಡ್‌ನಲ್ಲಿ, ESP ಸಂರಕ್ಷಿಸಿದ ಪೇಲೋಡ್ ಪೂರ್ಣ ಒಳಗಿನ IP ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಟ್ರೇಲರ್‌ನ ಮುಂದಿನ ಹೆಡರ್ ಕ್ಷೇತ್ರವು ಆ ಪೇಲೋಡ್ ಏನೆಂದು ಗುರುತಿಸುತ್ತದೆ, ಮತ್ತು ಅದು TCP ಪೋರ್ಟ್ ಅಲ್ಲ, ಹೊರಗಿನ ಹೆಡರ್‌ನ ಪ್ರೋಟೋಕಾಲ್ ಸಂಖ್ಯೆ ಅಲ್ಲ, ಮತ್ತು ಆರಂಭಿಕ SPI ಹಾಗೂ ಅನುಕ್ರಮ ಸಂಖ್ಯೆ ಕ್ಷೇತ್ರದ ಭಾಗವೂ ಅಲ್ಲ. RFC 4303 ವಿಭಾಗ 2.6 ಅದನ್ನು ಪೇಲೋಡ್-ಪ್ರಕಾರ ಕ್ಷೇತ್ರ ಎಂದು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ, ಇದು ನಿಖರ ಕೆಲಸಕ್ಕೆ ನಿಖರ ಹೆಸರು.

ನೀವು ಎದುರಿಸುವ ಮೌಲ್ಯಗಳು ಚಿಕ್ಕವು ಮತ್ತು ನೆನಪಿಡಲು ಯೋಗ್ಯ: IPv4 ಎಂಬುದು 4 (0x04) ಮತ್ತು IPv6 ಎಂಬುದು 41 (0x29).

ಆ ಸಂಖ್ಯೆಗಳು ಸ್ಥಳೀಯ ಸಂಪ್ರದಾಯದಿಂದಲ್ಲ, IANA ಪ್ರೋಟೋಕಾಲ್ ಸಂಖ್ಯೆ ಹಂಚಿಕೆಗಳಿಂದ ಬರುತ್ತವೆ. IPv4 ಎಂದು ಘೋಷಿಸಿ ಆದರೆ IPv6 ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಸುತ್ತುವ ಕಳುಹಿಸುವವರು ಫಾರ್ಮ್ಯಾಟ್ ಅಸಂಗತಿಯನ್ನು ಉಂಟುಮಾಡಿದ್ದಾರೆ, ಮತ್ತು ತಮ್ಮದೇ ಲೇಬಲ್‌ಗೆ ವಿರುದ್ಧವಾಗಿರುವ ಬೈಟ್‌ಗಳನ್ನು ಯಾವುದೇ ಫೈರ್‌ವಾಲ್ ನಿಯಮ ಸರಿಪಡಿಸುವುದಿಲ್ಲ.

ಸಾಮಾನ್ಯ ಶಂಕಿತರಿಂದ ಅದನ್ನು ಹೇಗೆ ಬೇರ್ಪಡಿಸುವುದು

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

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

ಆ ಸಾಕ್ಷ್ಯವನ್ನು ಯಾರೂ ನೀಡಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ನಿಮಗೆ ಫಾರ್ಮ್ಯಾಟ್ ದೋಷವಿಲ್ಲ. ನಿಮಗೆ ಒಂದು ಸಿದ್ಧಾಂತವಿದೆ, ಮತ್ತು ಸಿಲೆಕ್ಟರ್‌ಗಳೇ ಇನ್ನೂ ಉತ್ತಮ ಪಣ.

ಸರಿಪಡಿಸುವಿಕೆ ಏನಲ್ಲ

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

ದೃಢೀಕೃತ ಹೊಂದಾಣಿಕೆಯಿಲ್ಲದಿರುವಿಕೆ ಸಹವರ್ತಿ ಅನುಷ್ಠಾನದಿಂದ ಬಂದರೆ, ಕನಿಷ್ಠ ಸ್ವಚ್ಛಗೊಳಿಸಿದ ಮರುಸೃಷ್ಟಿಯನ್ನು ಇಟ್ಟುಕೊಂಡು ಅದನ್ನು ಆ ಅನುಷ್ಠಾನದ ಬೆಂಬಲಿತ ಚಾನಲ್‌ಗೆ ಒಯ್ಯಿರಿ.

ಹರಿವನ್ನು ಪರಿಶೀಲಿಸಿ, ಕೌಂಟರ್ ಅಲ್ಲ

ತಿದ್ದುಪಡಿಯ ನಂತರ ನಿಜವಾದ IPv6 ಹರಿವನ್ನು ಆರಂಭದಿಂದ ಕೊನೆಯವರೆಗೆ ಪರೀಕ್ಷಿಸಿ: ಟನಲ್ ಮೂಲಕ ಅಪ್ಲಿಕೇಶನ್ ವಿನಂತಿ, ಅದರ ಉತ್ತರ, ಮತ್ತು ಪ್ರತಿ ಬದಿಯೂ ಕಾಣುವ ವಿಳಾಸ ಜೋಡಿ. ಏರುತ್ತಿರುವ ESP ಕೌಂಟರ್ ಪ್ಯಾಕೆಟ್‌ಗಳು ಸ್ವೀಕರಿಸಲ್ಪಟ್ಟು ದೃಢೀಕರಿಸಲ್ಪಡುತ್ತಿವೆ ಎಂಬುದನ್ನು ಮಾತ್ರ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ಒಳಗಿನ ಪ್ಯಾಕೆಟ್ ಬಳಸಲು ಯೋಗ್ಯವಾಗಿತ್ತೇ ಎಂಬುದರ ಬಗ್ಗೆ ಅದು ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.

ಎರಡೂ ಫಲಿತಾಂಶಗಳನ್ನು ಟಿಕೆಟ್‌ನಲ್ಲಿ ದಾಖಲಿಸಿ. ಕೌಂಟರ್ ಚಲನೆ ಜೊತೆಗೆ ಕೆಲಸ ಮಾಡುವ ಹರಿವು ಸರಿಪಡಿಸುವಿಕೆ; ಕೇವಲ ಕೌಂಟರ್ ಚಲನೆ ಎಂದರೆ ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು ನಿಮ್ಮಲ್ಲಿದ್ದದ್ದೇ.