AWS Client VPN ನಿಯಮಗಳು ಸಂಪನ್ಮೂಲದಲ್ಲಿರಬೇಕು, ಸಬ್ನೆಟ್ನಲ್ಲಲ್ಲ

ಸಿಬ್ಬಂದಿ VPC ಯಲ್ಲಿ ಒಂದು ಅಪ್ಲಿಕೇಶನ್ ತಲುಪಬೇಕು ಮತ್ತು ಅದೇ ಇನ್ಸ್ಟಾನ್ಸ್‌ನಲ್ಲಿನ ಡೇಟಾಬೇಸ್ ಶ್ರೋತೃವನ್ನು ತಲುಪಬಾರದು, ಆದ್ದರಿಂದ ಯಾರೋ VPN endpoint ಗಾಗಿ ಎರಡನೇ ಸಾರ್ವಜನಿಕ ಸಬ್ನೆಟ್ ಸೇರಿಸಿ ಅಗತ್ಯ ಪೂರೈಸಲಾಗಿದೆ ಎಂದು ಹೇಳುತ್ತಾರೆ. ಸಬ್ನೆಟ್ ಸ್ಥಾನ ರೂಟಿಂಗ್ ಮತ್ತು ಲಭ್ಯತೆಯನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ. ಅದು ಒಂದೂ ಪೋರ್ಟ್ ನೀಡುವುದಿಲ್ಲ ಅಥವಾ ತಡೆಯುವುದಿಲ್ಲ. ಅಗತ್ಯವನ್ನು ವ್ಯಕ್ತಪಡಿಸುವ ಅನುಮತಿ ಗಮ್ಯಸ್ಥಾನದಲ್ಲಿ, ಸಂಪನ್ಮೂಲದ ಭದ್ರತಾ ಗುಂಪಿನಲ್ಲಿ ಇರುತ್ತದೆ, ಮತ್ತು VPN ಗಡಿ ಆ ನಿಯಮ ಉಲ್ಲೇಖಿಸುವ ಹ್ಯಾಂಡಲ್ ಅನ್ನು ಒದಗಿಸುತ್ತದೆ.

ಸಬ್ನೆಟ್ ಸ್ಥಾನ ರೂಟಿಂಗ್, ಅಧಿಕಾರ ನೀಡಿಕೆ ಅಲ್ಲ

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

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

Client VPN ಸಂಯೋಜನಾ ಗುಂಪೇ ಆ ಹ್ಯಾಂಡಲ್

ಸಬ್ನೆಟ್‌ಗೆ ಸಂಯೋಜಿತವಾದ AWS Client VPN endpoint ಗಾಗಿ ದಾಖಲಿತ ವ್ಯವಸ್ಥೆ ನಿರ್ದಿಷ್ಟವಾಗಿದೆ. ಉದ್ದೇಶಿತ ಭದ್ರತಾ ಗುಂಪನ್ನು endpoint ನ ಗುರಿ ನೆಟ್‌ವರ್ಕ್ ಸಂಯೋಜನೆಗಳಿಗೆ ಅನ್ವಯಿಸಿ, ನಂತರ ಆ Client VPN ಗುಂಪನ್ನು ಮೂಲವಾಗಿ ಬಳಸಿ ಸಂಪನ್ಮೂಲದ ಭದ್ರತಾ ಗುಂಪಿನಲ್ಲಿ ಅಗತ್ಯ ಸಂಚಾರಕ್ಕೆ ಅನುಮತಿ ನೀಡಿ.

ನಿರ್ದಿಷ್ಟವಾಗಿ, ಅಪ್ಲಿಕೇಶನ್ ಇನ್ಸ್ಟಾನ್ಸ್‌ನ ಗುಂಪು ಸಂಯೋಜನಾ ಗುಂಪಿನಿಂದ ಅಪ್ಲಿಕೇಶನ್ ಪೋರ್ಟ್‌ಗೆ ಮಾತ್ರ ಅನುಮತಿ ನೀಡುತ್ತದೆ, ಬೇರೇನೂ ಅಲ್ಲ. AWS ನ ಸಂಪನ್ಮೂಲ ಪ್ರವೇಶ ಕಾರ್ಯವಿಧಾನ ಆ ಸಂಬಂಧವನ್ನು ವಿವರಿಸುತ್ತದೆ, ಮತ್ತು endpoint ಸಂಯೋಜನೆಗೊಳ್ಳುವ ಪ್ರತಿಯೊಂದು ಸಬ್ನೆಟ್‌ನಲ್ಲೂ ಅದೇ ಗುಂಪು ನೀತಿಯನ್ನು ಇಟ್ಟುಕೊಳ್ಳುವುದು ಒಳ್ಳೆಯದು, ಏಕೆಂದರೆ ಬೇರೆ ಗುಂಪಿನೊಂದಿಗಿನ ಹಳೆಯ ಸಂಯೋಜನೆ ಗಡಿಯನ್ನು ಮೌನವಾಗಿ ವಿಸ್ತರಿಸುತ್ತದೆ.

ಆ ನಿಯಮ ಯಾರನ್ನೂ ದೃಢೀಕರಿಸುವುದಿಲ್ಲ. ಲಾಗಿನ್ ಪ್ರತ್ಯೇಕ ನಿಯಂತ್ರಣ, ಮತ್ತು ಸಂಪನ್ಮೂಲದ ಕಡೆಗಿನ ಮಾರ್ಗ ಮೂರನೆಯದು. ವಿನಂತಿ ಬರುವ ಮೊದಲು ಮೂರೂ ನಿಜವಾಗಿರಬೇಕು. ಯಾವುದು ವಿಫಲವಾಗುತ್ತದೆಯೋ ಅದು ಯಾವ ಸರಿಪಡಿಸುವಿಕೆ ಸರಿ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ, ಮತ್ತು ನಿಯಮ ಬದಲಾವಣೆ ಮೊದಲನೆಯದಕ್ಕೆ ಮಾತ್ರ ಸರಿಯಾದ ಉತ್ತರ.

ಒಂದು ಸಂಯೋಜನಾ ಗುಂಪು ಪ್ರತ್ಯೇಕಿಸಲಾಗದ್ದು

ಒಂದೇ ಸಂಯೋಜನಾ ಗುಂಪಿನ ಹಿಂದಿನ ಪ್ರತಿಯೊಬ್ಬ ಕ್ಲೈಂಟ್ ಸಂಪನ್ಮೂಲವನ್ನು ಅದೇ ಭದ್ರತಾ ಗುಂಪು ಮೂಲವಾಗಿ ತಲುಪುತ್ತಾನೆ. ವಿಭಿನ್ನ ಪಾತ್ರಗಳಿರುವ ಇಬ್ಬರು ಬಳಕೆದಾರರು ಆ ಪದರದಲ್ಲಿ ಪ್ರತ್ಯೇಕಿಸಲಾಗದವರು, ಗುಂಪನ್ನು ಹೇಗೇ ಹೆಸರಿಸಿದರೂ ಅಥವಾ ಟ್ಯಾಗ್ ಮಾಡಿದರೂ. Client VPN ನ ಬಾಹ್ಯ ಗುಂಪು ಅಧಿಕಾರ ನೀಡಿಕೆ ಡೈರೆಕ್ಟರಿ ಅಥವಾ SAML ಗುಂಪಿಗೆ ಗಮ್ಯ ಪೂರ್ವಪ್ರತ್ಯಯದ ಮೂಲಕ ಪ್ರವೇಶವನ್ನು ಮಿತಿಗೊಳಿಸುತ್ತದೆ, ಇದು ಸಂಪನ್ಮೂಲ ಪಾತ್ರಕ್ಕಿಂತ ಒರಟಾಗಿದೆ ಮತ್ತು ಗುರುತಿನ ವ್ಯವಸ್ಥೆಯಲ್ಲ, ನೆಟ್‌ವರ್ಕ್ ಗಡಿಯಾಗಿ ಪರಿಗಣಿಸಬೇಕು.

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

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

ಆ ನಿಯಮವನ್ನು ಪ್ರತಿ VPN ವಿನ್ಯಾಸಕ್ಕೂ ನಕಲಿಸಬೇಡಿ

ಸ್ವಯಂ ನಿರ್ವಹಿತ EC2 VPN ಗೇಟ್‌ವೇ, ರೂಟ್ ಮಾಡಿದ ತಪಾಸಣಾ ಸಾಧನ ಮತ್ತು ನಿರ್ವಹಿತ Client VPN ಮೂರು ವಿಭಿನ್ನ ಪ್ಯಾಕೆಟ್ ಮಾರ್ಗಗಳು. ಯಾವ ಮೂಲ ವಿಳಾಸವು ನಿಜವಾಗಿ ಸಂಪನ್ಮೂಲವನ್ನು ತಲುಪುತ್ತದೆ, ಮಧ್ಯದಲ್ಲಿ ಅನುವಾದ ನಡೆಯುತ್ತದೆಯೇ ಮತ್ತು ಆ ಮಾರ್ಗದಲ್ಲಿ ಸೇವೆ ಯಾವ ಉಲ್ಲೇಖ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಿ.

ಮಧ್ಯವರ್ತಿ ಸಾಧನದ ಮೂಲಕ ಸಂಚಾರವನ್ನು ರವಾನಿಸುವುದು ನೇರ ಇನ್ಸ್ಟಾನ್ಸ್-ಟು-ಇನ್ಸ್ಟಾನ್ಸ್ ಸಂಚಾರದಂತೆ ಮೂಲ ಭದ್ರತಾ ಗುಂಪು ಉಲ್ಲೇಖವನ್ನು ಉಳಿಸಿಕೊಳ್ಳುವುದಿಲ್ಲ. ಅಂತಹ ವಿನ್ಯಾಸಗಳಿಗೆ ಗುಂಪು ಉಲ್ಲೇಖದ ಬದಲು ಸೂಕ್ತವಾದ ಖಾಸಗಿ ಮೂಲ ವಿಳಾಸಗಳು ಅಥವಾ CIDR ಬೇಕಾಗಬಹುದು ಎಂದು AWS ದಾಖಲಿಸುತ್ತದೆ. ನಿರ್ವಹಿತ Client VPN ಕಾರ್ಯವಿಧಾನವು ಪ್ರತಿ ಗೇಟ್‌ವೇಯ ಸಂಯೋಜಿತ ಗುಂಪು ರವಾನಿಸಿದ ಪ್ಯಾಕೆಟ್‌ಗಳಿಗೆ ಸಾರ್ವತ್ರಿಕ ಗುರುತಿನ ಟೋಕನ್ ಆಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷ್ಯವಲ್ಲ.

ಮಾರ್ಗದಲ್ಲಿ ಒಂದು NAT ಹಾಪ್ ಸಾಕು ಊಹೆಯನ್ನು ಮುರಿಯಲು, ಮತ್ತು ವೈಫಲ್ಯವು ಇರುವ ಆದರೆ ಎಂದಿಗೂ ಹೊಂದಿಕೆಯಾಗದ ನಿಯಮದಂತೆ ಕಾಣುತ್ತದೆ.

ಪರಿಣಾಮಕಾರಿ ಗಡಿಯನ್ನು ಪರಿಶೀಲಿಸಿ

ಸಂಪನ್ಮೂಲಕ್ಕೆ ಸಂಯೋಜಿತವಾದ ಪ್ರತಿಯೊಂದು ಭದ್ರತಾ ಗುಂಪನ್ನು ಓದಿ, ಏಕೆಂದರೆ ಅನುಮತಿ ನಿಯಮಗಳು ಸೇರಿಕೊಳ್ಳುತ್ತವೆ ಮತ್ತು ಕಿರಿದಾದ ನಿಯಮವು ಇನ್ನೊಂದು ಗುಂಪಿನಲ್ಲಿನ ವಿಶಾಲವಾದ ನಿಯಮವನ್ನು ರದ್ದುಗೊಳಿಸುವುದಿಲ್ಲ. ನಂತರ ನೆಟ್‌ವರ್ಕ್ ACL, ಹೋಸ್ಟ್ ಫೈರ್‌ವಾಲ್ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ನ ಸ್ವಂತ ಅಧಿಕಾರ ನೀಡಿಕೆಯನ್ನು ಪರಿಶೀಲಿಸಿ, ಇವು ಪ್ರತ್ಯೇಕ ತಪ್ಪುಗಳಿರುವ ಪ್ರತ್ಯೇಕ ಪದರಗಳು.

ಅದೇ ಸಂಪನ್ಮೂಲದ ವಿರುದ್ಧ ಒಂದು ಅನುಮತಿಸಿದ ಮತ್ತು ಒಂದು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಹೊರಗಿಟ್ಟ ವಿನಂತಿಯೊಂದಿಗೆ ಮುಗಿಸಿ. ಆ ಜೋಡಿ ಗಡಿಯನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಆದರೆ ಒಂದೇ ಯಶಸ್ವಿ ಸಂಪರ್ಕ ಏನೋ ತೆರೆದಿದೆ ಎಂಬುದನ್ನು ಮಾತ್ರ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. endpoint ಹೊಂದಿರುವ ಸಬ್ನೆಟ್ ಬದಲು ಮಾರ್ಗ, ಪರಿಣಾಮಕಾರಿ ಮೂಲ ಮತ್ತು ಉದ್ದೇಶಿತ ಸೇವಾ ಪೋರ್ಟ್ ಅನ್ನು ದೃಢೀಕರಿಸಿ.

ಕೆಲಸದ ಕ್ರಮ: ನಾಲ್ಕು ಭಾಗದ ಅಗತ್ಯವನ್ನು ಬರೆಯಿರಿ, ಗುಂಪನ್ನು ಸಂಯೋಜನೆಗಳಿಗೆ ಜೋಡಿಸಿ, ಸಂಪನ್ಮೂಲ ನಿಯಮವನ್ನು ಪೋರ್ಟ್‌ಗೆ ಸೀಮಿತಗೊಳಿಸಿ, ಒಂದು ಅನುಮತಿ ಮತ್ತು ಒಂದು ನಿರಾಕರಣೆಯನ್ನು ಪರಿಶೀಲಿಸಿ, ಮತ್ತು ಆಮೇಲೆ ಮಾತ್ರ ರೂಟಿಂಗ್ ಕಾರಣಗಳಿಗಾಗಿ ಸಬ್ನೆಟ್‌ಗಳನ್ನು ವಿಭಜಿಸುವುದನ್ನು ಪರಿಗಣಿಸಿ.