VPN ಸರ್ವರ್ ಚಾಲನೆಯಲ್ಲಿದೆ, ಕ್ಲೈಂಟ್ ಸಮಯ ಮೀರುತ್ತಿದೆ, ಮತ್ತು ಮೊದಲ ಪ್ರತಿಕ್ರಿಯೆ ಎಂದರೆ ಸೆಕ್ಯುರಿಟಿ ಗ್ರೂಪ್‌ಗೆ ಎಲ್ಲವನ್ನೂ ಅನುಮತಿಸುವ ನಿಯಮ ಸೇರಿಸುವುದು. ಕೆಲವೊಮ್ಮೆ ಅದರಿಂದ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಅದೇ ಅತ್ಯಂತ ಕೆಟ್ಟ ಫಲಿತಾಂಶ, ಏಕೆಂದರೆ ಈಗ ಯಾವ ಗಡಿ ನಿಜವಾಗಿ ಮುಚ್ಚಿತು ಎಂದು ಯಾರಿಗೂ ಗೊತ್ತಿಲ್ಲ. ಕ್ಲೈಂಟ್ ಮತ್ತು ಡೀಮನ್ ನಡುವೆ ನಾಲ್ಕು ಪ್ರತ್ಯೇಕ ಫಿಲ್ಟರ್‌ಗಳಿವೆ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದೇ ಸೆಕ್ಯುರಿಟಿ ಗ್ರೂಪ್.

ನಿಯಮಕ್ಕಿಂತ ಮೊದಲು ಪ್ರೋಟೋಕಾಲ್ ಹೆಸರಿಸಿ

ನಿಯಮ ಎಂದರೆ ಪ್ರೋಟೋಕಾಲ್, ಪೋರ್ಟ್ ಶ್ರೇಣಿ ಮತ್ತು ಮೂಲ. WireGuard UDP ನಲ್ಲಿ ಕೇಳುತ್ತದೆ, ಸಾಮಾನ್ಯವಾಗಿ 51820. OpenVPN ಸಾಮಾನ್ಯವಾಗಿ UDP ಅಥವಾ TCP 1194 ಆಗಿದೆ, ಅದನ್ನು ಹೇಗೆ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ ಎಂಬುದರ ಮೇಲೆ ಅವಲಂಬಿತ. IPsec ಗೆ UDP 500 ಮತ್ತು 4500 ನಲ್ಲಿ IKE ವಿನಿಮಯ ಮತ್ತು ಜೊತೆಗೆ ESP ಪ್ರೋಟೋಕಾಲ್ ಸ್ವತಃ ಬೇಕು, ಅದು ಪೋರ್ಟ್ ಅಲ್ಲ ಬದಲಿಗೆ ಪ್ರೋಟೋಕಾಲ್ ಸಂಖ್ಯೆ. ಉಳಿದ ನಿಯಮಗಳು TCP ಎಂದು TCP ಊಹಿಸುವುದು ಸರಿಯಾಗಿ ಕಾಣುವ ಮತ್ತು ಯಾವುದಕ್ಕೂ ಹೊಂದಿಕೆಯಾಗದ ನಿಯಮವನ್ನು ನೀಡುತ್ತದೆ.

ಲಿಸನರ್ ಅನ್ನು ಚಾಲನೆಯಲ್ಲಿರುವ ಸೇವೆಯಿಂದ ಓದಿ, ಟ್ಯುಟೋರಿಯಲ್‌ನಿಂದ ಅಲ್ಲ. ಒಂದು ವಿಳಾಸಕ್ಕೆ ಬದ್ಧವಾದ ಡೀಮನ್ ಇನ್ನೊಂದು ವಿಳಾಸಕ್ಕೆ ಬರುವ ಸಂಚಾರವನ್ನು ಸ್ವೀಕರಿಸುವುದಿಲ್ಲ.

ಮೂಲವನ್ನು ಇಡೀ ಇಂಟರ್ನೆಟ್ ಬದಲು ವಿನ್ಯಾಸ ಅನುಮತಿಸುವ ಕ್ಲೈಂಟ್ ಶ್ರೇಣಿಗೆ ಸೀಮಿತಗೊಳಿಸಿ.

ಸೆಕ್ಯುರಿಟಿ ಗ್ರೂಪ್‌ಗಳು ಸ್ಟೇಟ್‌ಫುಲ್; ಸಬ್‌ನೆಟ್ ACL ಅಲ್ಲ

ಸೆಕ್ಯುರಿಟಿ ಗ್ರೂಪ್‌ಗಳು ಸ್ಟೇಟ್‌ಫುಲ್ ಮತ್ತು ಅನುಮತಿ ಮಾತ್ರ: ಅನುಮತಿಸಿದ ಒಳಬರುವ ಹರಿವು ತನ್ನ ಉತ್ತರಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಪಡೆಯುತ್ತದೆ, ಮತ್ತು ಯೋಚಿಸಬೇಕಾದ ನಿರಾಕರಣೆ ನಿಯಮವಿಲ್ಲ. ಸಬ್‌ನೆಟ್ ACL ಸ್ಟೇಟ್‌ಲೆಸ್ ಮತ್ತು ಎರಡೂ ದಿಕ್ಕಿನಲ್ಲಿ ಮೌಲ್ಯಮಾಪನವಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಸಂಬಂಧಿತ ಹೊರಹೋಗುವ ತಾತ್ಕಾಲಿಕ ಶ್ರೇಣಿ ಇಲ್ಲದ ಒಳಬರುವ ಅನುಮತಿ ಇನ್ನೂ ವಿಫಲವಾಗುತ್ತದೆ. ಈ ವ್ಯತ್ಯಾಸವೇ ಕನ್ಸೋಲ್‌ನಲ್ಲಿ ಸರಿಯಾಗಿ ಕಾಣುವ ಅನೇಕ ನಿಯಮಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ.

ಚಾಲನೆಯಲ್ಲಿರುವ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗೆ ಯಾವ ನೀತಿ ಲಗತ್ತಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನೂ ಖಚಿತಪಡಿಸಿ, ಏಕೆಂದರೆ ಒಂದು ಇನ್‌ಸ್ಟಾನ್ಸ್‌ನಲ್ಲಿ ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಗ್ರೂಪ್ ಇರಬಹುದು ಮತ್ತು ಲಗತ್ತಿಸದ ಗ್ರೂಪ್‌ನ ನಿಯಮ ಏನನ್ನೂ ಬದಲಿಸುವುದಿಲ್ಲ.

ಪರಿಣಾಮಕಾರಿ ನೀತಿ ಎಂದರೆ ಲಗತ್ತಿಸಿದ್ದರ ಒಕ್ಕೂಟ, ನೀವು ಸಂಪಾದಿಸಿದ ಫೈಲ್ ಅಲ್ಲ.

ಹೋಸ್ಟ್ ಫೈರ್‌ವಾಲ್ ಪ್ರತ್ಯೇಕ ಗಡಿ

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

ಹೋಸ್ಟ್ ಡಿಸ್ಟ್ರಿಬ್ಯೂಷನ್ ಫೈರ್‌ವಾಲ್ ಫ್ರಂಟೆಂಡ್ ಬಳಸಿದರೆ, ಪ್ರೊಫೈಲ್ ಹೆಸರ ಬದಲು ಆಧಾರ ನಿಯಮಗಳನ್ನು ಖಚಿತಪಡಿಸಿ, ಏಕೆಂದರೆ ಪ್ರೊಫೈಲ್ ಸಕ್ರಿಯವಾಗಿದ್ದರೂ ಪೋರ್ಟ್ ಮುಚ್ಚಿರಬಹುದು.

ಇಂಟರ್‌ಫೇಸ್‌ನಲ್ಲಿ ಸೆರೆಹಿಡಿಯುವುದು ಯಾವ ಗಡಿ ಪ್ಯಾಕೆಟ್ ಬೀಳಿಸಿತು ಎಂದು ಹೇಳುತ್ತದೆ.

ಲಿಸನರ್ ಅನುಮತಿಸುವುದು ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ರೂಟ್ ಮಾಡುವುದಲ್ಲ

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

ಇಲ್ಲಿಯೇ ಕೆಲಸ ಮಾಡುವ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಮತ್ತು ಮುರಿದ ಡೇಟಾ ಮಾರ್ಗ ಬೇರ್ಪಡುತ್ತವೆ, ಮತ್ತು ಆದ್ದರಿಂದ ಟನೆಲ್ ಸ್ಥಿತಿ ಆರೋಗ್ಯಕರವಾಗಿ ಕಾಣಬಹುದು ಆದರೆ ಏನೂ ಲೋಡ್ ಆಗುವುದಿಲ್ಲ.

ರೂಟಿಂಗ್ ಅನ್ನು ತನ್ನದೇ ಪರಿಶೀಲನೆಯೊಂದಿಗೆ ಪ್ರತ್ಯೇಕ ಬದಲಾವಣೆಯಾಗಿ ಸರಿಪಡಿಸಿ, ಮತ್ತು ಫಾರ್ವರ್ಡ್ ಮಾಡುವ ಗೇಟ್‌ವೇಗೆ ಗಮ್ಯವನ್ನು ಅನುಮತಿಸುವ ನಿರ್ಗಮನ ನೀತಿಯೂ ಬೇಕು ಎಂದು ಗಮನಿಸಿ.

ಹಿಂತಿರುಗುವ ದಾರಿ ಇಟ್ಟುಕೊಳ್ಳಿ, ನಂತರ ನಿಯಮ ಕಿರಿದಾಗಿಸಿ

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

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

ಲಗತ್ತನ್ನೂ ದಾಖಲಿಸಿ, ಇಲ್ಲದಿದ್ದರೆ ಬದಲಿ ಇಂಟರ್‌ಫೇಸ್ ನೀತಿಯನ್ನು ಸದ್ದಿಲ್ಲದೆ ಕಳೆದುಕೊಳ್ಳುತ್ತದೆ.

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