ಸ್ಪ್ಲಿಟ್ ಟನೆಲ್ ಸಾರ್ವಜನಿಕ ಹೋಸ್ಟ್ ಅನ್ನು ASA ನ NAT ನಿಯಮಗಳಿಂದ ವಿನಾಯಿತಿ ನೀಡುವುದಿಲ್ಲ

split-include ರೂಟ್ ಸಾರ್ವಜನಿಕ ಹೋಸ್ಟ್ ಅನ್ನು ಟನೆಲ್ ಒಳಗೆ ಎಳೆದುಕೊಳ್ಳುತ್ತದೆ, ಅಲ್ಲಿ ASA ಹೇರ್ಪಿನ್ ಮಾಡಿ ಮೂಲವನ್ನು ಅನುವಾದಿಸಬೇಕು. ಎರಡರಲ್ಲಿ ಒಂದು ಹಂತವನ್ನು ಬಿಟ್ಟರೂ ಹರಿವು ಕುಸಿಯುತ್ತದೆ.

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

ನಿಮ್ಮ ಪ್ರಧಾನ ಕಚೇರಿಯ ವಿಳಾಸವನ್ನು ನೋಡಲೇಬೇಕೆಂದು ಹಠ ಹಿಡಿಯುವ ಸಾರ್ವಜನಿಕ ವಿಳಾಸದ ಒಂದೇ ಪಾಲುದಾರ ಸೇವೆ ಈ ಕಥೆಯನ್ನು ಒಡೆಯಲು ಸಾಕು.

ಪುರಾಣ: ಸ್ಪ್ಲಿಟ್ ಟನೆಲ್ ಫೈರ್‌ವಾಲ್ ಅನ್ನು ಮಾರ್ಗದಿಂದ ತೆಗೆಯುತ್ತದೆ

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

ಕ್ಲೈಂಟ್ ರೂಟರ್ ಆಗಲಿಲ್ಲ. ನೀವು ಕೊಟ್ಟ ನೀತಿಯನ್ನೇ ಅದು ಅನುಸರಿಸಿತು.

split-include ರೂಟ್ ನಿಜವಾಗಿ ಏನು ಮಾಡುತ್ತದೆ

Cisco ASA ರಿಮೋಟ್-ಆಕ್ಸೆಸ್ ಸೆಟಪ್‌ನಲ್ಲಿ ಗುಂಪು ನೀತಿ split-tunnel-policy tunnelspecified ಮತ್ತು ಪ್ರಮಾಣಿತ ACL ಅನ್ನು ಹೆಸರಿಸುವ split-tunnel-network-list ಅನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಆ ACL ನಲ್ಲಿನ ಪ್ರತಿ permit ಸಾಲು ಕ್ಲೈಂಟ್ ಟನೆಲ್‌ಗೆ ಕಳುಹಿಸಬೇಕಾದ ಗಮ್ಯಸ್ಥಾನ, ಮತ್ತು ಉಳಿದೆಲ್ಲವೂ ಸ್ಥಳೀಯ ಡಿಫಾಲ್ಟ್ ರೂಟ್ ಬಳಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತದೆ.

ಒಂದು ಹೋಸ್ಟ್ ಸೇರಿಸುವುದು ಒಂದೇ ಸಾಲು, ಮತ್ತು ಕ್ಲೈಂಟ್ ನೋಡಬಹುದಾದ ಬದಲಾವಣೆಯ ಏಕೈಕ ಭಾಗ ಅದೇ: access-list RA-SPLIT standard permit host 203.0.113.20.

ನಂತರ ಕ್ಲೈಂಟ್ ಅನ್ನು ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿ. ನೀತಿ ಸಂಪರ್ಕದ ಸಮಯದಲ್ಲಿ ವಿನಿಮಯವಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಸ್ಥಾಪಿತ ಸೆಷನ್ ಹಳೆಯ ಪಟ್ಟಿಯನ್ನು ಉಳಿಸಿಕೊಂಡು ಬದಲಾವಣೆ ಏನೂ ಮಾಡಿಲ್ಲ ಎಂಬಂತೆ ಕಾಣಿಸುತ್ತದೆ.

ಪ್ಯಾಕೆಟ್ ಅದೇ ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ ಬರುತ್ತದೆ ಮತ್ತು ಹೋಗುತ್ತದೆ

ಈಗ ಡಿಕ್ರಿಪ್ಶನ್ ನಂತರದ ಹರಿವನ್ನು ಟ್ರೇಸ್ ಮಾಡಿ. ಪ್ಯಾಕೆಟ್ VPN ಟನೆಲ್ ಮೂಲಕ ಹೊರಗಿನ ಇಂಟರ್ಫೇಸ್‌ಗೆ ಬಂದಿದೆ, ಅದರ ಗಮ್ಯಸ್ಥಾನ ಸಾರ್ವಜನಿಕ ವಿಳಾಸ, ಮತ್ತು ರೂಟಿಂಗ್ ಕೋಷ್ಟಕ ಅದನ್ನು ಅದೇ ಹೊರಗಿನ ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ಮತ್ತೆ ಇಂಟರ್ನೆಟ್‌ನತ್ತ ಕಳುಹಿಸುತ್ತದೆ. ಒಂದು ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ ಒಳಬಂದು ಹೊರಹೋಗುವ ಸಂಚಾರವನ್ನು ASA ಅನುಮತಿಸದಿದ್ದರೆ ಬಿಟ್ಟುಬಿಡಲಾಗುತ್ತದೆ, ಮತ್ತು same-security-traffic permit intra-interface ಅದನ್ನೇ ಮಾಡುತ್ತದೆ. ಅದಿಲ್ಲದೆ ಸಂಪರ್ಕವು ರೂಟಿಂಗ್ ಸಮಸ್ಯೆಯಂತೆ ಕಾಣುವ ರೀತಿಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ, ಆದರೆ ಅದು ಅಲ್ಲ.

ಆ ಸೆಟ್ಟಿಂಗ್ ಜಾಗತಿಕವಾಗಿದೆ. ಅದು ಅಗತ್ಯವಿರುವ ಪ್ರತಿ ಹರಿವಿಗೂ ಹೇರ್ಪಿನಿಂಗ್ ಅನ್ನು ಅನುಮತಿಸುತ್ತದೆ, ಈ ಪಾಲುದಾರ ಹೋಸ್ಟ್‌ಗೆ ಮಾತ್ರವಲ್ಲ, ಆದ್ದರಿಂದ ಅದು ವೇಗದ ಪರೀಕ್ಷೆಗಲ್ಲ, ಪರಿಶೀಲಿತ ಬದಲಾವಣೆಗೆ ಸೇರುತ್ತದೆ.

ಗಮ್ಯಸ್ಥಾನ-ಸೀಮಿತ PAT ಐಚ್ಛಿಕವಲ್ಲದ ಕಾರಣ

ಡಿಕ್ರಿಪ್ಟ್ ಆದ ಪ್ಯಾಕೆಟ್‌ನ ಮೂಲ ವಿಳಾಸ ಇನ್ನೂ ಕ್ಲೈಂಟ್‌ನ VPN ವಿಳಾಸವೇ, ಸಾಮಾನ್ಯವಾಗಿ 10.77.0.0/24 ನಂತಹ ಪೂಲ್‌ನಿಂದ. ಆ ವಿಳಾಸಕ್ಕೆ ಸಾರ್ವಜನಿಕ ಇಂಟರ್ನೆಟ್‌ನಲ್ಲಿ ರೂಟ್ ಇಲ್ಲ, ಆದ್ದರಿಂದ ಪಾಲುದಾರ ಎಂದಿಗೂ ಉತ್ತರಿಸುವುದಿಲ್ಲ ಅಥವಾ ಎಲ್ಲಿಗೂ ಉತ್ತರಿಸುವುದಿಲ್ಲ.

ಅನುವಾದವು ಮೂಲವನ್ನು ಸರಿಪಡಿಸುತ್ತದೆ ಮತ್ತು ಗಮ್ಯಸ್ಥಾನವನ್ನು ಅಸ್ಪೃಶ್ಯವಾಗಿ ಬಿಡುತ್ತದೆ. ಆಬ್ಜೆಕ್ಟ್‌ಗಳು ಈಗಾಗಲೇ ಬೇರೆಡೆ ವ್ಯಾಖ್ಯಾನಿಸಲ್ಪಟ್ಟಿರುವುದರಿಂದ, ಈ ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಸೀಮಿತವಾದ ಹಸ್ತಚಾಲಿತ ನಿಯಮವು ಈ ರೂಪವನ್ನು ಹೊಂದಿದೆ:

same-security-traffic permit intra-interface

object network RA_POOL
 subnet 10.77.0.0 255.255.255.0
object network PARTNER_HOST
 host 203.0.113.20

nat (outside,outside) source dynamic RA_POOL interface destination static PARTNER_HOST PARTNER_HOST

destination static ಭಾಗ ಮುಖ್ಯ. ಅದನ್ನು ಬಿಟ್ಟರೆ ನಿಯಮವು ಉದ್ದೇಶಿಸಿದ್ದಕ್ಕಿಂತ ಹೆಚ್ಚು ಸಂಚಾರಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗಬಹುದಾದ ವಿಶಾಲ ಅನುವಾದವಾಗುತ್ತದೆ, ಮತ್ತು ಕ್ರಮದಲ್ಲಿ ಹಿಂದಿನ ವಿಶಾಲ identity ನಿಯಮವು ಇದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಸೋಲಿಸಬಹುದು. ನಿಮ್ಮ ನಿಯಮವೇ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ ಎಂದು ಭಾವಿಸುವ ಮೊದಲು show nat detail ಮತ್ತು ವಿಭಾಗಗಳ ಕ್ರಮವನ್ನು ಪರಿಶೀಲಿಸಿ.

ಇಂಟರ್ಫೇಸ್ PAT ಎಂದರೆ ಪಾಲುದಾರನು ASA ನ ಇಂಟರ್ಫೇಸ್ ವಿಳಾಸವನ್ನು ನೋಡುತ್ತಾನೆ, ಅದು ಮೇಲ್ಭಾಗದಲ್ಲಿ ಮತ್ತೆ ಅನುವಾದವಾಗಬಹುದು. ಒಪ್ಪಂದವು ವಿಳಾಸವನ್ನು ಹೆಸರಿಸಿದರೆ, ಅದನ್ನು ಒಂದು ಹಾಪ್‌ನಲ್ಲ, ಆರಂಭದಿಂದ ಕೊನೆಯವರೆಗೆ ದೃಢೀಕರಿಸಿ.

ಸರಿಯಾದ ಪರೀಕ್ಷಾ ಗಮ್ಯಸ್ಥಾನದಿಂದ ಸಾಬೀತುಪಡಿಸಿ

ಸಾಮಾನ್ಯ what-is-my-ip ಪುಟವನ್ನಲ್ಲ, ಪಾಲುದಾರ ಹೋಸ್ಟ್ ಅನ್ನೇ ಬಳಸಿ. ಆ ಪುಟ ಬಹುತೇಕ ಖಚಿತವಾಗಿ split ಪಟ್ಟಿಯ ಹೊರಗಿದೆ, ಆದ್ದರಿಂದ ಅದು ನಿಮ್ಮ ಸ್ಥಳೀಯ ಇಂಟರ್ನೆಟ್ ವಿಳಾಸವನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ ಮತ್ತು ಈ ಮಾರ್ಗದ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಪಾಲುದಾರ ಸೇವೆಗೆ ಹೊಸ ಸಂಪರ್ಕ ತೆರೆದು ಅವರು ಯಾವ ಮೂಲವನ್ನು ಗಮನಿಸಿದರು ಎಂದು ಕೇಳಿ, ಅಥವಾ packet-tracer input outside tcp 10.77.0.10 12345 203.0.113.20 443 detailed ಚಲಾಯಿಸಿ NAT ಮತ್ತು ರೂಟಿಂಗ್ ಹಂತಗಳನ್ನು ಸಾಲಿನಿಂದ ಸಾಲಿಗೆ ಓದಿ. ಕ್ಲೈಂಟ್‌ನಿಂದ traceroute ದುರ್ಬಲ ಪರಿಶೀಲನೆ, ಏಕೆಂದರೆ ಅದು ಈಗಾಗಲೇ ಸಂಭವಿಸಿದ ಮಾರ್ಗವನ್ನು ತೋರಿಸುತ್ತದೆ, ಅದನ್ನು ಆಯ್ಕೆ ಮಾಡಿದ ನೀತಿಯನ್ನಲ್ಲ.

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

ಈ ವಿನ್ಯಾಸದ ಕೆಲಸ ಮಾಡುವ ಆವೃತ್ತಿ ಚಿಕ್ಕದು: split ACL ನಲ್ಲಿ ಒಂದು ಹೋಸ್ಟ್, ಹೇರ್ಪಿನ್ ಅನುಮತಿ, ಗಮ್ಯಸ್ಥಾನ-ಸೀಮಿತ ಒಂದು PAT ನಿಯಮ. ಕಥೆಯಲ್ಲಿ ಉಳಿದದ್ದೆಲ್ಲ ಪುರಾಣ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು