ಸ್ಥಳೀಯ ಡೇಟಾಬೇಸ್ ಕ್ಲೈಂಟ್ ಮತ್ತು ಖಾಸಗಿ RDS: ಸಂಪರ್ಕವು ಏಕೆ ಸಮಯ ಮೀರಿ ಹೋಗುತ್ತದೆ

ಒಬ್ಬ ಡೆವಲಪರ್ನ ಲ್ಯಾಪ್ಟಾಪ್ ಖಾಸಗಿ RDS ಎಂಡ್ಪಾಯಿಂಟ್ಗೆ ಸಂಪರ್ಕಿಸುವಾಗ ಸಮಯ ಮೀರಿ ಹೋಗುತ್ತದೆ, ಆದರೆ ಅದೇ ರುಜುವಾತುಗಳು ಬ್ಯಾಸ್ಟಿಯನ್ ಹೋಸ್ಟ್ನಿಂದ ಕೆಲಸ ಮಾಡುತ್ತವೆ. ಏನೂ ಕೆಳಗೆ ಬಿದ್ದಿಲ್ಲ. ಆ ಲ್ಯಾಪ್ಟಾಪ್ ಮತ್ತು ಡೇಟಾಬೇಸ್ ನಡುವಿನ ಮಾರ್ಗಕ್ಕೆ ಮೂರರಲ್ಲಿ ಒಂದು ಕೊರತೆ ಇದೆ: ಪರಿಹರಿಸುವ ಹೆಸರು, ಸಂಚಾರವನ್ನು ಹೊತ್ತೊಯ್ಯುವ ಮಾರ್ಗ, ಅಥವಾ ಡೇಟಾಬೇಸ್ ನಿಜವಾಗಿ ನೋಡುವ ಮೂಲವನ್ನು ಅನುಮತಿಸುವ ಭದ್ರತಾ ಗುಂಪಿನ ನಿಯಮ. ಉಳಿದ ಎರಡನ್ನು ಬದಲಿಸುವ ಮೊದಲು ಯಾವುದು ಕೊರತೆ ಎಂದು ಕಂಡುಹಿಡಿಯಿರಿ.

ಸರಿಯಾದ ಪದರದಲ್ಲಿ ವಿಫಲತೆಯನ್ನು ಓದಿ

ಸಮಯ ಮೀರುವಿಕೆ ಒಂದೇ ದೋಷವಲ್ಲ. ಪರಿಹರಿಸದ ಹೆಸರು ಪ್ಯಾಕೆಟ್ ಯಂತ್ರವನ್ನು ಬಿಡುವ ಮೊದಲೇ ವಿಫಲವಾಗುತ್ತದೆ. ಮಾರ್ಗವಿಲ್ಲದ ವಿಳಾಸ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಕಪ್ಪು ಕುಳಿಗೆ ಕಳುಹಿಸುತ್ತದೆ. ಫಿಲ್ಟರ್ ಮಾಡಿದ ಪೋರ್ಟ್ ತಪ್ಪು ಹೋಸ್ಟ್ನಂತೆಯೇ ಕಾಣುವ ಕಾಯುವಿಕೆಯನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. ಹಂತಗಳನ್ನು ಕ್ರಮವಾಗಿ ನಿರ್ವಹಿಸಿ ಮತ್ತು ಮೊದಲು ವಿಫಲವಾಗುವ ಹಂತದಲ್ಲಿ ನಿಲ್ಲಿಸಿ.

dig +short db.internal.example
nc -vz db.internal.example 5432

ಹೆಸರು ಸಾರ್ವಜನಿಕ ವಿಳಾಸವನ್ನು ಹಿಂತಿರುಗಿಸಿದರೆ, ಅಥವಾ ಏನನ್ನೂ ಹಿಂತಿರುಗಿಸದಿದ್ದರೆ, ಸುರಂಗ ಇನ್ನೂ ಸಮಸ್ಯೆಯಲ್ಲ.

ಹೆಸರು ಪರಿಹರಿಸಿ ಪೋರ್ಟ್ ಪರೀಕ್ಷೆ ನೇತಾಡಿದರೆ, ನೀವು ಪರಿಹರಿಸಿದ ವಿಳಾಸವನ್ನು ಡೇಟಾಬೇಸ್ ವರದಿ ಮಾಡುವ ವಿಳಾಸದೊಂದಿಗೆ ಹೋಲಿಸಿ. ನಿರ್ವಹಿತ ಎಂಡ್ಪಾಯಿಂಟ್ VPC ಒಳಗೆ ಖಾಸಗಿ ವಿಳಾಸಕ್ಕೆ ಮತ್ತು ಹೊರಗೆ ಯಾವುದೇ ಉಪಯುಕ್ತವಲ್ಲದ್ದಕ್ಕೆ ಪರಿಹರಿಸಬಹುದು, ಮತ್ತು ಹಳೆಯ ಹುಡುಕಾಟದಿಂದ ನಕಲಿಸಿದ ವಿಳಾಸವು ಇನ್ನು ಉತ್ತರಿಸದ ಹೋಸ್ಟ್ ಅನ್ನು ತೋರಿಸುತ್ತದೆ.

ಸುರಂಗವನ್ನು ಮಾರ್ಗದಿಂದ ಬೇರ್ಪಡಿಸಿ

ಕ್ಲೈಂಟ್ VPN ಸಂಪರ್ಕಿಸುವುದು ಪ್ರತಿ ಖಾಸಗಿ ಶ್ರೇಣಿಯನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಮಾರ್ಗದರ್ಶಿಸುವುದಿಲ್ಲ. ಪ್ರೊಫೈಲ್ ಸೇವೆ ತಳ್ಳುವ ಮಾರ್ಗಗಳನ್ನು ಹೊತ್ತೊಯ್ಯುತ್ತದೆ, ಮತ್ತು ಕ್ಲೈಂಟ್ ಅವುಗಳಲ್ಲಿ ಕೆಲವನ್ನು ಮಾತ್ರ ಸ್ಥಾಪಿಸಬಹುದು. ಕ್ಲೈಂಟ್ ನಿಜವಾಗಿ ಯಾವ ಶ್ರೇಣಿಗಳನ್ನು ಸೇರಿಸಿದೆ ಮತ್ತು ಡೇಟಾಬೇಸ್ ವಿಳಾಸ ಅವುಗಳಲ್ಲಿ ಒಂದರೊಳಗೆ ಬರುತ್ತದೆಯೇ ಎಂದು ನೋಡಿ.

ip route get 10.20.40.15
ip addr show tun0

ಸುರಂಗ ಇಂಟರ್ಫೇಸ್ ಕಡೆಗೆ ತೋರಿಸುವ ಮಾರ್ಗ ಅಗತ್ಯ; ಅದು ಸಾಕಲ್ಲ, ಏಕೆಂದರೆ ಆಚೆಯ ಬದಿ ಇನ್ನೂ ಸಂಚಾರವನ್ನು ಸ್ವೀಕರಿಸಬೇಕು.

ಸ್ಪ್ಲಿಟ್-ಸುರಂಗ ಪ್ರೊಫೈಲ್ಗಳು ಈ ಅರ್ಧ ವಿಫಲತೆಯ ಸಾಮಾನ್ಯ ಮೂಲ. ಅವು ಪ್ರೊಫೈಲ್ ವಿನ್ಯಾಸಗೊಂಡ ಅಪ್ಲಿಕೇಶನ್ಗೆ ಕೆಲಸ ಮಾಡುತ್ತವೆ ಮತ್ತು ಡೇಟಾಬೇಸ್ ಶ್ರೇಣಿಯನ್ನು ಸುರಂಗದ ಹೊರಗೆ ಬಿಡುತ್ತವೆ, ಇದು ಫೈರ್ವಾಲ್ ಉಂಟುಮಾಡುವ ಸಮಯ ಮೀರುವಿಕೆಯನ್ನೇ ಉಂಟುಮಾಡುತ್ತದೆ.

ಭದ್ರತಾ ಗುಂಪನ್ನು ನಿಜವಾದ ಮೂಲಕ್ಕೆ ಹೊಂದಿಸಿ

RDS ಭದ್ರತಾ ಗುಂಪು ಜನರಿಗಲ್ಲ, ಮೂಲಗಳಿಗೆ ಅನುಮತಿ ನೀಡುತ್ತದೆ. ವಾಸ್ತುಶಿಲ್ಪದ ಪ್ರಕಾರ ಮೂಲವು VPN ಕ್ಲೈಂಟ್ ಪೂಲ್, ಬ್ಯಾಸ್ಟಿಯನ್ನ ಖಾಸಗಿ ವಿಳಾಸ, ಅಥವಾ ಸಂಚಾರವು ಅನುವಾದಗೊಳ್ಳುವ NAT ವಿಳಾಸವಾಗಿರಬಹುದು. ನಿಯಮ ಮತ್ತು ಪ್ಯಾಕೆಟ್ನ ನಿಜವಾದ ಮೂಲವನ್ನು ಒಟ್ಟಿಗೆ ಓದಿ.

aws ec2 describe-security-groups --group-ids sg-0123456789abcdef0 \
  --query 'SecurityGroups[].IpPermissions'

ಒಂದು ಲ್ಯಾಪ್ಟಾಪ್ನ ಮನೆ ವಿಳಾಸಕ್ಕೆ ಇರುವ ನಿಯಮ ಪ್ರವೇಶ ವಿನ್ಯಾಸವಲ್ಲ, ನಿರ್ವಹಣಾ ಸಮಸ್ಯೆ.

ಮಾರ್ಗದಲ್ಲಿ ಕ್ಲೈಂಟ್ VPN ಅಥವಾ NAT ಗೇಟ್ವೇ ಇದ್ದಾಗ, ಡೇಟಾಬೇಸ್ ಡೆವಲಪರ್ನ ಸುರಂಗ ವಿಳಾಸದ ಬದಲು ಅನುವಾದಕನ ವಿಳಾಸವನ್ನು ನೋಡಬಹುದು. ಆದ್ದರಿಂದ ಕೆಲಸ ಮಾಡುವ ಬ್ಯಾಸ್ಟಿಯನ್ ಸಂರಚನೆಯಿಂದ ನಕಲಿಸಿದ ನಿಯಮ ಲ್ಯಾಪ್ಟಾಪ್ಗೆ ವಿಫಲವಾಗಬಹುದು: ಎರಡೂ ಮಾರ್ಗಗಳು ಬೇರೆ ಬೇರೆ ಮೂಲಗಳಿಂದ ಬರುತ್ತವೆ, ಆದರೂ ಎರಡೂ ಒಳಗಿನವು ಎಂದು ಕಾಣುತ್ತವೆ.

ಅಗಲವಾದ ಮಾರ್ಗಕ್ಕಿಂತ ಸಂಕುಚಿತ ಮಾರ್ಗವನ್ನು ಆರಿಸಿ

ಒಬ್ಬ ಡೆವಲಪರ್ಗೆ ಒಂದು ಡೇಟಾಬೇಸ್ ಬೇಕಾದಾಗ, ಸೆಷನ್ ಆಧಾರಿತ ಫಾರ್ವರ್ಡಿಂಗ್ ಸಂಪೂರ್ಣ ನೆಟ್ವರ್ಕ್ ಸುರಂಗಕ್ಕಿಂತ ನಿರ್ವಹಿಸಲು ಅಗ್ಗವಾಗಿರುತ್ತದೆ. ಸ್ಥಳೀಯ ಕ್ಲೈಂಟ್ ಫಾರ್ವರ್ಡ್ ಮಾಡಿದ ಪೋರ್ಟ್ಗೆ ಸಂಪರ್ಕಿಸುತ್ತದೆ, ಮತ್ತು ದೂರದ ಘಟಕ ನೆಟ್ವರ್ಕ್ನ ಒಳಗಿನಿಂದ ಡೇಟಾಬೇಸ್ ಸಂಪರ್ಕವನ್ನು ಮಾಡುತ್ತದೆ.

ssh -N -L 5432:db.internal.example:5432 bastion.internal.example

ಆ ವಿನ್ಯಾಸದಲ್ಲಿ TLS ಪರಿಶೀಲನೆಯನ್ನು ಅಕ್ಷತವಾಗಿ ಇರಿಸಿ. ಕ್ಲೈಂಟ್ ಇನ್ನೂ ನಿರೀಕ್ಷಿಸುವ ಹೆಸರಿನ ವಿರುದ್ಧ ಸರ್ವರ್ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಪರಿಶೀಲಿಸಬೇಕು; ಸ್ಥಳೀಯ ಫಾರ್ವರ್ಡ್ ಮಾಡಿದ ಪೋರ್ಟ್ ಪರಿಶೀಲನೆಯನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವ ಕಾರಣವಲ್ಲ, ಮತ್ತು ಅದನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವುದು ಹಿಡಿಯಲು ಯೋಗ್ಯವಾದ ಗುರುತಿನ ಸಮಸ್ಯೆಯನ್ನೇ ಮರೆಮಾಡುತ್ತದೆ.

ಸಂಪೂರ್ಣ ಸುರಂಗ ಮತ್ತು ಸಂಕುಚಿತ ಫಾರ್ವರ್ಡಿಂಗ್ ನಡುವಿನ ಆಯ್ಕೆ ಭದ್ರತಾ ನಾಟಕವಲ್ಲ, ವ್ಯಾಪ್ತಿಯ ಬಗ್ಗೆ ನಿರ್ಣಯ.

ಹಿಂದೆ ಪುನರಾವರ್ತಿಸಬಹುದಾದ ಮಾರ್ಗವನ್ನು ಬಿಡಿ

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

ನಂತರ ಋಣಾತ್ಮಕ ಪ್ರಕರಣವನ್ನು ಒಮ್ಮೆ ಪರೀಕ್ಷಿಸಿ: ಅನುಮೋದಿತ ಮೂಲದ ಹೊರಗಿನ ಕ್ಲೈಂಟ್ ಇನ್ನೂ ನಿರಾಕರಿಸಬೇಕು.

ತಾನೇ ಸಿದ್ಧಪಡಿಸಿದ ವ್ಯಕ್ತಿಗೆ ಮಾತ್ರ ಕೆಲಸ ಮಾಡುವ ಖಾಸಗಿ ಡೇಟಾಬೇಸ್ ಖಾಸಗಿ ಪ್ರವೇಶವಲ್ಲ; ಅದು ಮತ್ತೆ ಕಂಡುಹಿಡಿಯಲು ಕಾಯುತ್ತಿರುವ ದಾಖಲಿಸದ ವಿನಾಯಿತಿ. ಮಾರ್ಗವನ್ನು ಬರೆಯಿರಿ, ಮತ್ತು ಮುಂದಿನ ಡೆವಲಪರ್ ಒಗಟಿನ ಬದಲು ವಿಧಾನವನ್ನು ಬಳುವಳಿಯಾಗಿ ಪಡೆಯುತ್ತಾನೆ.