AWS Client VPN DNS: subnet ಅಲ್ಲ, VPC resolver ಬಳಸಿ

endpoint 10.0.8.0/24 ನಲ್ಲಿದೆ, ಆದ್ದರಿಂದ resolver 10.0.8.2 ಆಗಿರಬೇಕು. ಇದು ನಾನು ಹೆಚ್ಚು ಕೇಳುವ ತರ್ಕ, ಮತ್ತು ಇದು ಎರಡು ಬಾರಿ ತಪ್ಪು. Route 53 Resolver ಪ್ರಾಥಮಿಕ VPC IPv4 ಶ್ರೇಣಿ ಪ್ಲಸ್ ಎರಡರಲ್ಲಿ ಉತ್ತರಿಸುತ್ತದೆ, ಅದು 10.0.0.0/16 ನ VPC ಗೆ 10.0.0.2, endpoint ಯಾವ subnet ಬಳಸಿದರೂ. ಎರಡನೇ ತಪ್ಪು ಹೆಚ್ಚು ಮೌನವಾಗಿದೆ: endpoint ನಲ್ಲಿ ಸರಿಯಾದ ವಿಳಾಸ ಹಾಕುವುದು client ನ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಅದನ್ನು ಎಂದಾದರೂ ಏನಾದರೂ ಕೇಳುತ್ತದೆ ಎಂದು ಅರ್ಥವಲ್ಲ. ಎರಡೂ ತಪ್ಪುಗಳು ಒಂದೇ ಲಕ್ಷಣ ನೀಡುತ್ತವೆ: ಹೆಸರು ರೆಸಲ್ಯೂಶನ್ ಕೆಲವು client ಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಇತರರಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ.

ಪುರಾಣ subnet ಸಂಬಂಧದಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ

ಸಂಬಂಧ ಎಂದರೆ client ಸಂಪರ್ಕಗಳಿಗೆ elastic network interfaces ಎಲ್ಲಿವೆ ಎಂಬುದು, ಯಾವ resolver ವಿಳಾಸ ಇದೆ ಎಂಬುದಲ್ಲ. endpoint ನ subnet ಗಳು client ಗಳಿಗೆ VPC ಒಳಗೆ ವಿಳಾಸ ನೀಡುತ್ತವೆ, ಮತ್ತು ಪ್ರತಿಯೊಂದೂ ತನ್ನದೇ resolver ಹೊಂದಿರುವುದಿಲ್ಲ.

ಆ ಎರಡು ಕಲ್ಪನೆಗಳನ್ನು ಬೇರ್ಪಡಿಸಿದರೆ, ಗಣಿತ ರಹಸ್ಯವಾಗಿರುವುದು ನಿಲ್ಲುತ್ತದೆ ಮತ್ತು ಸಮಸ್ಯೆ ಪರಿಹಾರ client ನ ಬಳಿಗೆ ಹೋಗುತ್ತದೆ, ಈ ಪ್ರಕರಣಗಳ ಬಹುಪಾಲು ನಿಜವಾಗಿ ಅಲ್ಲಿಯೇ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ.

ಪ್ರಾಥಮಿಕ VPC ಶ್ರೇಣಿಯಿಂದ ವಿಳಾಸ ಲೆಕ್ಕ ಹಾಕಿ

VPC ನ ಪ್ರಾಥಮಿಕ IPv4 CIDR ತೆಗೆದುಕೊಂಡು network ವಿಳಾಸಕ್ಕೆ ಎರಡು ಸೇರಿಸಿ. 10.0.0.0/16 10.0.0.2 ನೀಡುತ್ತದೆ, 172.31.0.0/16 172.31.0.2 ನೀಡುತ್ತದೆ, ಮತ್ತು ದ್ವಿತೀಯ ಶ್ರೇಣಿ ಇರುವ VPC resolver ಅನ್ನು ಪ್ರಾಥಮಿಕದಲ್ಲೇ ಇಡುತ್ತದೆ. ಆ VPC ಒಳಗಿನ 10.0.8.0/24 subnet ಅದನ್ನು ಸರಿಸುವುದಿಲ್ಲ. endpoint ಮುಟ್ಟುವ ಮೊದಲು VPC ID ಪಕ್ಕದಲ್ಲಿ ವಿಳಾಸ ಬರೆಯಿರಿ, ಏಕೆಂದರೆ ಸಂಖ್ಯೆ VPC ಯ ಗುಣ, ಸಂಪರ್ಕದ್ದಲ್ಲ.

VPC link-local ವಿಳಾಸ 169.254.169.253 ನಲ್ಲೂ ಉತ್ತರಿಸುತ್ತದೆ. ಈ ವಿಳಾಸ VPC ಒಳಗಿನಿಂದ ತಲುಪಬಹುದು, ಆದರೆ tunnel ನ ಇನ್ನೊಂದು ತುದಿಯಲ್ಲಿರುವ ಲ್ಯಾಪ್ಟಾಪ್‌ಗೆ ಇದು ಸಾಮಾನ್ಯ ರೂಟ್ ಆದ ಗಮ್ಯಸ್ಥಾನವಲ್ಲ.

ಆದ್ದರಿಂದ ಎರಡು ಮಾನ್ಯ resolver ವಿಳಾಸಗಳಿವೆ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ subnet ಪ್ಲಸ್ ಎರಡು ಅಲ್ಲ.

endpoint ಸೆಟ್ಟಿಂಗ್ ಏನು ಮಾಡುತ್ತದೆ, ಏನು ಮಾಡುವುದಿಲ್ಲ

Client VPN endpoint ನಲ್ಲಿ DNS ಸರ್ವರ್ ಕ್ಷೇತ್ರಗಳಿವೆ, ಮತ್ತು console VPC resolver ಆಯ್ಕೆ ನೀಡುವಲ್ಲಿ ಅದೇ ಕಲ್ಪನೆಯನ್ನು ತುಂಬುತ್ತದೆ. ಅವನ್ನು ಸೆಟ್ ಮಾಡುವುದು ಸಂಪರ್ಕ ಸ್ಥಾಪನೆಯ ಸಮಯದಲ್ಲಿ ಸೇವೆ client ಗಳಿಗೆ ಏನು ನೀಡುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಿಸುತ್ತದೆ. ಅನ್‌ಮ್ಯಾನೇಜ್ಡ್ OpenVPN client ಆ ಮೌಲ್ಯದೊಂದಿಗೆ ಏನು ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಇದು ಬದಲಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ client ಅದನ್ನು ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗೆ ಅನ್ವಯಿಸಬೇಕು. «ನನ್ನ Mac ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಆದರೆ Linux ಬಾಕ್ಸ್‌ನಲ್ಲಿ ಇಲ್ಲ» ಎಂಬುದು ಈ ಕಂದರದಿಂದ ಬರುತ್ತದೆ.

Linux ನಲ್ಲಿ resolver ಏಕೀಕರಣ connection manager ನ ಮಾಲೀಕತ್ವ, ಬಳಕೆದಾರರದ್ದಲ್ಲ. /etc/resolv.conf ಅನ್ನು ಕೈಯಿಂದ ಸಂಪಾದಿಸುವುದು ವಿಳಾಸ ಒಂದು ಸೆಷನ್‌ಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ಸಾಬೀತು ಮಾಡುತ್ತದೆ, ನಂತರ ಮರುಸಂಪರ್ಕದಲ್ಲಿ ಮಾಯವಾಗುತ್ತದೆ — ಆದ್ದರಿಂದ ಸರಿಪಡಿಸಿದ ಅನೇಕ ಪ್ರಕರಣಗಳು ಮರುದಿನ ಬೆಳಿಗ್ಗೆ ಮತ್ತೆ ಬರುತ್ತವೆ.

ಸಂಪರ್ಕಿಸಿದ ನಂತರ client ನಲ್ಲಿ ಸಕ್ರಿಯ resolver ಪರಿಶೀಲಿಸಿ, endpoint ನ ಸಂರಚನಾ ಪುಟವಲ್ಲ.

split tunneling ಸರಿಯಾದ resolver ಅನ್ನು ಸೋಲಿಸಬಹುದು

split tunneling ನಲ್ಲಿ tunnel ಗೆ ತಳ್ಳಿದ ಮಾರ್ಗಗಳನ್ನು ಮಾತ್ರ ಬಳಸಲಾಗುತ್ತದೆ. resolver ವಿಳಾಸ ಯಾವುದೇ ಮಾರ್ಗದಿಂದ ಆವರಿಸದಿದ್ದರೆ, query ಸ್ಥಳೀಯ ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ಹೊರಹೋಗಿ ನಿಮ್ಮ ಮನೆ ರೂಟರ್ ಉತ್ತರಿಸುತ್ತದೆ. endpoint ನ ವಿಳಾಸ ಇನ್ನೂ ಸರಿ ಮತ್ತು ಹುಡುಕಾಟ ಇನ್ನೂ ವಿಫಲ. resolver ಗೆ ಮಾರ್ಗ ಸೇರಿಸಿ, ನಂತರ ಮತ್ತೆ ಪರೀಕ್ಷಿಸಿ.

ಅತಿಕ್ರಮಿಸುವ ಸ್ಥಳೀಯ ಶ್ರೇಣಿಗಳು ಅದೇ ಫಲಿತಾಂಶವನ್ನು ಹೆಚ್ಚು ಕಿರಿಕಿರಿಯ ರೀತಿಯಲ್ಲಿ ನೀಡುತ್ತವೆ: query ಗೆ ಉತ್ತರ ಸಿಗುತ್ತದೆ, ಬರೀ ತಪ್ಪು ಸರ್ವರ್‌ನಿಂದ.

Amazon DNS ವಿಳಾಸಕ್ಕಾಗಿ security groups ತೆರೆಯಬೇಡಿ

ಹುಡುಕಾಟಗಳು ಸಮಯ ಮೀರಿದಾಗ ಪ್ರವೃತ್ತಿ resolver ವಿಳಾಸಕ್ಕೆ UDP 53 ಅನುಮತಿಸುವ ನಿಯಮ ಸೇರಿಸುವುದು. security groups ಮತ್ತು network ACL ಗಳು Amazon DNS ಸಂಚಾರವನ್ನು ಕಸ್ಟಮ್ DNS ಇನ್ಸ್ಟಾನ್ಸ್‌ಗೆ ಇರುವ ಸಂಚಾರದಂತೆ ಫಿಲ್ಟರ್ ಮಾಡುವುದಿಲ್ಲ ಎಂದು AWS ದಾಖಲಿಸುತ್ತದೆ. ಆ ನಿಯಮಗಳನ್ನು ತೆರೆಯುವುದು VPC resolver ಗೆ ಏನನ್ನೂ ಬದಲಿಸುವುದಿಲ್ಲ ಮತ್ತು ಗಡಿಯನ್ನು ಕಾರಣವಿಲ್ಲದೆ ವಿಸ್ತರಿಸುತ್ತದೆ. ನೀವೇ ನಡೆಸುವ resolver ಬೇರೆ ಪ್ರಕರಣ ಮತ್ತು ಅದಕ್ಕೆ ನಿಜವಾಗಿಯೂ ತನ್ನದೇ ನಿಯಮಗಳು ಬೇಕು.

ನಿಮ್ಮ ವಿನ್ಯಾಸದಲ್ಲಿ ಎರಡೂ ಇದ್ದರೆ, ಯಾವುದೇ ನಿಯಮ ಸಂಪಾದಿಸುವ ಮೊದಲು client ನಿಜವಾಗಿ ಯಾವುದಕ್ಕೆ ತೋರಿಸುತ್ತಿದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ.

ಮಾರ್ಗ ಪರಿಶೀಲಿಸಿ, ನಂತರ ಬೇರೆ ಏನಾದರೂ ಅಳೆಯಿರಿ

ಸಾರ್ವಜನಿಕ ಹೆಸರು ಪರಿಹರಿಸಿ, VPC ಗೆ ಸಂಬಂಧಿಸಿದ ಖಾಸಗಿ ಹೋಸ್ಟೆಡ್ ವಲಯದಲ್ಲಿ ನೋಂದಾಯಿಸಲಾದ ಖಾಸಗಿ ಹೆಸರು ಪರಿಹರಿಸಿ, ಮತ್ತು ಎರಡರ ನಡುವೆ client ನ ಸಕ್ರಿಯ resolver ಓದಿ. ಈ ಕ್ರಮ «resolver ವಿಳಾಸ ತಪ್ಪು» ಎಂಬುದನ್ನು «ವಲಯ ಸಂಬಂಧಿಸಿಲ್ಲ» ಮತ್ತು «client ಸೆಟ್ಟಿಂಗ್ ನಿರ್ಲಕ್ಷಿಸಿದೆ» ಎಂಬುದರಿಂದ ಬೇರ್ಪಡಿಸುತ್ತದೆ. ಪ್ರತಿಯೊಂದಕ್ಕೂ ಬೇರೆ ಪರಿಹಾರ, ಮತ್ತು ಯಾವುದೂ throughput ಸಮಸ್ಯೆ ಅಲ್ಲ.

ಯಶಸ್ವಿ ಹುಡುಕಾಟ ನಿರಂತರ ವರ್ಗಾವಣೆ ವೇಗದ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ವರದಿ ಮಾಡುವಾಗ ಈ ಎರಡು ಸಂಭಾಷಣೆಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿಡಿ.