VPN ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡಿದ ನಂತರ ಯಾವ ASA ನಿಯಮ ಟ್ರಾಫಿಕ್ ನೋಡುತ್ತದೆ

ಮೊದಲು ಬಿಡಬೇಕಾದ ಊಹೆ ಎಂದರೆ ಕ್ರಿಪ್ಟೋ ACL ಒಂದು ಪ್ರವೇಶ ನೀತಿ ಎಂಬುದು. ಹಾಗಲ್ಲ. Cisco ASA ನಲ್ಲಿ ಆ ಪಟ್ಟಿ ಒಂದು ಸಂಕುಚಿತ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ: ಯಾವ ಪ್ಯಾಕೆಟ್‌ಗಳು ರಕ್ಷಣೆಗೆ ಅರ್ಹ, ಮತ್ತು ಆ ಉತ್ತರ ಡೀಕ್ರಿಪ್ಟ್ ಆದ ಪ್ಯಾಕೆಟ್ ಫೈರ್‌ವಾಲ್ ಹಿಂದಿನ ಸರ್ವರ್‌ಗೆ ತಲುಪಬಹುದೇ ಎಂಬುದರ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಪ್ರವೇಶದ ನಿರ್ಣಯ ನಂತರ ತೆಗೆದುಕೊಳ್ಳಲಾಗುತ್ತದೆ — ಇಂಟರ್ಫೇಸ್ ನೀತಿ, ಗ್ರೂಪ್-ಪಾಲಿಸಿ ಫಿಲ್ಟರ್, ಅಥವಾ ಎರಡೂ, ಟನಲ್ ಹೇಗೆ ನಿರ್ಮಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ಅವಲಂಬಿಸಿ.

ಕ್ರಿಪ್ಟೋ ACL ಬೇರೊಂದು ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ

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

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

ಬೈಪಾಸ್ ಸೆಟ್ಟಿಂಗ್ ನಿಜವಾಗಿ ಏನನ್ನು ಬಿಟ್ಟುಬಿಡುತ್ತದೆ

sysopt connection permit-vpn ರಕ್ಷಿತ ಟ್ರಾಫಿಕ್‌ಗೆ ಒಳಬರುವ ಬದಿಯಲ್ಲಿ ಇಲ್ಲದಿದ್ದರೆ ಅನ್ವಯವಾಗುತ್ತಿದ್ದ ಇಂಟರ್ಫೇಸ್ ACL ಪರಿಶೀಲನೆಯನ್ನು ಬಿಟ್ಟುಬಿಡಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ಇದು VPN ನಿಯೋಜನೆಗಳಿಗೆ ಒಂದು ಸೌಲಭ್ಯ, ಮತ್ತು ಇದು ಜಾಗತಿಕ. ಇದು ಗ್ರೂಪ್ ಪಾಲಿಸಿಯನ್ನು ಮುಟ್ಟುವುದಿಲ್ಲ, ಮತ್ತು ಪ್ರತಿ-ಬಳಕೆದಾರ ಅಧಿಕಾರ ಫಿಲ್ಟರ್ ಅನ್ನೂ ಮುಟ್ಟುವುದಿಲ್ಲ.

ಊಹೆಯ ಬದಲು ನಿಜವಾದ ಮೌಲ್ಯವನ್ನು ಓದಿ: show running-config all sysopt ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಎಂದಿಗೂ ಸ್ಪಷ್ಟವಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡದಿದ್ದರೂ ಮುದ್ರಿಸುತ್ತದೆ, ಮತ್ತು ಬಹಳ ಗೊಂದಲ ಅಲ್ಲಿಂದಲೇ ಆರಂಭವಾಗುತ್ತದೆ.

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

ಡೀಕ್ರಿಪ್ಟ್ ದಿಕ್ಕಿನಲ್ಲಿ ಫಿಲ್ಟರ್ ಓದಿ

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

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

ಯಾವ ಫಿಲ್ಟರ್ ನಿಜವಾಗಿ ಲಗತ್ತಿಸಲಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ: show running-config group-policy ಮತ್ತು show vpn-sessiondb detail l2l ಒಟ್ಟಿಗೆ ಸೆಷನ್ ಏನನ್ನು ಬಳುವಳಿಯಾಗಿ ಪಡೆದಿದೆ ಎಂದು ಹೇಳುತ್ತವೆ. ಯಾವುದೇ ನೀತಿ ಉಲ್ಲೇಖಿಸದ ACL ಅನ್ನು ಸಂಪಾದಿಸುವುದರಿಂದ ಏನೂ ಬದಲಾಗುವುದಿಲ್ಲ.

ಒಂದು ACL ವಸ್ತುವನ್ನು ಎರಡು ಕೆಲಸಗಳಿಗೆ ಮರುಬಳಕೆ ಮಾಡಬೇಡಿ

ಇಂಟರ್ಫೇಸ್‌ನ access-group ಮತ್ತು vpn-filter ಒಂದೇ ರೀತಿಯ ವಸ್ತುವಿನಂತೆ ಕಾಣುತ್ತವೆ ಮತ್ತು ವಿಭಿನ್ನ ಹಂತಗಳಲ್ಲಿ ವಿಭಿನ್ನ ವಿಳಾಸ ದಿಕ್ಕಿನೊಂದಿಗೆ ಮೌಲ್ಯಮಾಪನವಾಗುತ್ತವೆ. ಒಂದು ಪಟ್ಟಿಯನ್ನು ಎರಡಕ್ಕೂ ನೀಡುವುದು ಟನಲ್ ಸರಿಪಡಿಸಿ ಭೌತಿಕ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಮೌನವಾಗಿ ಸಡಿಲಗೊಳಿಸುವ ಬದಲಾವಣೆಗೆ ಆಹ್ವಾನ ನೀಡುತ್ತದೆ.

ಅವುಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿ, ಅವುಗಳ ಕೆಲಸದಂತೆ ಹೆಸರಿಸಿ, ಮತ್ತು ದಿಕ್ಕಿನ ವ್ಯತ್ಯಾಸ ಹೆಸರುಗಳಲ್ಲಿ ಕಾಣುವಂತೆ ಮಾಡಿ.

ಹೊಸ ಸಂಪರ್ಕಗಳೊಂದಿಗೆ, ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಪರಿಶೀಲಿಸಿ

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

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

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