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

ನಿಯಮ ಬರೆಯುವ ಮೊದಲು ಸೇವೆಯನ್ನು ಬರೆಯಿರಿ

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

ಅನುವಾದ ಮತ್ತು ರೂಟಿಂಗ್ ಒಳಗಾದಾಗ ಈ ಎರಡು ವಿಳಾಸಗಳು ಜನರು ನಿರೀಕ್ಷಿಸುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿ ಬೇರೆಯಾಗುತ್ತವೆ.

ಮೂರು ಮೂಲ ಮಾದರಿಗಳು, ಮೂರು ವಿಭಿನ್ನ ನಿಯಮಗಳು

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

ಕೆಲಸ ಮಾಡದಿರುವುದು VPN ಗೇಟ್‌ವೇಯನ್ನು ಭದ್ರತಾ ಗುಂಪಿನ ಮೂಲವಾಗಿ ಉಲ್ಲೇಖಿಸುವುದು. ಗುಂಪು ಉಲ್ಲೇಖಗಳು VPC ಅಥವಾ ಜೋಡಿತ ನೆಟ್‌ವರ್ಕ್ ಒಳಗಿನ ಸ್ಥಿತಿಸ್ಥಾಪಕ ನೆಟ್‌ವರ್ಕ್ ಇಂಟರ್‌ಫೇಸ್‌ಗಳಿಗೆ ಹೊಂದುತ್ತವೆ, ಮತ್ತು ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವ ಗೇಟ್‌ವೇ ಅವುಗಳಲ್ಲಿ ಒಂದಲ್ಲ.

ಪ್ರತಿ ಸಂಲಗ್ನ ಗುಂಪಿನಾದ್ಯಂತ ಒಕ್ಕೂಟವನ್ನು ಓದಿ

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

AWS ನಿಯಮ ಉಲ್ಲೇಖವು ಭದ್ರತಾ ಗುಂಪುಗಳನ್ನು ಮಾತ್ರ-ಅನುಮತಿ ಎಂದು ವಿವರಿಸುತ್ತದೆ ಮತ್ತು ಎಲ್ಲಾ ಸಂಲಗ್ನ ಗುಂಪುಗಳ ನಿಯಮಗಳನ್ನು ಒಟ್ಟುಗೂಡಿಸಲಾಗುತ್ತದೆ ಎಂದು ಹೇಳುತ್ತದೆ, ಮತ್ತು ಇದೇ ಈ ವೈಫಲ್ಯದ ಹಿಂದಿನ ಸಂಪೂರ್ಣ ಕಾರ್ಯವಿಧಾನ.

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

ನಿರಾಕರಣೆಯ ಗೋಡೆಯಿಂದ ಉತ್ತರಿಸಬೇಡಿ

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

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

ಹೊಸ ಸೆಷನ್‌ನೊಂದಿಗೆ ಪರೀಕ್ಷಿಸಿ ಮತ್ತು ಒಳಗೆ ಬರುವ ದಾರಿಯನ್ನು ಇಟ್ಟುಕೊಳ್ಳಿ

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

ಕೊನೆಯದಾಗಿ, ಅಪ್ಲಿಕೇಶನ್‌ನ ಸ್ವಂತ ಅಧಿಕಾರವನ್ನು ಅದರ ಸ್ಥಳದಲ್ಲೇ ಇರಿಸಿ. ಅನುವಾದಿತ ಕಾರ್ಪೊರೇಟ್ ಎಗ್ರೆಸ್ ನೂರಾರು ಜನರನ್ನು ಪ್ರತಿನಿಧಿಸಬಹುದು, ಮತ್ತು ನೆಟ್‌ವರ್ಕ್ ಪ್ರವೇಶವು ಎಂದಿಗೂ ಒಬ್ಬ ವ್ಯಕ್ತಿಗತ ಬಳಕೆದಾರ ಅಥವಾ ಅವರ ಸಾಧನವನ್ನು ಗುರುತಿಸಿಲ್ಲ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು