Anypoint VPN ಅಥವಾ Transit Gateway NAT: ಅನುವಾದ ಎಲ್ಲಿ ನಡೆಯುತ್ತದೆ

NAT ಅಗತ್ಯವು ಬದಲಾಗುವ ವಿಳಾಸಗಳನ್ನು ಮತ್ತು ಅವನ್ನು ಬದಲಿಸಲು ಅನುಮತಿ ಇರುವ ಘಟಕವನ್ನು ಹೆಸರಿಸುವವರೆಗೆ ಅದು ಅಗತ್ಯವಲ್ಲ. MuleSoft ಸಂಪರ್ಕದಲ್ಲಿ ಆ ನಿರ್ಣಯಕ್ಕೆ ಮೂರು ಒಳಹರಿವುಗಳಿವೆ: ಬ್ಯಾಕೆಂಡ್‌ಗೆ ಅನೇಕ-ಇಂದ-ಒಂದು ಪೋರ್ಟ್ ಅನುವಾದ ಬೇಕೇ ಅಥವಾ ಒಂದು-ಇಂದ-ಒಂದು ಪ್ರೀಫಿಕ್ಸ್ ಅಲಿಯಾಸ್ ಬೇಕೇ, ನೀವು ನಿಜವಾಗಿ ಹೊಂದಿರುವ AWS ಸಂಪರ್ಕವು ಆ ಮ್ಯಾಪಿಂಗ್ ಮಾಡಬಹುದೇ, ಮತ್ತು ಇಡೀ ಮಾರ್ಗವು ಮಾರಾಟಗಾರ ಬೆಂಬಲಿಸುವ ಸಂಯೋಜನೆಯೊಳಗೆ ಉಳಿಯುತ್ತದೆಯೇ. ಇವು ತಪ್ಪಾದರೆ, ಕೆಲಸ ಮಾಡುವ ಆದರೆ ಪರಿಶೀಲನೆಯಲ್ಲಿ ವಿಫಲವಾಗುವ ಪ್ರಯೋಗಾಲಯವನ್ನು ನೀವು ಕಟ್ಟುತ್ತೀರಿ.

ಒಂದೇ ಸ್ಥಿರ ಅಂಶ ಎಂದರೆ Anypoint VPN ಸ್ವತಃ ಅನುವಾದ ಸಾಧನವಲ್ಲ. CloudHub 2.0 ದಾಖಲೆಗಳು ಅಲ್ಲಿ NAT ಅನ್ನು ಬೆಂಬಲಿತವಲ್ಲ ಎಂದು ಪಟ್ಟಿ ಮಾಡುತ್ತವೆ, ಆದ್ದರಿಂದ ಸುರಂಗವು ನಿಮ್ಮ ಕೆಲಸಗಾರರ ವಿಳಾಸಗಳನ್ನು ಮರೆಮಾಡುತ್ತದೆ ಎಂದು ಊಹಿಸುವ ಯಾವುದೇ ವಿನ್ಯಾಸ ಈಗಾಗಲೇ ಮುರಿದಿದೆ.

ಅನುವಾದ ಏನು ಮಾಡಬೇಕು ಎಂದು ನಿರ್ಧರಿಸಿ

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

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

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

AWS ನಿಮಗಾಗಿ ಮ್ಯಾಪಿಂಗ್ ಮಾಡಬಹುದೇ ಎಂದು ಪರಿಶೀಲಿಸಿ

AWS ಈಗ Transit Gateway ಮತ್ತು Cloud WAN ಸಂಪರ್ಕಗಳಲ್ಲಿ ನಿರ್ವಹಿತ ಒಂದು-ಇಂದ-ಒಂದು NAT ಅನ್ನು ದಾಖಲಿಸುತ್ತದೆ, ಇದನ್ನು 2026ರ ಅಕ್ಟೋಬರ್ ಅಂತ್ಯದಲ್ಲಿ ಘೋಷಿಸಲಾಯಿತು, ಆದ್ದರಿಂದ ಟ್ರಾನ್ಸಿಟ್ ಗೇಟ್‌ವೇ ಎಂದಿಗೂ ಅನುವಾದಿಸಲಾರದು ಎಂಬ ಹಳೆಯ ಸಾಮಾನ್ಯ ಹೇಳಿಕೆ ಬಳಕೆಯಲ್ಲಿಲ್ಲ. Transit Gateway NAT ದಾಖಲೆ ಸ್ಥಿತಿ ಇಲ್ಲದ IPv4 ಪ್ರೀಫಿಕ್ಸ್ ಮ್ಯಾಪಿಂಗ್ ವಿವರಿಸುತ್ತದೆ: ಮೂಲ ಮತ್ತು ಅನುವಾದಿತ ಪ್ರೀಫಿಕ್ಸ್‌ಗಳು ಒಂದೇ ಉದ್ದವನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತವೆ, ಮತ್ತು ಹೋಸ್ಟ್ ಬಿಟ್‌ಗಳು ಹಾಗೂ ಸಾಗಣೆ ಪೋರ್ಟ್‌ಗಳು ಅನುವಾದವನ್ನು ದಾಟುತ್ತವೆ. ಒಳಬರುವ ಮತ್ತು ಹೊರಹೋಗುವ ದಿಕ್ಕುಗಳನ್ನು ಪ್ರತ್ಯೇಕ ವಿನ್ಯಾಸ ನಿರ್ಣಯಗಳಾಗಿ ಓದಿ, ಏಕೆಂದರೆ ಅವು ಪ್ರತ್ಯೇಕವಾಗಿ ಸಂರಚಿಸಲ್ಪಡುತ್ತವೆ ಮತ್ತು ಒಂದು ಸಿದ್ಧವಿರಬಹುದು ಇನ್ನೊಂದು ಇಲ್ಲದಿರಬಹುದು. ಆ ವಿವರಣೆಯಲ್ಲಿ ಯಾವುದೂ ಹರಿವುವಾರು ಸ್ಥಿತಿಯನ್ನು ಸೂಚಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಮ್ಯಾಪಿಂಗ್ ನಿಮಗಾಗಿ ಸಂಪರ್ಕಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುತ್ತದೆ ಎಂದು ನಿರೀಕ್ಷಿಸಬೇಡಿ.

ಇದರರ್ಥ 10.80.0.0/16 ಅನ್ನು 172.28.0.0/16 ಗೆ ಮ್ಯಾಪ್ ಮಾಡಿದರೆ 10.80.10.23 172.28.10.23 ಆಗುತ್ತದೆ. ಇದು /16 ಅನ್ನು ಒಂದೇ ವಿಳಾಸಕ್ಕೆ ಮಡಚುವುದಿಲ್ಲ ಮತ್ತು PAT ಅಗತ್ಯವನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ. ಇದು ಆಯ್ದ ಸಂಪರ್ಕ ಪ್ರಕಾರಗಳನ್ನೂ ಒಳಗೊಳ್ಳುತ್ತದೆ, ಅವುಗಳಲ್ಲಿ VPC ಮತ್ತು Site-to-Site VPN ಸೇರಿವೆ, ಆದರೆ Client VPN ಸಂಪರ್ಕಗಳಲ್ಲ, ಮತ್ತು ಸಂರಚನೆ Anypoint ಬದಿಯಲ್ಲಿ ಅಲ್ಲ, ಟ್ರಾನ್ಸಿಟ್ ಗೇಟ್‌ವೇ ಮಾಲೀಕರ ಬಳಿ ಇರುತ್ತದೆ.

ಈ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಇನ್ನೊಂದು ಸಂಭಾವ್ಯ ನಿಯಂತ್ರಣ ಬಿಂದುವಾಗಿ ಪರಿಗಣಿಸಿ, ನಿಮ್ಮ ನಿಯೋಜನೆ ಅದನ್ನು ಬಳಸಬಹುದು ಎಂಬ ಸಾಕ್ಷಿಯಾಗಿ ಅಲ್ಲ. CloudHub 2.0 ಗ್ರಾಹಕರ ಸ್ವಂತ AWS ಖಾತೆಯಲ್ಲಿನ ಟ್ರಾನ್ಸಿಟ್ ಗೇಟ್‌ವೇಗೆ ಖಾಸಗಿ-ಸ್ಥಳ ಸಂಪರ್ಕಗಳನ್ನು ಪ್ರಾದೇಶಿಕ ಮತ್ತು ಹಕ್ಕು ಷರತ್ತುಗಳೊಂದಿಗೆ ದಾಖಲಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಹೊಸ ಆಯ್ಕೆಯ ಸುತ್ತ ವಿನ್ಯಾಸ ಮಾಡುವ ಮೊದಲು ನಿಜವಾದ ಸಂಪರ್ಕ ಪ್ರಕಾರ, ಅದರ ಮಾಲೀಕ ಮತ್ತು ಮಾರಾಟಗಾರರ ಬೆಂಬಲ ನಿಲುವನ್ನು ಖಚಿತಪಡಿಸಿ.

ಮಾರ್ಗವನ್ನು ಬೆಂಬಲಿತ ಗಡಿಯೊಳಗೆ ಇರಿಸಿ

ಫೈರ್‌ವಾಲ್ ಅನುವಾದಕಕ್ಕೆ, ಕೆಲಸ ಮಾಡುವ ಸುರಂಗಕ್ಕೆ ಸಾಮಾನ್ಯ NAT ನಿಯಮವನ್ನು ಅಂಟಿಸುವ ಬದಲು ಆ ಉತ್ಪನ್ನದ ಬೆಂಬಲಿತ VPN, ಅನುವಾದ ಮತ್ತು ರೂಟಿಂಗ್ ಮಾದರಿಯನ್ನು ಬಳಸಿ. ಬ್ಯಾಕೆಂಡ್‌ನ ಉತ್ತರವು ಅದೇ ಅನುವಾದ ಘಟಕದ ಮೂಲಕ ಹಿಂತಿರುಗಬೇಕು, ಮತ್ತು ಆರೋಗ್ಯಕರ ಹೊರಹೋಗುವ ಸುರಂಗವು ಆ ಹಿಂತಿರುಗುವ ಮಾರ್ಗದ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.

ಟ್ರಾನ್ಸಿಟ್ ಗೇಟ್‌ವೇ ಮಾರ್ಗಕ್ಕೆ, ಖಾಸಗಿ-ಸ್ಥಳ ಸಂಪರ್ಕ, ಸಂಬಂಧಿತ ಮಾರ್ಗ ಕೋಷ್ಟಕಗಳು, ಆನ್-ಪ್ರಿಮೈಸ್ ಸಂಪರ್ಕ ಮತ್ತು ಗ್ರಾಹಕರು ನಿಜವಾಗಿ ಸಂರಚಿಸಬಹುದಾದ ಭಾಗಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡಿ. ಇದು ಬೇರೆ ಸಂಪರ್ಕ ವಾಸ್ತುಶಿಲ್ಪ, ಇರುವ Anypoint VPN ಸಂಪರ್ಕಕ್ಕೆ ಬಿಗಿಗೊಳಿಸಿದ NAT ಚೆಕ್‌ಬಾಕ್ಸ್ ಅಲ್ಲ, ಮತ್ತು ಬೆಂಬಲ ಗಡಿ ಅದರೊಂದಿಗೆ ಚಲಿಸುತ್ತದೆ.

ಮೂರು ಆಯ್ಕೆಗಳನ್ನು ಒಂದೇ ಕೋಷ್ಟಕದಲ್ಲಿ ಹೋಲಿಸಿ

ಹೆಚ್ಚಿನ ತಂಡಗಳು ಕೇವಲ ಎರಡು ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸಬೇಕು: ಅನೇಕ-ಇಂದ-ಒಂದು ಅಥವಾ ಒಂದು-ಇಂದ-ಒಂದು, ಮತ್ತು ಸಂಪರ್ಕದ ಮಾಲೀಕರು ಯಾರು. ಕೆಳಗಿನ ಕೋಷ್ಟಕ ಆ ಉತ್ತರಗಳನ್ನು ಆರಂಭಿಕ ಆಯ್ಕೆಯಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ.

ಮೂರನೇ ಕಾಲಂ ಅನ್ನು ನಂತರದ ಯೋಚನೆಯಾಗಿ ಅಲ್ಲ, ಪರಿಶೀಲನೆಯ ಪ್ರಶ್ನೆಯಾಗಿ ಓದಿ. ಕಾಗದದ ಮೇಲೆ ಅನುಮತಿಸಲಾದ ಆದರೆ ನಿಮ್ಮ ಮಾಲೀಕತ್ವವಲ್ಲದ ಸಂಪರ್ಕದಲ್ಲಿ ಸಂರಚಿಸಿದ ಪ್ರೀಫಿಕ್ಸ್ ನಕ್ಷೆ ಇನ್ನೂ ತಡೆಹಿಡಿಯಲಾದ ಯೋಜನೆ, ಮತ್ತು ಸಂಚಾರವನ್ನು ದಾಟಿಸಿ ಆದರೆ ಗ್ರಾಹಕವಾರು ಲಾಗಿಂಗ್ ಮುರಿಯುವ PAT ನಿಯಮವು ನಂತರದ ಲೆಕ್ಕಪರಿಶೋಧನೆಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ.

ಭರವಸೆ ನೀಡುವ ಮೊದಲು ಮ್ಯಾಪಿಂಗ್ ಪರಿಶೀಲಿಸಿ

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

ಬ್ಯಾಕೆಂಡ್ ದೃಢೀಕರಣವನ್ನು ಅದರ ಅನುಮತಿ ಪಟ್ಟಿಯನ್ನು ಪೂರೈಸುವ ಯಾವುದೇ ಅನುವಾದಿತ ವಿಳಾಸದಿಂದ ಸ್ವತಂತ್ರವಾಗಿ ಇರಿಸಿ, ಏಕೆಂದರೆ ಮ್ಯಾಪಿಂಗ್ ನೆಟ್‌ವರ್ಕ್ ಕೊಳವೆ ಬಳಕೆ, ಪ್ರವೇಶ ನಿಯಂತ್ರಣ ನಿರ್ಣಯವಲ್ಲ. ಪಾಸ್‌ವರ್ಡ್ ಮರುಹೊಂದಿಕೆ NAT ಪ್ರೀಫಿಕ್ಸ್ ಅನ್ನು ಅವಲಂಬಿಸಿದ ಕ್ಷಣದಿಂದ, ಮುಂದಿನ ಪ್ರತಿ ಶ್ರೇಣಿ ಬದಲಾವಣೆಯೂ ಅಡಚಣೆಯಾಗುತ್ತದೆ.

ಅನುಮೋದನೆಗೆ ಮೊದಲು ಮೂರು ಉತ್ತರಗಳನ್ನು ಬರೆಯಿರಿ: ಅನುವಾದದ ಪ್ರಕಾರ, ಅನುವಾದಕರ ಮಾಲೀಕ, ಮತ್ತು ಅದನ್ನು ಹೊತ್ತೊಯ್ಯುವ ಬೆಂಬಲಿತ ಸಂಪರ್ಕ ಅಥವಾ ಉತ್ಪನ್ನ ಮಾರ್ಗ. ಅವುಗಳಲ್ಲಿ ಯಾವುದಾದರೂ ಇನ್ನೂ ಊಹೆಯಾಗಿದ್ದರೆ, ವಿನ್ಯಾಸವು ಬದಲಾವಣೆ ಕಿಟಕಿಗೆ ಸಿದ್ಧವಿಲ್ಲ.