ಮೂಲ/ಗಮ್ಯ ಪರಿಶೀಲನೆ ಒಂದು ದ್ವಾರ, ಇಡೀ VPN ಮಾರ್ಗವಲ್ಲ

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

ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ಎರಡು ಪರೀಕ್ಷೆಗಳನ್ನು ಬೇರ್ಪಡಿಸಿ

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

ಗೇಟ್ವೇಗೆ ಕೆಲಸ ಮಾಡುವ ping ಮತ್ತು ಅದರಾಚೆ ಇರುವ ಹೋಸ್ಟ್ಗೆ ವಿಫಲವಾಗುವ ping ಮಧ್ಯಂತರ ಸಮಸ್ಯೆ ಅಲ್ಲ. ಫಾರ್ವರ್ಡ್ ಮಾಡಬಹುದೆಂದು ಹೇಳದ ಇನ್ಸ್ಟಾನ್ಸ್ನ ನಿರೀಕ್ಷಿತ ನಡವಳಿಕೆ ಇದು.

ಸಂರಚನೆಯನ್ನು ಮುಟ್ಟುವ ಮೊದಲು ಮಾರ್ಗವನ್ನು ಬರೆಯಿರಿ

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

ನಂತರ ಮೂಲ/ಗಮ್ಯ ಪರಿಶೀಲನೆಯ ಸಂರಚನೆಯನ್ನು ನಿಜವಾದ ಫಾರ್ವರ್ಡಿಂಗ್ ಘಟಕದಲ್ಲಿ ಪರಿಶೀಲಿಸಿ, VPCಯ ಪ್ರತಿ ಇನ್ಸ್ಟಾನ್ಸ್ನಲ್ಲಲ್ಲ. ಇತರರಿಗೆ ಟ್ರಾಫಿಕ್ ಫಾರ್ವರ್ಡ್ ಮಾಡುವ ಇನ್ಸ್ಟಾನ್ಸ್ಗೆ ಆ ಪರಿಶೀಲನೆ ನಿಷ್ಕ್ರಿಯವಾಗಿರಬೇಕು ಏಕೆ ಎಂದು AWS ದಾಖಲಿಸುತ್ತದೆ, ಮತ್ತು ಸಂರಚನೆಯು ಇಡೀ VPCಯ ಡೀಫಾಲ್ಟ್ ಅಲ್ಲದೆ ಪ್ರತಿ ಇನ್ಸ್ಟಾನ್ಸ್ನ ನಿರ್ಧಾರ ಏಕೆ ಎಂದೂ ದಾಖಲಿಸುತ್ತದೆ.

ನಾಲ್ಕು ಗಡಿಗಳು, ಮತ್ತು ಪರಿಶೀಲನೆ ಅವುಗಳಲ್ಲಿ ಒಂದೇ

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

ಕ್ರಮ ಮುಖ್ಯ ಏಕೆಂದರೆ ಪರಿಶೀಲನೆ ಅಗ್ಗ: ರೂಟ್ಗಳು ಒಂದು ಪುಟದಲ್ಲಿ ಕಾಣುತ್ತವೆ, ಪರಿಶೀಲನೆ ಒಂದೇ ಗುಣಲಕ್ಷಣ, ಮತ್ತು ಗಮ್ಯದ ಅಭಿಪ್ರಾಯ ಸಾಮಾನ್ಯವಾಗಿ ಯಾರಾದರೂ ಕೊನೆಯದಾಗಿ ಕೇಳುವ ವಿಷಯ.

ಅನುವಾದವು ಗಮ್ಯ ಯಾವ ಮೂಲವನ್ನು ನೋಡುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಿಸುತ್ತದೆ

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

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

ಮೂಲ ಕ್ಲೈಂಟ್ನಿಂದ ಪರೀಕ್ಷಿಸಿ, ನಂತರ ಬದಲಾವಣೆಯನ್ನು ಉಳಿಸಿ

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

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