AWS NAT ಗೇಟ್ವೇ ಮೂಲಕ GRE ಮತ್ತು ESP ಏಕೆ ವಿಫಲವಾಗುತ್ತವೆ

ಸುರಂಗ ವಿಫಲವಾಗುತ್ತದೆ, ಭದ್ರತಾ ಗುಂಪು ಈಗಾಗಲೇ ಎಲ್ಲಾ ಸಂಚಾರವನ್ನು ಅನುಮತಿಸುತ್ತದೆ, ಮತ್ತು AWS VPN ಅನ್ನು ನಿರ್ಬಂಧಿಸುತ್ತಿದೆ ಎಂಬ ತೀರ್ಮಾನಕ್ಕೆ ಬರಲಾಗುತ್ತದೆ. ಅದು ಏನನ್ನೂ ನಿರ್ಬಂಧಿಸುತ್ತಿಲ್ಲ. ನಿರ್ವಹಿತ NAT ಗೇಟ್ವೇ ದಾಖಲಿತ ಬಾಹ್ಯ ಪ್ರೋಟೋಕಾಲ್ಗಳ ಗುಂಪನ್ನು ಮುಂದಕ್ಕೆ ಸಾಗಿಸುತ್ತದೆ, ಮತ್ತು ಸ್ಥಳೀಯ GRE ಅಥವಾ ಸ್ಥಳೀಯ ESP ಅದರಲ್ಲಿ ಇಲ್ಲ, ಆದ್ದರಿಂದ ನೀವು ಸೇರಿಸುವ ಯಾವುದೇ ನಿಯಮ ಗೇಟ್ವೇಗೆ ಅವುಗಳನ್ನು ಸಾಗಿಸಲು ಮಾಡುವುದಿಲ್ಲ. ಅನುಮತಿ ನಿಯಮ ಮತ್ತು ಸಾಗಣೆ ಸಾಮರ್ಥ್ಯ ಎರಡು ವಿಭಿನ್ನ ವಿಷಯಗಳು, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದನ್ನು ಮಾತ್ರ ನೀವು ಬದಲಿಸಬಹುದು.

ನಿಯಮಗಳ ಗುಂಪು ಪ್ರೋಟೋಕಾಲ್ಗಳ ಗುಂಪಲ್ಲ

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

AWS ನ NAT ಗೇಟ್ವೇ ಪ್ರೋಟೋಕಾಲ್ ವಿಶೇಷಣೆ ನಿರ್ವಹಿತ ಸೇವೆಗಾಗಿ TCP, UDP ಮತ್ತು ICMP ಅನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ. ಅದೇ ಸಂಪೂರ್ಣ ಬೆಂಬಲಿತ ಗುಂಪು. ಇನ್ನೊಂದು IP ಪ್ರೋಟೋಕಾಲ್ಗೆ ಇರುವ ಅನುಮತಿ ನಿಯಮ ಅದನ್ನು ವಿಸ್ತರಿಸಲಾರದು, ಏಕೆಂದರೆ ನಿಯಮವು ಗೇಟ್ವೇಯ ಮುಂದಕ್ಕೆ ಸಾಗಿಸುವ ಮಾರ್ಗ ತಲುಪುವ ಬಹಳ ಮೊದಲೇ ಮೌಲ್ಯಮಾಪನಗೊಳ್ಳುತ್ತದೆ.

ಈ ವ್ಯತ್ಯಾಸ ಮುಖ್ಯ ಏಕೆಂದರೆ ಎರಡೂ ವೈಫಲ್ಯಗಳು ಕ್ಲೈಂಟ್ನ ದೃಷ್ಟಿಯಿಂದ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ ಮತ್ತು ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನ ಪರಿಹಾರಗಳನ್ನು ಹೊಂದಿವೆ.

PPTP ಪೋರ್ಟ್ ಪರೀಕ್ಷೆ ಏಕೆ ಸುಳ್ಳು ಹೇಳುತ್ತದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ

ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸದ ಪೋರ್ಟ್ ಪರಿಶೀಲನೆಯ ಅತ್ಯಂತ ಸ್ಪಷ್ಟ ಹಳೆಯ ಉದಾಹರಣೆ PPTP. ಅದು 1723 ಪೋರ್ಟ್ನಲ್ಲಿ TCP ನಿಯಂತ್ರಣ ಸಂಪರ್ಕ ತೆರೆದು ನಂತರ ಸುರಂಗ ದತ್ತಾಂಶವನ್ನು GRE ಮೇಲೆ ಸಾಗಿಸುತ್ತದೆ, ಅದು IP ಪ್ರೋಟೋಕಾಲ್ 47. ಪ್ರೋಟೋಕಾಲ್ 47 ಎಂಬುದು TCP ಪೋರ್ಟ್ 47 ಅಲ್ಲ, ಮತ್ತು ಈ ಎರಡು ಸಂಖ್ಯೆಗಳಿಗೆ ಅಂಕಿಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳುವುದನ್ನು ಬಿಟ್ಟು ಒಂದಕ್ಕೊಂದು ಸಂಬಂಧವಿಲ್ಲ.

1723 ಗೆ ಸಂಪರ್ಕ ಪರೀಕ್ಷಿಸಿ ಪೂರ್ಣಗೊಂಡ ಹ್ಯಾಂಡ್ಶೇಕ್ ನೋಡುವ ನಿರ್ವಾಹಕರು ಮಾರ್ಗ ಕೆಲಸ ಮಾಡುತ್ತಿದೆ ಎಂದು ತೀರ್ಮಾನಿಸುತ್ತಾರೆ. ನಂತರ ದತ್ತಾಂಶ ಚಾನಲ್ ಒಂದೂ ಪ್ಯಾಕೆಟ್ ಸಾಗಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಗೇಟ್ವೇ ಬಳಿ ನೀಡಲು GRE ಬೆಂಬಲವಿಲ್ಲ. ಇದು ಹಳೆಯ ಪ್ರೋಟೋಕಾಲ್ನ ಅಗತ್ಯಗಳ ವ್ಯಾಖ್ಯಾನ, ವರ್ಷಗಳಿಂದ ಬಳಕೆಯಲ್ಲಿಲ್ಲದ PPTP ಅನ್ನು ನಿಯೋಜಿಸುವ ಸಲಹೆ ಅಲ್ಲ.

ನಿಯಂತ್ರಣ ಚಾನಲ್ TCP ಅಥವಾ UDP ಆಗಿದ್ದು ದತ್ತಾಂಶ ಮಾರ್ಗ ಹಾಗಿಲ್ಲದ ಯಾವುದೇ ಪ್ರೋಟೋಕಾಲ್ಗೆ ಅದೇ ತರ್ಕ ಅನ್ವಯಿಸುತ್ತದೆ.

IPsec UDP ಆಗಿ ಮಾತ್ರ ಉಳಿಯುತ್ತದೆ

IPsec ಎಂಬುದು ಉತ್ತರ ನೇರ ಇಲ್ಲ ಎಂಬುದಲ್ಲ, ಷರತ್ತುಬದ್ಧವಾಗಿರುವ ಸಂದರ್ಭ. NAT ಗೇಟ್ವೇ ಮೂಲಕ IPsec ಗೆ NAT ಟ್ರಾವರ್ಸಲ್ ಅನ್ನು AWS ಬೆಂಬಲಿತ ವ್ಯವಸ್ಥೆ ಎಂದು ದಾಖಲಿಸುತ್ತದೆ. NAT-T ಮಾತುಕತೆಯಾದಾಗ ESP ಅನ್ನು UDP ಒಳಗೆ ಸುತ್ತಿ ಗೇಟ್ವೇ ಪ್ರೋಟೋಕಾಲ್ 50 ಬದಲಿಗೆ ಸಾಮಾನ್ಯ UDP ನೋಡುತ್ತದೆ.

UDP 4500 ಗೆ ಅನುಮತಿ ನೀಡುವುದರಿಂದ ಎಂಡ್ಪಾಯಿಂಟ್ಗಳು NAT ಟ್ರಾವರ್ಸಲ್ ಬಳಸಲು ಪ್ರಾರಂಭಿಸುವುದಿಲ್ಲ. ಪ್ಯಾಕೆಟ್ಗಳು ಈಗಾಗಲೇ ಆ ರೂಪದಲ್ಲಿದ್ದರೆ ಮಾತ್ರ ಅದು ಅನುಮತಿಸುತ್ತದೆ. ಕ್ಲೈಂಟ್ನ ಸ್ವಂತ ಮಾತುಕತೆ ಔಟ್ಪುಟ್ನಿಂದ ಯಾವ ಎನ್ಕ್ಯಾಪ್ಸುಲೇಶನ್ ಆಯ್ಕೆಯಾಯಿತು ಎಂದು ಖಚಿತಪಡಿಸಿ, ಮತ್ತು ಸ್ವೀಕರಿಸುವ ಬದಿಯಲ್ಲಿ ಸಹವರ್ತಿ ಅದನ್ನು ಸ್ವೀಕರಿಸಿದ್ದನ್ನು ಖಚಿತಪಡಿಸಿ. ಸ್ಥಳೀಯ ESP ಗೆ ಸಂರಚಿಸಿದ ಎರಡು ಎಂಡ್ಪಾಯಿಂಟ್ಗಳು ನಿಯಮಗಳ ಗುಂಪು ಏನೇ ಹೇಳಲಿ ಸ್ಥಳೀಯ ESP ಕಳುಹಿಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತವೆ.

TCP ಅಥವಾ UDP ಆಧಾರಿತ VPN ದಾಖಲಿತ ಸಾಗಣೆ ಗುಂಪಿಗೆ ಹೊಂದುತ್ತದೆ ಮತ್ತು ಆದರೂ ರೂಟಿಂಗ್, ಫಿಲ್ಟರಿಂಗ್ ಅಥವಾ ದೃಢೀಕರಣ ಕಾರಣಗಳಿಂದ ವಿಫಲವಾಗಬಹುದು. ಗುಂಪಿಗೆ ಹೊಂದುವುದು ಅಗತ್ಯ, ಸಾಕಲ್ಲ.

ನೀತಿ ವಿಸ್ತರಿಸುವ ಮೊದಲು ಮಾರ್ಗ ಪರಿಶೀಲಿಸಿ

ಕೆಲಸದ ಉಪಜಾಲದ ನಿಜವಾದ ಮಾರ್ಗ ಮತ್ತು ಅದರ ಮುಂದಿನ ಹಾಪ್ನ ಗುರುತನ್ನು ಮೊದಲು ಪರಿಶೀಲಿಸಿ. ನೇರ ಸಾರ್ವಜನಿಕ ಮಾರ್ಗ, NAT ಇನ್ಸ್ಟಾನ್ಸ್, ನಿರ್ವಹಿತ NAT ಗೇಟ್ವೇ ಮತ್ತು ಟ್ರಾನ್ಸಿಟ್ ಗೇಟ್ವೇ ಮೂಲಕ ಖಾಸಗಿ ಮಾರ್ಗ ನಾಲ್ಕು ವಿಭಿನ್ನ ವಿನ್ಯಾಸಗಳು, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದು ಮಾತ್ರ ಇಲ್ಲಿ ವಿವರಿಸಿದ ನಿರ್ವಹಿತ ಸೇವೆ.

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

ಸೇವೆ ಸಾಗಿಸಲಾರದ ಸಾಗಣೆಯನ್ನು ಸರಿದೂಗಿಸಲು ಎಲ್ಲಾ ಸಂಚಾರ ತೆರೆಯಬೇಡಿ. ನಿಯಮ ಬದಲಾವಣೆ ಅದನ್ನು ಸರಿಪಡಿಸದು, ಮತ್ತು ಅದು ಘಟನೆಯ ನಂತರವೂ ಉಳಿಯುತ್ತದೆ.

ಸಾಗಣೆ ಹೊಂದದಿದ್ದಾಗ

ಬಾಹ್ಯ ಪ್ರೋಟೋಕಾಲ್ ಬೆಂಬಲಿತ ಗುಂಪಿನ ಹೊರಗಿದ್ದರೆ, ಪರಿಹಾರ ವಾಸ್ತುಶಿಲ್ಪದ್ದು: ಮಾರ್ಗ ಸಾಗಿಸಬಲ್ಲ ಸಾಗಣೆಯನ್ನು ಆರಿಸಿ, ಅಥವಾ ನಿಮಗೆ ಬೇಕಾದದ್ದನ್ನು ಸಾಗಿಸುವ ಒಂದಕ್ಕೆ ನಿರ್ಗಮನವನ್ನು ಸರಿಸಿ. OpenVPN UDP ಮೇಲೆ, WireGuard UDP ಮೇಲೆ ಮತ್ತು TLS ಆಧಾರಿತ ಸುರಂಗಗಳು ಎಲ್ಲವೂ ದಾಖಲಿತ ಗುಂಪಿಗೆ ಹೊಂದುತ್ತವೆ. ಗ್ರಾಹಕ ನಿರ್ವಹಿಸುವ NAT ಇನ್ಸ್ಟಾನ್ಸ್ ಒಂದು ನಿರ್ದಿಷ್ಟ ಪ್ರೋಟೋಕಾಲ್ ಹಾದುಹೋಗಬೇಕಾದಾಗ ಮತ್ತು ಅದನ್ನು ನಡೆಸುವ ಕಾರ್ಯಾಚರಣೆ ವೆಚ್ಚ ಸ್ವೀಕಾರಾರ್ಹವಾದಾಗ ಆಯ್ಕೆ.

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

ಕೆಲಸದ ಕ್ರಮ: ಬಾಹ್ಯ ಪ್ರೋಟೋಕಾಲ್ ಹೆಸರಿಸಿ, ಮುಂದಿನ ಹಾಪ್ ಖಚಿತಪಡಿಸಿ, ದಾಖಲಿತ ಗುಂಪಿನೊಂದಿಗೆ ಹೋಲಿಸಿ, ನಂತರ ವಾಸ್ತುಶಿಲ್ಪ ಅಥವಾ ಸಾಗಣೆ ಬದಲಿಸಿ. ಬೇರೆ ಪೋರ್ಟ್ ಸಂಖ್ಯೆ GRE ಅನ್ನು TCP ಆಗಿಸಲಾರದು, ಮತ್ತು ಇನ್ನೊಂದು ಅನುಮತಿಸುವ ನಿಯಮ ಪೂರ್ಣಗೊಂಡ ನಿಯಂತ್ರಣ ವಿನಿಮಯವನ್ನು ಕೆಲಸ ಮಾಡುವ ದತ್ತಾಂಶ ಚಾನಲ್ ಆಗಿಸಲಾರದು.