ASA ದೂರಸ್ಥ ಬಳಕೆದಾರ ಸಬ್‌ನೆಟ್ ತಲುಪುತ್ತಾರೆ ಆದರೆ ಅಪ್ಲಿಕೇಶನ್ ಏಕೆ ತಲುಪುವುದಿಲ್ಲ
ಮಾರ್ಗಗಳು ಸುರಂಗ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತವೆ, ಬಳಕೆದಾರರು ಅಪ್ಲಿಕೇಶನ್ ತೆರೆಯಬಹುದು ಎಂದಲ್ಲ. ಸೆಷನ್ ಪಡೆದ ಫಿಲ್ಟರ್ ಓದಿ, ನಂತರ ಅನುಮತಿಸಿದ ಮತ್ತು ನಿರಾಕರಿಸಿದ ಸಂಪರ್ಕವನ್ನು ಪರೀಕ್ಷಿಸಿ.
ನಿಮ್ಮ ಬಳಕೆದಾರರು ಸಂಪರ್ಕಿಸುತ್ತಾರೆ, ವಿಳಾಸ ಪಡೆಯುತ್ತಾರೆ, ಅಪ್ಲಿಕೇಶನ್‌ನ ಸಬ್‌ನೆಟ್‌ನಲ್ಲಿರುವ ಸರ್ವರ್‌ಗೆ ಪಿಂಗ್ ಮಾಡುತ್ತಾರೆ, ಆದರೂ ಅದರ ಮೇಲಿನ ಸೇವೆಯನ್ನು ತೆರೆಯಲು ಸಾಧ್ಯವಿಲ್ಲ. ಈ ಸಂಯೋಜನೆ ASA ಯಲ್ಲಿ ಸಾಮಾನ್ಯ, ಏಕೆಂದರೆ ಯಶಸ್ವಿ ಸುರಂಗ ಮತ್ತು ಬಳಸಬಹುದಾದ ಅನುಮತಿಯನ್ನು ವಿಭಿನ್ನ ಸೆಟ್ಟಿಂಗ್‌ಗಳು ನಿರ್ಧರಿಸುತ್ತವೆ. ಸ್ಪ್ಲಿಟ್-ಸುರಂಗ ಪಟ್ಟಿ ಯಾವ ಗಮ್ಯಸ್ಥಾನಗಳು ಸುರಂಗವನ್ನು ಪ್ರವೇಶಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ಆಯ್ಕೆ ಮಾಡಿತು; VPN ಫಿಲ್ಟರ್ ಮತ್ತು ಗಮ್ಯಸ್ಥಾನದ ಸ್ವಂತ ಪ್ರವೇಶ ನಿಯಮಗಳು ಡೀಕ್ರಿಪ್ಟ್ ಆದ ವಿನಂತಿ ಎಲ್ಲಿಗೆ ತಲುಪಬಹುದು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ. ಮಾರ್ಗ ಪಟ್ಟಿಯನ್ನು ಅಗಲಗೊಳಿಸುವ ಬದಲು ಮೂರು ನಿರ್ಣಯಗಳನ್ನು ಕ್ರಮವಾಗಿ ನಿಭಾಯಿಸಿ, ಏನಾದರೂ ಬದಲಾಗುವವರೆಗೆ.
ಗೊಂದಲಕ್ಕೀಡಾಗುವ ಮೂರು ನಿರ್ಣಯಗಳು
ಪ್ರವೇಶವು ಬಳಕೆದಾರರು ಸುರಂಗವನ್ನು ನಿರ್ಮಿಸಬಹುದೇ ಎಂದು ಉತ್ತರಿಸುತ್ತದೆ: ರುಜುವಾತುಗಳು, ಪ್ರಮಾಣಪತ್ರ ಮತ್ತು ಯಾವುದೇ ಎರಡನೇ ಅಂಶ. ಮಾರ್ಗ ಆಯ್ಕೆಯು ಕ್ಲೈಂಟ್ ಯಾವ ಗಮ್ಯಸ್ಥಾನಗಳನ್ನು ಆ ಸುರಂಗಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆ ಎಂದು ಉತ್ತರಿಸುತ್ತದೆ. ಅಧಿಕಾರವು ಡೀಕ್ರಿಪ್ಟ್ ಆದ ವಿನಂತಿ ಸೇವೆಯನ್ನು ತಲುಪಬಹುದೇ ಎಂದು ಉತ್ತರಿಸುತ್ತದೆ. ಬಳಕೆದಾರರು ವರದಿ ಮಾಡುವ ದೋಷವನ್ನು ಮೂರನೆಯದು ಮಾತ್ರ ಉಂಟುಮಾಡುತ್ತದೆ.
ಅವುಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸುವ ತ್ವರಿತ ಮಾರ್ಗವೆಂದರೆ ಬದಲಾವಣೆಯು ಏನನ್ನು ಮುರಿಯುತ್ತದೆ ಎಂದು ಕೇಳುವುದು. ಸ್ಪ್ಲಿಟ್ ಪಟ್ಟಿಯಿಂದ ಮಾರ್ಗವನ್ನು ತೆಗೆದರೆ ಆ ಸಬ್‌ನೆಟ್‌ಗೆ ಸಂಚಾರ ನಿಲ್ಲುತ್ತದೆ, ಆದರೆ ಏನನ್ನೂ ನೀಡುವುದಿಲ್ಲ; VPN ಫಿಲ್ಟರ್‌ಗೆ ACE ಸೇರಿಸಿದರೆ ಕ್ಲೈಂಟ್ ಸುರಂಗದಲ್ಲಿ ಏನನ್ನು ಸಾಗಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಿಸದೆ ಗಮ್ಯಸ್ಥಾನವನ್ನು ನೀಡುತ್ತದೆ.
| Setting | What it decides | Symptom when it is wrong |
|---|---|---|
| Connection profile and authentication | Whether the tunnel is built | Login fails, no address assigned |
| Split-tunnel network list | Which destinations the client routes into the tunnel | Subnet unreachable from the client, everything else fine |
| VPN filter (ACL) | Which decrypted flows are permitted | Tunnel up, ping may work, TCP service refused or dropped |
ಸೆಷನ್ ನಿಜವಾಗಿ ಪಡೆದ ಫಿಲ್ಟರ್ ಓದಿ
ನೀವು ಅನ್ವಯವಾಗುತ್ತದೆ ಎಂದು ಭಾವಿಸುವ ಸಂರಚನೆಯಿಂದ ಅಲ್ಲ, ಜೀವಂತ ಸೆಷನ್‌ನಿಂದ ಪ್ರಾರಂಭಿಸಿ. show vpn-sessiondb detail anyconnect ನಿಗದಿಪಡಿಸಿದ ಗುಂಪು ನೀತಿ ಮತ್ತು ಆ ಸೆಷನ್‌ಗೆ ಲಗತ್ತಿಸಿದ ಫಿಲ್ಟರ್ ಹೆಸರನ್ನು ಮುದ್ರಿಸುತ್ತದೆ. ಕ್ಷೇತ್ರ ಖಾಲಿಯಿದ್ದರೆ, ಯಾವುದೇ ಫಿಲ್ಟರ್ ಏನನ್ನೂ ಜಾರಿಗೊಳಿಸುತ್ತಿಲ್ಲ ಮತ್ತು ನಿರ್ಬಂಧ ಬೇರೆಡೆಯಿಂದ ಬರುತ್ತದೆ.
ನಂತರ ಮೌಲ್ಯವನ್ನು ಹೊಂದಿರುವ ನೀತಿಯನ್ನು ಓದಿ, ಡೀಫಾಲ್ಟ್‌ಗಳೂ ಸೇರಿದಂತೆ, ಏಕೆಂದರೆ ಫಿಲ್ಟರ್ ನೀವು ನೋಡುತ್ತಿರುವ ಸ್ಥಳದಲ್ಲಿ ಬರೆಯುವ ಬದಲು ಆನುವಂಶಿಕವಾಗಿ ಬರಬಹುದು:
show run all group-policy <policy-name>
show run access-list <acl-name>
show run webvpn
ಸೆಷನ್‌ನಲ್ಲಿನ ಫಿಲ್ಟರ್ ಹೆಸರನ್ನು ನೀವು ಈಗಷ್ಟೇ ಸಂಪಾದಿಸಿದ ACL ಜೊತೆ ಹೋಲಿಸಿ. ಬಳಕೆದಾರರು ಎಂದೂ ಪಡೆಯದ ಹೋಲುವ ಹೆಸರಿನ ACL ಆ ಸೆಷನ್‌ನ ಸಂಪನ್ಮೂಲ ನೀತಿಯನ್ನು ಬದಲಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ, ಮತ್ತು ಸರಿಯಾಗಿ ಕಾಣುವ ಬದಲಾವಣೆಗೆ ಪರಿಣಾಮವಿಲ್ಲದಿರುವುದಕ್ಕೆ ಇದೇ ಸಾಮಾನ್ಯ ಕಾರಣ.
ಆದ್ಯತೆ ಉಳಿದದ್ದನ್ನು ವಿವರಿಸುತ್ತದೆ. ಫಿಲ್ಟರ್ ಸೆಟ್ಟಿಂಗ್‌ಗೆ, DAP ದಾಖಲೆ ಬಳಕೆದಾರರ ಹೆಸರಿನ ಗುಣಲಕ್ಷಣಗಳಿಗಿಂತ ಮೇಲು, ಮತ್ತು ಬಳಕೆದಾರರ ಹೆಸರಿನ ಗುಣಲಕ್ಷಣಗಳು ಗುಂಪು ನೀತಿಗಿಂತ ಮೇಲು. ಸೆಷನ್ ನಿರೀಕ್ಷಿಸದ ಫಿಲ್ಟರ್ ತೋರಿಸಿದಾಗ, ಗುಂಪನ್ನು ಮುಟ್ಟುವ ಮೊದಲು ಆ ಬಳಕೆದಾರರಿಗೆ ಹೊಂದುವ DAP ನೀತಿಯನ್ನು ಹುಡುಕಿ.
ಸ್ಪ್ಲಿಟ್ ಪಟ್ಟಿ ಮತ್ತು ಫಿಲ್ಟರ್ ಪ್ರತ್ಯೇಕ ಕ್ಷೇತ್ರಗಳು
ASA 9.x ನಲ್ಲಿ ಗುಂಪು ನೀತಿ split-tunnel-network-list ಮತ್ತು vpn-filter ಅನ್ನು ವಿಭಿನ್ನ ಸೆಟ್ಟಿಂಗ್‌ಗಳಾಗಿ ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ, ಮತ್ತು 9.22 ಗುಂಪು-ನೀತಿ ಮಾರ್ಗದರ್ಶಿ ಅದೇ ಕಾರಣಕ್ಕೆ ಅವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ದಾಖಲಿಸುತ್ತದೆ. ನೆಟ್‌ವರ್ಕ್ ಪಟ್ಟಿ ಕ್ಲೈಂಟ್‌ಗೆ ಮಾರ್ಗದರ್ಶನ ಸೂಚನೆ; ಫಿಲ್ಟರ್ ಡೀಕ್ರಿಪ್ಟ್ ಆದ ಸಂಚಾರಕ್ಕೆ ಅನ್ವಯಿಸುವ ಪ್ರವೇಶ ನಿಯಂತ್ರಣ ಪಟ್ಟಿ.
ಬಳಕೆದಾರರಿಗೆ ಸಬ್‌ನೆಟ್‌ನಲ್ಲಿ ಒಂದೇ HTTPS ಸೇವೆ ಬೇಕಾದಾಗ ಈ ವ್ಯತ್ಯಾಸ ಮುಖ್ಯ. ಪ್ಯಾಕೆಟ್‌ಗಳು ಸುರಂಗವನ್ನು ಪ್ರವೇಶಿಸಲು ಸಬ್‌ನೆಟ್ ಅನ್ನು ಸ್ಪ್ಲಿಟ್ ಪಟ್ಟಿಗೆ ಹಾಕಿ, ನಂತರ ಫಿಲ್ಟರ್‌ನಲ್ಲಿ ಆ ಸೇವೆಗೆ ಮಾತ್ರ ಅನುಮತಿಸಿ. ಮಾರ್ಗ ಪಟ್ಟಿಯನ್ನು ವಿಸ್ತರಿಸುವುದು ಏನನ್ನೂ ಅಧಿಕಾರ ನೀಡುವುದಿಲ್ಲ, ಮತ್ತು ಅದನ್ನು ಸಂಕುಚಿಸುವುದು ಜಾರಿ ಕಾರ್ಯವಿಧಾನವಲ್ಲ.
ಇಂಟರ್ಫೇಸ್ ACL ಕೂಡ ಮಾರ್ಗದಲ್ಲಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ
ಡೀಕ್ರಿಪ್ಟ್ ಆದ ದೂರಸ್ಥ ಪ್ರವೇಶ ಸಂಚಾರವು ಜನರು ಊಹಿಸಿದಂತೆ ಯಾವಾಗಲೂ ಹೊರಗಿನ ಇಂಟರ್ಫೇಸ್ ACL ಮೂಲಕ ಹಾದುಹೋಗುವುದಿಲ್ಲ. sysopt connection permit-vpn ಸಕ್ರಿಯವಾಗಿರುವಲ್ಲಿ, ASA ಆ ಸಂಚಾರಕ್ಕೆ ತನ್ನ ದಾಖಲಿತ VPN ಬೈಪಾಸ್ ಅನ್ನು ಅನ್ವಯಿಸುತ್ತದೆ, ಆದರೆ ಅನ್ವಯವಾಗುವ VPN ಫಿಲ್ಟರ್‌ಗಳು ಅದರ ನಂತರವೂ ಜಾರಿಯಲ್ಲಿರುತ್ತವೆ. ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು show run all sysopt ನಿಂದ ಪರಿಶೀಲಿಸಿ, ಟೋಪಾಲಜಿ ರೇಖಾಚಿತ್ರದಿಂದ ತರ್ಕಿಸುವ ಬದಲು.
ಹೇಗಾದರೂ, ಗಮ್ಯಸ್ಥಾನದ ಹೋಸ್ಟ್‌ನ ಸ್ವಂತ ಫೈರ್‌ವಾಲ್ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ನ ಅಧಿಕಾರ ಮಾರ್ಗದಲ್ಲೇ ಉಳಿಯುತ್ತವೆ. TCP 443 ಗೆ ಅನುಮತಿ ನೀಡುವ ASA ನಿಯಮ ಅಪ್ಲಿಕೇಶನ್ ಬಳಕೆದಾರರನ್ನು ಸ್ವೀಕರಿಸುವಂತೆ ಮಾಡುವುದಿಲ್ಲ.
ನಿರಾಕರಿಸಿದ ಸಂಪರ್ಕದೊಂದಿಗೂ ಬದಲಾವಣೆಯನ್ನು ಸ್ವೀಕರಿಸಿ
ಅನುಮತಿಸಿದ ಪರೀಕ್ಷೆ ಒಂದೇ ಸ್ವಲ್ಪವೇ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಕೆಲಸ ಮಾಡುವ ಸುರಂಗ ಫಿಲ್ಟರ್ ಇರಲಿ ಇಲ್ಲದಿರಲಿ ಅದೇ ಮೊದಲ ಪ್ಯಾಕೆಟ್ ಉತ್ಪಾದಿಸುತ್ತದೆ. ಕ್ಲೈಂಟ್‌ನಿಂದ ಉದ್ದೇಶಿತ ಸೇವೆಯನ್ನು ತೆರೆಯಿರಿ, ನಂತರ ಮುಚ್ಚಿದ್ದೇ ಇರಬೇಕಾದ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಪ್ರಯತ್ನಿಸಿ ಮತ್ತು ಅದು ಸರಿಯಾದ ಕಾರಣದಿಂದ ವಿಫಲವಾಗುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ.
ಟಿಕೆಟ್ ಮುಚ್ಚುವಾಗ ನಾಲ್ಕು ಅಂಶಗಳನ್ನು ದಾಖಲಿಸಿ: ಸ್ವೀಕರಿಸಿದ ಗುರುತು, ಸೆಷನ್ ನಿಜವಾಗಿ ಪಡೆದ ನೀತಿ ಮತ್ತು ಫಿಲ್ಟರ್, ಸ್ಪ್ಲಿಟ್ ಪಟ್ಟಿಯಲ್ಲಿನ ಗಮ್ಯಸ್ಥಾನಗಳು, ಮತ್ತು ಬಳಕೆದಾರರಿಗೆ ತಲುಪಲು ಅನುಮತಿಸಿದ ಸಂಪನ್ಮೂಲ. ಆ ನಾಲ್ಕು ಮಾರ್ಗ ಪಟ್ಟಿಯನ್ನು ಫೈರ್‌ವಾಲ್ ಆಗಿ ಬದಲಿಸದೆ ಸಂಚಾರ ಎಲ್ಲಿ ನಿಯಂತ್ರಿಸಲ್ಪಡುತ್ತದೆ ಎಂದು ವಿವರಿಸುತ್ತವೆ.
ಫಿಲ್ಟರ್ ಅನುಮತಿ ನೀಡಿದ ನಂತರವೂ ಸೇವೆ ನಿರಾಕರಿಸಿದರೆ, ಹೋಸ್ಟ್‌ಗೆ ಹೋಗಿ: ಆಲಿಸುವ ವಿಳಾಸ, ಹೋಸ್ಟ್ ಫೈರ್‌ವಾಲ್ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ನ ಸ್ವಂತ ಬಳಕೆದಾರ ಮ್ಯಾಪಿಂಗ್. ಆ ಹಂತದಲ್ಲಿ ಸುರಂಗ ತನ್ನ ಕೆಲಸ ಮಾಡಿತು, ಮತ್ತು ASA ನಲ್ಲಿ ಹೆಚ್ಚಿನ ಬದಲಾವಣೆಗಳು ಅಪಾಯವನ್ನು ಮಾತ್ರ ಸೇರಿಸುತ್ತವೆ.