ಒಂದು WAN ಇಂಟರ್ಫೇಸ್ ಸೈಟ್-ಟು-ಸೈಟ್ ಮತ್ತು ರಿಮೋಟ್ VPN ಎರಡನ್ನೂ ಸೇವೆ ಮಾಡಬಲ್ಲದೇ?

ಒಂದು ಸಾರ್ವಜನಿಕ ವಿಳಾಸವು ಒಂದೇ ಸಮಯದಲ್ಲಿ ಶಾಖಾ ಸುರಂಗ ಮತ್ತು ಸುತ್ತಾಡುವ ಬಳಕೆದಾರರ ಪೂಲ್ ಎರಡನ್ನೂ ಸೇವೆ ಮಾಡಬಲ್ಲದು. ಆದರೆ ಅದು ಒಂದೇ ಸಾಮಾನ್ಯ ಪ್ರವೇಶ ನಿಯಮವನ್ನು ಸೇವೆ ಮಾಡಲಾರದು. ಶಾಖೆಯ ಪೀರ್ ಮತ್ತು ಸುತ್ತಾಡುವ ಬಳಕೆದಾರ ಭಿನ್ನರು — ಅವರು ತಾವು ಯಾರೆಂದು ಹೇಳಿಕೊಳ್ಳುವುದು, ಆ ಸಾಕ್ಷ್ಯವನ್ನು ಹೇಗೆ ಪರಿಶೀಲಿಸಲಾಗುತ್ತದೆ, ಅವರು ಯಾವ ವಿಳಾಸಗಳನ್ನು ಪಡೆಯುತ್ತಾರೆ ಮತ್ತು ಯಾವ ಪ್ರಿಫಿಕ್ಸ್ಗಳು ಅವರಿಗೆ ಉತ್ತರಿಸಬಹುದು ಎಂಬುದರಲ್ಲಿ. ಹೊರಗಿನ ವಿಳಾಸವನ್ನು ಗುರುತು ಎಂದಲ್ಲದೆ ಸಾಗಣೆ ವಿವರ ಎಂದು ಪರಿಗಣಿಸಿದಾಗ ವಿನ್ಯಾಸ ಬಹಳ ಸರಳವಾಗುತ್ತದೆ.

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

ಯಾವುದೇ ಸಂರಚನೆಗೆ ಮೊದಲು ಎರಡು ದಾಖಲೆಗಳು

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

ಸುತ್ತಾಡುವ ದಾಖಲೆ ಹೆಚ್ಚು ಅಗಲವಾದದ್ದು ಮತ್ತು ಹೆಚ್ಚು ವೈಯಕ್ತಿಕವಾದದ್ದು. ಅದು ಕ್ಲೈಂಟ್ ಪ್ರೋಟೋಕಾಲ್ ಮತ್ತು ಪೋರ್ಟ್, ಬಳಕೆದಾರ ಅಥವಾ ಸಾಧನವು ಹೇಗೆ ದೃಢೀಕರಿಸುತ್ತದೆ, ಸಂಪರ್ಕದ ವೇಳೆ ನೀಡುವ ವಿಳಾಸ ಪೂಲ್, ಆ ಪೂಲ್ ತಲುಪಬಹುದಾದ ಸಂಪನ್ಮೂಲಗಳು, ಸ್ಪ್ಲಿಟ್ ಸುರಂಗದ ಪ್ರಿಫಿಕ್ಸ್ಗಳು, ಕ್ಲೈಂಟ್ಗೆ ಕಳುಹಿಸುವ DNS ಸರ್ವರ್ಗಳು, ಮತ್ತು ಯಾವುದೇ ಎರಡನೇ ಅಂಶವನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ. ಪ್ರತಿ ಕ್ಷೇತ್ರವು ಒಂದು ಗೇಟ್ವೇ ಬಗ್ಗೆ ಅಲ್ಲ, ತಿಳಿಯದ ಸಂಖ್ಯೆಯ ಬಳಕೆದಾರರ ಬಗ್ಗೆ ಇರುವ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ.

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

ಪೀರ್ ಹೊಂದಾಣಿಕೆ ಮತ್ತು ದೃಢೀಕರಣ ಎಲ್ಲಿ ಬೇರೆಯಾಗುತ್ತವೆ

IOS XE ನಲ್ಲಿ IKEv2 ಪ್ರೊಫೈಲ್ ಮಾತುಕತೆ ನಡೆಸಲಾಗದ ನಿಯತಾಂಕಗಳನ್ನು ಮತ್ತು ಪೀರ್ ಆಯ್ಕೆಗೆ ಬಳಸುವ ಷರತ್ತುಗಳನ್ನು ಹೊತ್ತೊಯ್ಯುತ್ತದೆ. ಅಂದರೆ ಶಾಖೆಯ ಪಕ್ಷ ಮತ್ತು ಸುತ್ತಾಡುವ ಪಕ್ಷ ಎರಡೂ ತಮ್ಮದೇ ಪ್ರೊಫೈಲ್ ಬೇಕು, ಅವು ಒಂದೇ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಕೊನೆಗೊಂಡರೂ ಮತ್ತು ಒಂದೇ ಕ್ರಿಪ್ಟೊ PKI ಹಂಚಿಕೊಂಡರೂ. Cisco ತನ್ನ IOS XE 17 ಗಾಗಿ IKEv2 ಸಂರಚನಾ ಮಾರ್ಗದರ್ಶಿಯಲ್ಲಿ.

ಶಾಖಾ ಪ್ರೊಫೈಲ್ ಸಾಮಾನ್ಯವಾಗಿ ಸಂಕುಚಿತ ಗುರುತಿಗೆ ಹೊಂದುತ್ತದೆ: ದೂರದ ವಿಳಾಸ, FQDN, ಅಥವಾ ಪ್ರಮಾಣಪತ್ರ ವಿಷಯ. match identity remote address 198.51.100.10 255.255.255.255 ನಂತಹ ಒಂದು ಸಾಲು ಒಬ್ಬ ಪೀರ್ ಅನ್ನು ಪಿನ್ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಪ್ರತಿ ಸೈಟ್ಗೆ ಸಂಗ್ರಹಿಸಿದ ಕೀಲಿಯೊಂದಿಗೆ authentication remote pre-share ಸಾಕು. ಪೀರ್ ಪಟ್ಟಿ ಅನುಮತಿಸುವಷ್ಟು ಹೊಂದಾಣಿಕೆಯನ್ನು ನಿರ್ದಿಷ್ಟವಾಗಿ ಇರಿಸಿ, ಏಕೆಂದರೆ ಆಯ್ಕೆ ಕ್ರಮದಲ್ಲಿ ಮೇಲಿರುವ ಅತಿವ್ಯಾಪ್ತ ವೈಲ್ಡ್ಕಾರ್ಡ್ ಶಾಖೆಯ ಸಂಚಾರವನ್ನು ತಪ್ಪು ಪ್ರೊಫೈಲ್ಗೆ ಎಳೆಯಬಹುದು.

ಸುತ್ತಾಡುವ ಪ್ರೊಫೈಲ್ ವಿಳಾಸವನ್ನು ಪಿನ್ ಮಾಡಲಾರದು, ಆದ್ದರಿಂದ ಅದು ಗುಂಪು, key-id, ಅಥವಾ ಪ್ರಮಾಣಪತ್ರ ಕ್ಷೇತ್ರಕ್ಕೆ ಹೊಂದುತ್ತದೆ, ನಂತರ ನಿಜವಾದ ಬಳಕೆದಾರ ಪರಿಶೀಲನೆಯನ್ನು AAA ಗೆ ಅಥವಾ ಪ್ರೊಫೈಲ್ಗೆ ಜೋಡಿಸಿದ ಅಧಿಕಾರ ನೀತಿಗೆ ಒಪ್ಪಿಸುತ್ತದೆ. ಈ ಪ್ರತ್ಯೇಕತೆ ಮುಖ್ಯ: ಪೀರ್ ದೃಢೀಕರಣವು ಕ್ಲೈಂಟ್ಗೆ ಸುರಂಗ ನಿರ್ಮಿಸಲು ಅನುಮತಿ ಇದೆಯೇ ಎಂದು ಉತ್ತರಿಸುತ್ತದೆ, ಮತ್ತು ಬಳಕೆದಾರ-ವಾರು ಅಧಿಕಾರವು ಅವನಿಗೆ ಯಾವ ಪೂಲ್ ಮತ್ತು ಯಾವ ಸಂಪನ್ಮೂಲಗಳು ಸಿಗುತ್ತವೆ ಎಂದು ಉತ್ತರಿಸುತ್ತದೆ. ಶಾಖೆಯ ಕೀಲಿಯನ್ನು ಸಾರ್ವತ್ರಿಕ ಲಾಗಿನ್ ಆಗಿ ಬಳಸುವುದು ಎರಡನೇ ಉತ್ತರವನ್ನು ಬಿಸಾಡುತ್ತದೆ.

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

ಪ್ರವೇಶ ಮತ್ತು ತಲುಪುವಿಕೆ ಬೇರೆ ಬೇರೆ ಸಮಸ್ಯೆಗಳು. ಯಶಸ್ವಿ IKE ಮತ್ತು IPsec ವಿನಿಮಯವು ಎರಡೂ ಪಕ್ಷಗಳು ಕೀಲಿಗಳಲ್ಲಿ ಒಪ್ಪಿದ್ದಾರೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ; ಅದು ಕ್ಲೈಂಟ್ ಪಡೆದ ಪೂಲ್ಗೆ ಮಾರ್ಗವನ್ನು ಸೃಷ್ಟಿಸುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ ರಿಮೋಟ್-ಆಕ್ಸೆಸ್ ಪೂಲ್ಗಳಿಗೆ ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಬೇಕು — ಸುರಂಗದ ಇಂಟರ್ಫೇಸ್ ಕಡೆಗಿನ ಸ್ಥಿರ ಮಾರ್ಗ ಅಥವಾ ಪೂಲ್ ಸಾರಾಂಶವನ್ನು ಸೇರಿಸುವ ರೂಟಿಂಗ್ ಪ್ರೋಟೋಕಾಲ್. ಶಾಖೆಯ ಪ್ರಿಫಿಕ್ಸ್ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಸೈಟ್ನ ಉಳಿದ ಭಾಗಕ್ಕೆ ಸೇವೆ ಮಾಡುವ ಅದೇ ರೂಟಿಂಗ್ ಪ್ರಕ್ರಿಯೆಯಿಂದ ಬರುತ್ತವೆ.

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

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

ಅಡ್ಡಾದಿಡ್ಡಿ ನೀತಿಯನ್ನು ಬಯಲು ಮಾಡುವ ಸ್ವೀಕೃತಿ ಪ್ರಕರಣಗಳು

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

ನಂತರ ಸಂರಚನೆಯನ್ನಲ್ಲ, ಡೇಟಾ ಪ್ಲೇನ್ ಅನ್ನು ದೃಢೀಕರಿಸಿ. show crypto ikev2 sa ಮತ್ತು show crypto ipsec sa ಪ್ರತಿ ಹರಿವನ್ನು ಯಾವ ಪ್ರೊಫೈಲ್ ಮತ್ತು ಯಾವ ಸೆಲೆಕ್ಟರ್ಗಳು ಹೊತ್ತವೆ ಎಂದು ಹೇಳುತ್ತವೆ, ಆದರೆ show ip nat translations ಮತ್ತು ಸುರಂಗ ಕೌಂಟರ್ಗಳು ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಮತ್ತು ವಿನಾಯಿತಿ ನಿಜವಾಗಿ ಹೊಂದಿದವೇ ಎಂದು ತೋರಿಸುತ್ತವೆ. ಸುರಂಗದ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ tracer ಅಥವಾ ಪ್ಯಾಕೆಟ್ ಸೆರೆಹಿಡಿಯುವಿಕೆ ಚಕ್ರವನ್ನು ಮುಚ್ಚುತ್ತದೆ.

ಪ್ರತಿ ಫಲಿತಾಂಶದ ಪಕ್ಕದಲ್ಲಿ ಗಮನಿಸಿದ ಗುರುತು, ಪೂಲ್ ವಿಳಾಸ ಮತ್ತು ಆಯ್ಕೆಮಾಡಿದ ನೀತಿಯನ್ನು ಬರೆಯಿರಿ. ಪ್ರತಿ ಪ್ರಕರಣವು ನಿಖರವಾಗಿ ಒಂದು ದಾಖಲೆಗೆ ಹೊಂದಿಕೆಯಾದಾಗ ಮತ್ತು ಯಾವುದೇ ಪ್ರಕರಣಕ್ಕೆ ಉತ್ತೀರ್ಣರಾಗಲು ತಾತ್ಕಾಲಿಕ ವಿನಾಯಿತಿ ಬೇಕಾಗದಿದ್ದಾಗ ಸುತ್ತು ಮುಗಿಯುತ್ತದೆ.