EC2 ನಿಮ್ಮ AWS Client VPN ಲ್ಯಾಪ್‌ಟಾಪ್‌ಗೆ ಏಕೆ ತಲುಪಲಾರದು
Client VPN IPv4 ಕ್ಲೈಂಟ್ ಮೂಲಗಳನ್ನು endpoint ನ ಇಂಟರ್ಫೇಸ್‌ಗೆ ಅನುವಾದಿಸುತ್ತದೆ. ಅದಕ್ಕೇ ಉತ್ತರ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಮತ್ತು EC2 ನಿಂದ ಹೊಸ ಸಂಪರ್ಕ ಮಾಡುವುದಿಲ್ಲ.
AWS Client VPN ಮೂಲಕ ಸಂಪರ್ಕಗೊಂಡ ಲ್ಯಾಪ್‌ಟಾಪ್ EC2 ಅಪ್ಲಿಕೇಶನ್‌ನ್ನು ಯಾವುದೇ ತೊಂದರೆಯಿಲ್ಲದೆ ತಲುಪುತ್ತದೆ. ನಂತರ ನೀವು ವಿರುದ್ಧ ದಿಕ್ಕನ್ನು ಪ್ರಯತ್ನಿಸುತ್ತೀರಿ, EC2 ನಿಂದ ಕ್ಲೈಂಟ್‌ಗೆ ನೀಡಿದ ವಿಳಾಸಕ್ಕೆ, ಮತ್ತು ಸಂಪರ್ಕ ನೇತಾಡುತ್ತದೆ ಅಥವಾ ನಿರಾಕರಿಸಲ್ಪಡುತ್ತದೆ. ಈ ಅಸಮಮಿತಿ ಅಪರೂಪವಾಗಿ ಕಾಣೆಯಾದ ಭದ್ರತಾ ಗುಂಪು ನಿಯಮವಾಗಿರುತ್ತದೆ. VPC ಉಪಜಾಲಗಳಿಗೆ ಸಂಯೋಜಿತವಾದ Client VPN endpoint ನಲ್ಲಿ AWS IPv4 ಕ್ಲೈಂಟ್ ಮೂಲಗಳನ್ನು endpoint ನ ನೆಟ್‌ವರ್ಕ್ ಇಂಟರ್ಫೇಸ್‌ಗೆ ಅನುವಾದಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ನಿಮ್ಮ ಲ್ಯಾಪ್‌ಟಾಪ್ ಅನ್ನು ಪ್ರತಿನಿಧಿಸುವ ಒಳಬರುವ VPC ವಿಳಾಸವಿಲ್ಲ.
ಕ್ಯಾಪ್ಚರ್ ತೋರಿಸುವುದರಿಂದ ಪ್ರಾರಂಭಿಸಿ
ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕಗೊಳ್ಳುತ್ತಿರುವಾಗ EC2 ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಕ್ಯಾಪ್ಚರ್ ತೆಗೆದುಕೊಂಡು ಅಪ್ಲಿಕೇಶನ್ ನಿಜವಾಗಿ ನೋಡುವ ಮೂಲ ವಿಳಾಸವನ್ನು ಓದಿ. ಅದು ಕ್ಲೈಂಟ್ ಪೂಲ್‌ನ ವಿಳಾಸವಲ್ಲದೆ VPC ಬದಿಯ endpoint ಇಂಟರ್ಫೇಸ್ ಆಗಿದ್ದರೆ, ಒಂದು ನಿಯಮವನ್ನೂ ಬದಲಿಸುವ ಮೊದಲೇ ಅನುವಾದ ದೃಢೀಕರಿಸಲ್ಪಟ್ಟಿದೆ.
ಕ್ಲೈಂಟ್ ಪೂಲ್ ಒಂದು ಹಂಚಿಕೆ ಶ್ರೇಣಿ, ಹಿಂತಿರುಗುವ ಮಾರ್ಗವಿರುವ ಉಪಜಾಲವಲ್ಲ. ಈ ವ್ಯತ್ಯಾಸದಲ್ಲಿಯೇ ಇಂತಹ ತನಿಖೆಗಳ ಬಹುಪಾಲು ತಪ್ಪು ದಾರಿ ಹಿಡಿಯುತ್ತವೆ.
ಅಸಮಮಿತಿಯನ್ನು ವಿವರಿಸುವ ಅನುವಾದ
ಮೂರು ಹರಿವುಗಳನ್ನು ಪರಸ್ಪರ ಗೊಂದಲಿಸಲಾಗುತ್ತದೆ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದೇ ಜನರು ಪರೀಕ್ಷಿಸುವ ಹರಿವು.
| Flow | Started by | What the VPC sees | Outcome |
|---|---|---|---|
| Client to EC2 service | The client | A translated source at the endpoint interface | Works, with a stateful reply |
| EC2 host to client pool address | The EC2 host | A destination with no route and no translation state | No usable path |
| Client to client | A client, when the feature is configured | Traffic mediated by the endpoint | Works only with that feature and its authorisation |
Client VPN ಘಟಕಗಳ ವಿವರಣೆ IPv4 ಕ್ಲೈಂಟ್ ಮೂಲಗಳು endpoint ಇಂಟರ್ಫೇಸ್‌ಗೆ ಅನುವಾದಗೊಳ್ಳುತ್ತವೆ ಎಂದು ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳುತ್ತದೆ, ಮತ್ತು ಮಧ್ಯದ ಸಾಲಿಗೆ ಹೊಂದಿಸಲು ಏನೂ ಏಕೆ ಇಲ್ಲ ಎಂಬುದನ್ನು ನೋಡಲು ಅಷ್ಟೇ ಸಾಕು.
ಹೊಸ ಸಂಪರ್ಕಕ್ಕೆ ಮಾರ್ಗ, ವಿಳಾಸ ಪರಿಹಾರದ ಹಂತ ಮತ್ತು ಅಧಿಕಾರ ನಿರ್ಣಯ ಬೇಕು. ಬೇರೊಬ್ಬರ ಅವಧಿಯಿಂದ ಬಂದ ಅನುವಾದ ಸ್ಥಿತಿ ಈ ಮೂರರಲ್ಲಿ ಒಂದನ್ನೂ ಒದಗಿಸುವುದಿಲ್ಲ.
ಉತ್ತರ ಹೊಸ ಸಂಪರ್ಕ ಏಕೆ ಅಲ್ಲ
TCP ಉತ್ತರವನ್ನು ಇರುವ ನಮೂದಿಗೆ ಹೊಂದಿಸಲಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಯಾವುದೇ ಒಳಬರುವ ನಿಯಮವಿಲ್ಲದೆಯೂ ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಕೆಲಸ ಮಾಡುತ್ತದೆ. EC2 ಹೋಸ್ಟ್‌ನಿಂದ ಬರುವ ಹೊಸ SYN ಗೆ ಹೊಂದಿಸಲು ನಮೂದಿಲ್ಲ, ಆದ್ದರಿಂದ ಅದು VPC ಗೆ ತಲುಪುವುದು ಹೇಗೆಂದು ತಿಳಿಯದ ಗಮ್ಯದೆಡೆಗೆ ಸಾಮಾನ್ಯ ಹೊರಹೋಗುವ ಪ್ರಯತ್ನವಾಗುತ್ತದೆ.
ಅದಕ್ಕೇ ಇದನ್ನು ಒಂದೇ ದಿಕ್ಕಿನಲ್ಲಿ ಹೋಗುವ ಸಂಚಾರ ಎಂದು ವಿವರಿಸುವುದು ದಾರಿತಪ್ಪಿಸುತ್ತದೆ. ಈ ಅವಧಿಗಳಲ್ಲಿ ಹಿಂತಿರುಗುವ ಸಂಚಾರ ನಿರಂತರವಾಗಿ ಹರಿಯುತ್ತದೆ. ಮಾರ್ಗವಿಲ್ಲದ ಭಾಗವೆಂದರೆ ಆರಂಭ.
ಕೆಲಸ ಮಾಡಬೇಕಾದ ಅವಧಿಯನ್ನು ಇನ್ನೂ ಏನು ಮುರಿಯುತ್ತದೆ
ಭದ್ರತಾ ಗುಂಪುಗಳು, ನೆಟ್‌ವರ್ಕ್ ACL ಗಳು ಮತ್ತು ಲ್ಯಾಪ್‌ಟಾಪ್‌ನ ಸ್ವಂತ ಫೈರ್‌ವಾಲ್ — ಯಶಸ್ವಿಯಾಗಬೇಕಾದ ಸಂಪರ್ಕಗಳಿಗೆ ಎಲ್ಲವೂ ಮುಖ್ಯ. ವಿಫಲವಾದ ping ಅತ್ಯಲ್ಪ ಹೇಳುತ್ತದೆ, ಏಕೆಂದರೆ ICMP ನೀತಿ ನಿಮಗೆ ಮುಖ್ಯವಾದ TCP ನೀತಿಯಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿರುತ್ತದೆ.
ಈ ನಿಯಮಗಳನ್ನು ಅನುವಾದಿತ ಮೂಲಕ್ಕೆ ಅನುಗುಣವಾಗಿ ಬರೆಯಿರಿ, ಕ್ಲೈಂಟ್ ವಿಳಾಸಕ್ಕಲ್ಲ. ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಎಂದೂ ಕಾಣದ ವಿಳಾಸಕ್ಕೆ ಬಂಧಿಸಿದ ನಿಯಮಗಳೇ ಈ ವಿನ್ಯಾಸದಲ್ಲಿ ಅತಿ ಸಾಮಾನ್ಯ ಸ್ವಯಂ ಉಂಟುಮಾಡಿದ ವೈಫಲ್ಯ.
VPC ನಿಜವಾಗಿಯೂ ಸಂಭಾಷಣೆ ಪ್ರಾರಂಭಿಸಬೇಕಾದಾಗ
ಸೇವೆಯೊಂದು ಕಾರ್ಯಸ್ಥಾನಕ್ಕೆ ತಿಳಿಸಬೇಕಿದ್ದರೆ, ದಿಕ್ಕನ್ನು ತಿರುಗಿಸಿ ಮತ್ತು ಸೇವೆ ಉತ್ತರಿಸುವ ನಿರಂತರ ಹೊರಹೋಗುವ ಚಾನಲ್ ಅನ್ನು ಕ್ಲೈಂಟ್ ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳಲು ಬಿಡಿ. ಇಡೀ ದೂರದ ಜಾಲವು VPC ಯಿಂದ ತಲುಪಬಹುದಾದದ್ದಾಗಿರಬೇಕಿದ್ದರೆ, Client VPN ಈಗಾಗಲೇ ಅದನ್ನು ಮಾಡುತ್ತದೆ ಎಂದು ಊಹಿಸುವ ಬದಲು ತನ್ನ ಪೂರ್ವಪ್ರತ್ಯಯಗಳು ಮತ್ತು ಪ್ರವೇಶ ನೀತಿಯನ್ನು ಪ್ರಕಟಿಸುವ ವಾಸ್ತುಶಿಲ್ಪವನ್ನು ಆರಿಸಿ. ಕ್ಲೈಂಟ್‌ನಿಂದ ಕ್ಲೈಂಟ್‌ಗೆ ಪ್ರವೇಶವು ಮೂರನೆಯ, ಸಣ್ಣ ಪ್ರಕರಣ, ಅದರ ಸ್ವಂತ ಮಾರ್ಗ ಮತ್ತು ಅಧಿಕಾರ ವಸ್ತುಗಳೊಂದಿಗೆ. ಇವುಗಳಲ್ಲಿ ಯಾವುದೂ ಇರುವ endpoint ನಲ್ಲಿ ಕೇವಲ ಚೆಕ್‌ಬಾಕ್ಸ್ ಅಲ್ಲ.
IPv4 ವಿವರಣೆಯ ವ್ಯಾಪ್ತಿಯನ್ನೂ ಪ್ರಾಮಾಣಿಕವಾಗಿ ಇರಿಸಿ. ಪ್ರಸ್ತುತ AWS ದಾಖಲೆಗಳು IPv6 ಅನ್ನು ಪ್ರತ್ಯೇಕಿಸುತ್ತವೆ, ಅಲ್ಲಿ ಆ ಅನುವಾದ ಅನ್ವಯವಾಗುವುದಿಲ್ಲ, ಮತ್ತು ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಮಾರ್ಗನಿರ್ದೇಶನ ಮಾಡುವ ಇತರ ಸಂಪರ್ಕ ಮಾದರಿಗಳನ್ನು.
ಮೂರು ಲೇಬಲ್ ಮಾಡಿದ ಹಂತಗಳಲ್ಲಿ ಪರೀಕ್ಷಿಸಿ: ಕ್ಲೈಂಟ್ ಅನುಮತಿಸಿದ ಅವಧಿಯನ್ನು ತೆರೆಯುತ್ತದೆ, VPC ಸೇವೆ ಆ ಅವಧಿಗೆ ಉತ್ತರಿಸುತ್ತದೆ, ಮತ್ತು VPC ಹೋಸ್ಟ್ ಕ್ಲೈಂಟ್‌ನೆಡೆಗೆ ಹೊಸ ಅವಧಿ ತೆರೆಯುತ್ತದೆ. ಮೊದಲೆರಡು ಯಶಸ್ವಿಯಾಗಿ ಮೂರನೆಯದು ವಿಫಲವಾಗುವುದು ಈ ವಿನ್ಯಾಸದ ನಿರೀಕ್ಷಿತ ರೂಪ, ಫೈರ್‌ವಾಲ್ ನಿಯಮಗಳಿಂದ ಬೆನ್ನಟ್ಟಬೇಕಾದ ದೋಷವಲ್ಲ.