ಎರಡು ಸೈಟ್ಗಳು, ಒಂದು ಸಬ್ನೆಟ್: ಪ್ರತಿಯೊಂದಕ್ಕೂ ಅಲಿಯಾಸ್ ನೋಟವನ್ನು ನಿರ್ಮಿಸಿ

ಎರಡು ಗ್ರಾಹಕ ಸೈಟ್ಗಳು ಎರಡೂ 192.168.50.0/24 ಬಳಸುತ್ತವೆ, ಮತ್ತು ದೂರದ ಇಂಜಿನಿಯರ್ ಪ್ರತಿಯೊಂದರಲ್ಲೂ ಅದೇ ವಿಳಾಸದಲ್ಲಿರುವ ಮುದ್ರಕವನ್ನು ತಲುಪಬೇಕು. ಯಾವುದೇ ರೂಟಿಂಗ್ ತಂತ್ರವು ಈ ಅಸ್ಪಷ್ಟತೆಯನ್ನು ಒಂಟಿಯಾಗಿ ಪರಿಹರಿಸುವುದಿಲ್ಲ. ಪ್ರತಿಯೊಂದು ಸೈಟ್ಗೂ ಪ್ರತ್ಯೇಕ ವಿಳಾಸ ನೋಟ ಬೇಕು, ಮತ್ತು ಗೇಟ್ವೇ ಏನನ್ನಾದರೂ ಮುಂದೆ ರವಾನಿಸುವ ಮೊದಲು ಆ ನೋಟದಿಂದ ಸೈಟ್ ಆಯ್ಕೆ ಮಾಡಬೇಕು.

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

ಪ್ರತಿ ಸೈಟ್ಗೆ ಒಂದು ಅಲಿಯಾಸ್ ಪೂರ್ವಪ್ರತ್ಯಯ ಆಯ್ಕೆಮಾಡಿ

ಪರಿಸರದಲ್ಲಿ ಬೇರೆ ಯಾರಿಗೂ ಸೇರದ ಪೂರ್ಣ ಅಲಿಯಾಸ್ ಪೂರ್ವಪ್ರತ್ಯಯವನ್ನು ಪ್ರತಿ ಸೈಟ್ಗೆ ನಿಯೋಜಿಸಿ. ಎರಡು ಸೈಟ್ಗಳ ಯೋಜನೆ ಸೈಟ್ A ಯ 192.168.50.0/24 ಅನ್ನು 172.21.10.0/24 ಗೆ ಮತ್ತು ಸೈಟ್ B ಯ ಒಂದೇ ರೀತಿಯ LAN ಅನ್ನು 172.21.20.0/24 ಗೆ ಮ್ಯಾಪ್ ಮಾಡಬಹುದು. ಕ್ಲೌಡ್ VPC ಮತ್ತು ಇತರ VPN ಪೂಲ್ಗಳನ್ನು ಒಳಗೊಂಡಂತೆ ಪ್ರತಿ ಭಾಗವಹಿಸುವ ನೆಟ್ವರ್ಕ್ ವಿರುದ್ಧ ಅಭ್ಯರ್ಥಿಗಳನ್ನು ಪರಿಶೀಲಿಸಿ. ಖಾಸಗಿ ವಿಳಾಸ ಸ್ಥಳವನ್ನು ಪ್ರತಿ ಸಂಸ್ಥೆಯೂ ಹಂಚಿಕೊಳ್ಳುತ್ತದೆ, ಆದ್ದರಿಂದ ಒಂದು ಶ್ರೇಣಿ RFC 1918 ಆಗಿರುವುದು ಅದು ಇಲ್ಲಿ ಮುಕ್ತವಾಗಿದೆ ಎಂದು ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.

ದೂರದ ಬಳಕೆದಾರರಿಗೆ ಮೂಲ ಸಬ್ನೆಟ್ ಅಲ್ಲ, ಅಲಿಯಾಸ್ ಅನ್ನು ಪ್ರಕಟಿಸಿ. ಮೂಲ ಶ್ರೇಣಿ ಸ್ಥಳೀಯ ಸತ್ಯವಾಗಿಯೇ ಉಳಿಯುತ್ತದೆ.

ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಅನುವಾದಿಸಿ

ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಅನುವಾದಿಸಿ. ಗಮ್ಯಸ್ಥಾನ ಮ್ಯಾಪಿಂಗ್ ಅಲಿಯಾಸ್ ವಿಳಾಸವನ್ನು ಮಾಲೀಕ ಸೈಟ್ನಲ್ಲಿ ಮೂಲ ವಿಳಾಸಕ್ಕೆ ಮರುಬರೆಯುತ್ತದೆ. ಮೂಲ ಮ್ಯಾಪಿಂಗ್ ದೂರದ ಕರೆಗಾರನನ್ನು ಇತರ ಸೈಟ್ಗಳು ಪ್ರತ್ಯೇಕಿಸಬಹುದಾದ ಅಲಿಯಾಸ್ಗೆ ಮರುಬರೆಯುತ್ತದೆ.

ಸ್ಥಿರ ಒಂದರಿಂದ-ಒಂದು ಮ್ಯಾಪಿಂಗ್ ನಿರ್ಣಾಯಕವಾಗಿದೆ, ಮತ್ತು ಅದು ಅನುಷ್ಠಾನವನ್ನು ಸ್ಥಿತಿರಹಿತವಾಗಿಸುವುದಿಲ್ಲ. ಹಿಮ್ಮುಖ ಅನುವಾದ ಸಂಪರ್ಕ ಸ್ಥಿತಿಯನ್ನು ಅವಲಂಬಿಸಬಹುದು, ಮತ್ತು ಫೇಲ್ಓವರ್ ಅಥವಾ ಅಸಮ್ಮಿತ ಮಾರ್ಗಗಳು ಅದನ್ನು ನಿರ್ಲಕ್ಷಿಸುವ ಯೋಜನೆಯನ್ನು ಮುರಿಯಬಹುದು. ಪ್ಲಾಟ್ಫಾರ್ಮ್ನ ದಾಖಲೆಗಳು ಇವುಗಳಲ್ಲಿ ಯಾವುದು ಅನ್ವಯಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ.

ನೀತಿ, ಆಯ್ಕೆಗಾರರು ಮತ್ತು ಮಾರ್ಗಗಳು ಅನ್ವಯವಾಗುವ ನಿಖರ ಹಂತವು ನೀತಿ-ಆಧಾರಿತ IPsec, ಮಾರ್ಗ-ಆಧಾರಿತ ಸುರಂಗಗಳು ಮತ್ತು ಇತರ ಉತ್ಪನ್ನಗಳ ನಡುವೆ ಭಿನ್ನವಾಗಿದೆ. ನೀವು ನಡೆಸುವದಕ್ಕಾಗಿ ವಿನ್ಯಾಸ ಮಾಡಿ.

ಯೋಜನೆಯನ್ನು ಓವರ್ಲೇ ಮೂಲಕ ಒಯ್ಯಿರಿ

ಹಬ್ನಲ್ಲಿ ಪ್ರತಿ ಅಲಿಯಾಸ್ ಪೂರ್ವಪ್ರತ್ಯಯವನ್ನು ಅದನ್ನು ಹೊಂದಿರುವ ಸೈಟ್ ಮಾರ್ಗಕ್ಕೆ ನಿಯೋಜಿಸಿ ಮತ್ತು ಕಾರ್ಯಕ್ಕೆ ಬೇಕಾದ ಸಂಚಾರಕ್ಕೆ ಮಾತ್ರ ಅನುಮತಿ ನೀಡಿ. ಮೆಶ್ನಲ್ಲಿ ಪ್ರತಿ ಸಂಬಂಧಿತ ಪೀರ್ ಅದೇ ಪೂರ್ವಪ್ರತ್ಯಯ ಮತ್ತು ನೀತಿ ಜ್ಞಾನವನ್ನು ಬೇಕಾಗುತ್ತದೆ. ಸುರಂಗಗಳನ್ನು ಸೇರಿಸುವುದು ಅಸ್ಪಷ್ಟ ವಿಳಾಸೀಕರಣವನ್ನು ತಾನೇ ಸರಿಪಡಿಸುವುದಿಲ್ಲ.

ಇಡೀ ಸಬ್ನೆಟ್ ಪ್ರಕಟಣೆಯು ಒಂದು ಸೇವೆಯ ಪ್ರಕಟಣೆಗಿಂತ ವಿಶಾಲವಾಗಿದೆ. ಕೆಲವೇ ಯಂತ್ರಗಳು ಅಥವಾ ಪೋರ್ಟ್ಗಳು ಮಾತ್ರ ಬೇಕಾದರೆ, ಪ್ರವೇಶ ನಿಯಮಗಳನ್ನು ಮ್ಯಾಪಿಂಗ್ಗಿಂತ ಸಂಕುಚಿತವಾಗಿ ಇರಿಸಿ.

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

ಪ್ರತಿ ಕರೆಗಾರ ಕಾಣುವ ಹೆಸರುಗಳನ್ನು ಸರಿಪಡಿಸಿ

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

ಮೊದಲ ನಿರ್ವಹಣಾ ಕಿಟಕಿಗೆ ಮೊದಲು ಪ್ರತಿ ಸೈಟ್ಗೆ DNS ನೋಟಗಳನ್ನು ಪರಿಶೀಲಿಸಿ. ಮೂಲ ಸಬ್ನೆಟ್ಗೆ ಪರಿಹರಿಸುವ ಹೆಸರು ಕರೆಗಾರನನ್ನು ಯೋಜನೆ ತೆಗೆದುಹಾಕಬೇಕಿದ್ದ ಅಸ್ಪಷ್ಟತೆಗೆ ಮರಳಿ ಕಳುಹಿಸುತ್ತದೆ.

ಪ್ರತಿ ಸೈಟ್ಗೆ ದಾಖಲಿಸಿ ಮತ್ತು ಪರಿಶೀಲಿಸಿ

ನಿಜವಾದ ಕರೆಗಾರನಿಂದ ಪ್ರತಿ ಸೈಟ್ ಅನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಸ್ವೀಕರಿಸಿ ಮತ್ತು ಯಾವ ಯಂತ್ರ ಉತ್ತರಿಸಿತು ಎಂದು ದೃಢೀಕರಿಸಿ. ಮೂಲ ವಿಳಾಸ, ಅಲಿಯಾಸ್, ಮಾಲೀಕ ಗೇಟ್ವೇ ಮತ್ತು ಅನುಮತಿಸಲಾದ ಸೇವೆಯನ್ನು ಒಟ್ಟಿಗೆ ದಾಖಲಿಸಿ.

ಮೂರನೇ ಸೈಟ್ ಅದೇ ಡಿಫಾಲ್ಟ್ LAN ನೊಂದಿಗೆ ಬಂದಾಗ ಈ ದಾಖಲೆಯೇ ವ್ಯತ್ಯಾಸವನ್ನು ಕಾಪಾಡುತ್ತದೆ. ನೀತಿ-ಆಧಾರಿತ IPsec NAT ಮಾರ್ಗದರ್ಶಿ ಒಂದು ನಿರ್ದಿಷ್ಟ ಅನುವಾದ ಮಾದರಿಯನ್ನು ದಾಖಲಿಸುತ್ತದೆ; ಅದು ಪ್ರತಿ ಪ್ಲಾಟ್ಫಾರ್ಮ್ಗೂ ಒಪ್ಪಂದವಲ್ಲ.