ಸೈಟ್ VPN ಮೂಲಕ ದೂರದ ASA ಗೆ SSH: ಹಂತ ಹಂತವಾಗಿ

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

ನೀವು ನಿಜವಾಗಿ ನಿರ್ವಹಿಸುತ್ತಿರುವ ವಿಳಾಸವನ್ನು ಆಯ್ಕೆಮಾಡಿ

ಮೂರು ವಿನ್ಯಾಸಗಳು ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ ಮತ್ತು ವಿಭಿನ್ನವಾಗಿ ವರ್ತಿಸುತ್ತವೆ: ASA ಯ ಸಾರ್ವಜನಿಕ VPN-ಮುಖಿ ವಿಳಾಸವನ್ನು ತಲುಪುವುದು, IPsec ಮೂಲಕ ಆಂತರಿಕ ಇಂಟರ್ಫೇಸ್ ತಲುಪುವುದು, ಮತ್ತು ಮೀಸಲಾದ ನಿರ್ವಹಣಾ ಇಂಟರ್ಫೇಸ್ ತಲುಪುವುದು. ಯಾವುದೇ ಅನುಮತಿಯನ್ನು ಮುಟ್ಟುವ ಮೊದಲು ನಿರ್ವಾಹಕರ ಮೂಲ ವಿಳಾಸ, ನಿಖರ ಗಮ್ಯಸ್ಥಾನ ವಿಳಾಸ ಮತ್ತು TCP 22 ಅನ್ನು ಬರೆದಿಡಿ. ಮುಂದಿನ ಎಲ್ಲವೂ ಆ ಜೋಡಿಯ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ.

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

ಗಮ್ಯಸ್ಥಾನ ಫೈರ್‌ವಾಲ್ ಸ್ವತಃ ಆಗಿರುವುದರಿಂದ, ನಿರ್ವಹಣಾ ಪ್ರವೇಶವು ಮುಂದಕ್ಕೆ ರವಾನೆಯಾದ ಸಂಚಾರದ ನಿಯಮಗಳಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿದೆ. ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ASA ಯ ಹಿಂದಿನ ಸರ್ವರ್‌ಗಳಿಗೆ ತಲುಪಲು ಬಿಡುವ ACL ಸ್ವತಂತ್ರವಾಗಿ ಸಾಧನದ SSH ನಿರ್ವಹಣೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವುದಿಲ್ಲ, ಮತ್ತು ರವಾನೆ ನಿಯಮವನ್ನು ಸರಿಪಡಿಸುವುದರಿಂದ ಈ ವೈಫಲ್ಯ ಸರಿಯುವುದಿಲ್ಲ.

management-access ಇಂಟರ್ಫೇಸ್-ನಿರ್ದಿಷ್ಟವಾಗಿದೆ

management-access ಆದೇಶವು VPN ಮೂಲಕ ಬರುವ ನಿರ್ವಹಣಾ ಸಂಪರ್ಕಗಳನ್ನು ಹೆಸರಿಸಿದ ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ ಸ್ವೀಕರಿಸಲು ASA ಗೆ ಹೇಳುತ್ತದೆ. ಅದು ಮಾರ್ಗವನ್ನು ರಚಿಸುವುದಿಲ್ಲ, SSH ಅನುಮತಿಯನ್ನು ಸೇರಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಒಂದೇ ಸಮಯದಲ್ಲಿ ಎಲ್ಲಾ ಇಂಟರ್ಫೇಸ್‌ಗಳಿಗೆ ಅನ್ವಯವಾಗುವುದಿಲ್ಲ. ಗಮ್ಯಸ್ಥಾನ ಇಂಟರ್ಫೇಸ್ ಹೆಸರಿಸಿದ್ದಲ್ಲದಿದ್ದರೆ, ದೃಢೀಕರಣಕ್ಕೆ ಮೊದಲೇ ಸಂಪರ್ಕವನ್ನು ತಿರಸ್ಕರಿಸಲಾಗುತ್ತದೆ.

ಇಲ್ಲಿ ಎರಡು ಹೊರತುಪಡಿಸುವಿಕೆಗಳು ಕಚ್ಚುತ್ತವೆ. ನಿರ್ವಹಣೆಗೆ ಮಾತ್ರ ಇರುವ ಇಂಟರ್ಫೇಸ್‌ಗಳು ಈ ಕಾರ್ಯವಿಧಾನದ ಹೊರಗಿವೆ, ಮತ್ತು ASA 9.20 ನಿರ್ವಹಣಾ ಮಾರ್ಗದರ್ಶಿ ಡೀಫಾಲ್ಟ್ CiscoSSH ಸ್ಟ್ಯಾಕ್ VPN ಮೂಲಕ ಇಂಟರ್ಫೇಸ್-ಅಂತರ SSH ಬೆಂಬಲಿಸುವುದಿಲ್ಲ ಎಂದು ಗಮನಿಸುತ್ತದೆ, ಆದರೆ ASA SSH ಸ್ಟ್ಯಾಕ್ ಬೆಂಬಲಿಸುತ್ತದೆ. ಮಾರ್ಗಗಳಿಗೆ ಸಮಯ ವ್ಯಯಿಸುವ ಮೊದಲು ನಿಯೋಜಿತ ಆವೃತ್ತಿಯಲ್ಲಿ ಸಕ್ರಿಯ ಸ್ಟ್ಯಾಕ್ ಖಚಿತಪಡಿಸಿ.

ಲಾಗಿನ್ ಪ್ರಾಂಪ್ಟ್‌ಗೆ ಮೊದಲು ನಾಲ್ಕು ಗೇಟ್‌ಗಳು

ಕ್ಲೈಂಟ್ ಮತ್ತು ಬಳಕೆದಾರಹೆಸರಿನ ಪ್ರಾಂಪ್ಟ್ ನಡುವೆ ನಾಲ್ಕು ಸ್ವತಂತ್ರ ಗೇಟ್‌ಗಳಿವೆ: ನಿರ್ವಹಣಾ ಜೋಡಿಗೆ ಮಾರ್ಗ ಮತ್ತು ಸುರಂಗದ ಹೊಂದಾಣಿಕೆ, ASA ವಿಳಾಸಕ್ಕೆ TCP 22 ಅನ್ನು ಅನುಮತಿಸುವ ಇಂಟರ್ಫೇಸ್ ACL, ನಿರ್ವಾಹಕರ ಮೂಲವನ್ನು ಆವರಿಸುವ ssh ಅನುಮತಿ, ಮತ್ತು ಆ ಬಳಕೆದಾರರಿಗೆ AAA ದೃಢೀಕರಣ. ಪ್ರತಿಯೊಂದೂ ಯಾವ ಗೇಟ್ ಮುಚ್ಚಿತು ಎಂದು ಕ್ಲೈಂಟ್‌ಗೆ ಹೇಳದೆ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಬಿಡಬಹುದು.

ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ಯಾವ ಗೇಟ್ ವಿಫಲವಾಗುತ್ತದೆ ಎಂದು ನೋಡಲು packet-tracer ಬಳಸಿ: packet-tracer input inside tcp 10.10.5.20 50000 10.20.1.1 22 detailed. ಟ್ರೇಸ್ ACL, NAT ಹಂತ ಮತ್ತು to-the-box ನಿರ್ಧಾರವನ್ನು ಹೆಸರಿಸುತ್ತದೆ, ಇದು ಸಾಮಾನ್ಯವಾಗಿ ರೂಟಿಂಗ್ ಸಮಸ್ಯೆಯನ್ನು ಪ್ರವೇಶ ಸಮಸ್ಯೆಯಿಂದ ಬೇರ್ಪಡಿಸಲು ಸಾಕು.

ಕಿರಿದಾದ ಅನುಮತಿ ಬರೆಯಿರಿ, ಅಗಲವಾದದ್ದಲ್ಲ

ಅನುಮತಿಯನ್ನು ಅನುಮೋದಿತ ಆಡಳಿತಾತ್ಮಕ ಸಬ್‌ನೆಟ್ ಮತ್ತು ಸುರಂಗದ ಸಂಚಾರವನ್ನು ಸ್ವೀಕರಿಸುವ ಇಂಟರ್ಫೇಸ್‌ಗೆ ಸೀಮಿತಗೊಳಿಸಿ: ssh 10.10.5.0 255.255.255.0 inside. ಹೊರಗಿನ ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ ಪ್ರತಿ ಮೂಲವನ್ನು ತೆರೆಯುವ ಬದಲು ಅದನ್ನು aaa authentication ssh console LOCAL ನಂತಹ ದೃಢೀಕರಣ ವಿಧಾನ ಮತ್ತು ಹೆಸರಿಸಿದ ಸ್ಥಳೀಯ ಖಾತೆಯೊಂದಿಗೆ ಜೋಡಿಸಿ.

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

ಹೆಸರಿಸಿದ ಹೋಸ್ಟ್‌ನಿಂದ ಪರಿಶೀಲಿಸಿ, ನಂತರ ಮತ್ತೆ ಕಿರಿದಾಗಿಸಿ

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

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