ಖಾಸಗಿ VPN ಹೆಸರುಗಳು ವಿಫಲವಾಗುತ್ತಿವೆಯೇ? ಸಂದೇಹ DNS ರೀಬೈಂಡ್ ಸಂರಕ್ಷಣೆ ಮೇಲೆ

ಕಚೇರಿ LAN ನಲ್ಲಿ ಒಳಗಿನ ಹೆಸರು ತಕ್ಷಣ ಉತ್ತರಿಸುತ್ತದೆ. VPN ಆನ್ ಆದ ಕ್ಷಣವೇ ಅದು ಕೆಲಸ ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ, ಅಪ್ಲಿಕೇಶನ್ ಟೈಮೌಟ್ ವರದಿ ಮಾಡುತ್ತದೆ, ಟನೆಲ್ ಸ್ವತಃ ದೂರಿಲ್ಲದೆ ಟ್ರಾಫಿಕ್ ಸಾಗಿಸುತ್ತಿದೆ. ಬದಲಾದದ್ದು ರೆಸಾಲ್ವರ್, ಮತ್ತು ಆ ರೆಸಾಲ್ವರ್ಗೆ ಖಾಸಗಿ ವಿಳಾಸಗಳ ಬಗ್ಗೆ ತನ್ನದೇ ಅಭಿಪ್ರಾಯವಿದೆ.

ರೀಬೈಂಡ್ ಸಂರಕ್ಷಣೆ ಒಂದು ನಿರ್ದಿಷ್ಟ ಉಪಾಯವನ್ನು ನಿಲ್ಲಿಸಲು ಇದೆ. ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಪ್ರಕಟಿಸಿದ ಖಾಸಗಿ ಹೆಸರು ಸಂರಕ್ಷಣೆ ಸಕ್ರಿಯವಾಗುವಷ್ಟು ಹೋಲುತ್ತದೆ.

ನೀತಿಯನ್ನು ಓದುವ ಮೊದಲು ಉತ್ತರವನ್ನು ಓದಿ

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

ರೋಗಲಕ್ಷಣಗಳು ಒಂದರ ಮೇಲೊಂದು ಬರುತ್ತವೆ, ಆದ್ದರಿಂದ ಉತ್ತರದ ಆಕಾರವೇ ನಿರ್ಣಯವನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. NXDOMAIN ಎಂದರೆ ಕಾಣೆಯಾದ ದಾಖಲೆ, REFUSED ಎಂದರೆ ಪ್ರವೇಶ ನಿಯಮ, ಒಳಗಿನ ಹೆಸರಿಗೆ ಸಾರ್ವಜನಿಕ ವಿಳಾಸ ಎಂದರೆ ನೀತಿ ಅಥವಾ split-DNS ದೋಷ, ಮತ್ತು ಕ್ಲೈಂಟ್ ಬಳಸಲಾಗದ ಸರಿಯಾದ ಖಾಸಗಿ ವಿಳಾಸ ಸಂಪೂರ್ಣ ಬೇರೆ ಸಮಸ್ಯೆ. ನಿರಾಕರಿಸಿದ ಸಂಪರ್ಕ ಅಥವಾ ನಿಂತಿರುವ ವಿನಂತಿ ತನ್ನಷ್ಟಕ್ಕೇ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಇಂತಹ ಟಿಕೆಟ್ಗಳಲ್ಲಿ ಮೊದಲ ಆಜ್ಞೆ ಮರುಪ್ರಾರಂಭವಲ್ಲ, ಹುಡುಕಾಟವಾಗಿರಬೇಕು. ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ಉತ್ತರವನ್ನು ಬರೆದಿಡಿ.

ಸಂರಕ್ಷಣೆ ನಿಜವಾಗಿ ಏನನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ

DNS ರೀಬೈಂಡ್ ಕ್ಲೈಂಟ್ ಈಗಾಗಲೇ ಹೆಸರನ್ನು ನಂಬಿದ ನಂತರ ಅದು ಯಾವುದಕ್ಕೆ ಪರಿಹರಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಿಸುವ ಮೂಲಕ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ದಾಳಿಕೋರ ನಿಯಂತ್ರಿಸುವ ಹೆಸರಿನಿಂದ ಪುಟ ಲೋಡ್ ಆಗುತ್ತದೆ, ಉತ್ತರ ಖಾಸಗಿ ವಿಳಾಸಕ್ಕೆ ತಿರುಗುತ್ತದೆ, ಮತ್ತು ಬ್ರೌಸರ್ ಸ್ಥಳೀಯ ಜಾಲದಲ್ಲಿನ, ಅದು ಎಂದಿಗೂ ನೇರ ಸಂಪರ್ಕವನ್ನು ಒಪ್ಪಿಕೊಳ್ಳದ ಯಾವುದೋ ಒಂದರೊಂದಿಗೆ ಮಾತನಾಡಲು ಮೋಸಹೋಗುತ್ತದೆ. ರೆಸಾಲ್ವರ್ಗೆ ಖಾಸಗಿ ಹೆಸರಿನ ಜಾಗಕ್ಕೆ ಸೇವೆ ಸಲ್ಲಿಸಲು ಎಂದಿಗೂ ಕೇಳದಿದ್ದಾಗ ಖಾಸಗಿ ಜಾಗಕ್ಕೆ ಬೆರಳಿಡುವ ಉತ್ತರಗಳನ್ನು ನಿರಾಕರಿಸುವುದೇ ಸಂರಕ್ಷಣೆ. ಆ ಅಸಮಮಿತಿಯೇ ಇಡೀ ದಾಳಿ.

dnsmasq ನಿಖರವಾಗಿ ಆ ವರ್ತನೆಯನ್ನು, ಪ್ರತಿ ಡೊಮೇನ್ ವಿನಾಯಿತಿಗಳೊಂದಿಗೆ ದಾಖಲಿಸುತ್ತದೆ. ತನ್ನ ಕೈಪಿಡಿಯಲ್ಲಿ ಅದು rebind-domain-ok ಅನ್ನು ಅಂತಹ ವಿಳಾಸಗಳನ್ನು ಕಾನೂನುಬದ್ಧವಾಗಿ ಹಿಂತಿರುಗಿಸಬಹುದಾದ ಡೊಮೇನ್ಗಳನ್ನು ಹೆಸರಿಸುವ ಮಾರ್ಗವಾಗಿ ವಿವರಿಸುತ್ತದೆ. ಉದ್ದೇಶಿತ ಪರಿಹಾರವು ವ್ಯಾಪ್ತಿಗೊಳಿಸಿದ ಅನುಮತಿ, ಜಾಗತಿಕ ಸ್ವಿಚ್ ಅಲ್ಲ ಎಂಬ ಸೂಚನೆಯಾಗಿ ಅದನ್ನು ಓದಿ.

ವಿನಾಯಿತಿಯನ್ನು ಹೆಸರಿನ ಜಾಗಕ್ಕೆ ಸೀಮಿತಗೊಳಿಸಿ

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

# ask the resolver the VPN pushed, and show the full answer
dig +noall +answer db.corp.example @10.40.0.1
dig +short db.corp.example @10.40.0.1

# dnsmasq: what does the running configuration already allow?
grep -R 'rebind' /etc/dnsmasq.d /etc/dnsmasq.conf

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

Split DNS ಅದೇ ನಿರ್ಣಯದ ಭಾಗ. ಖಾಸಗಿ ಹೆಸರಿನ ಜಾಗಕ್ಕೆ ಒಳಗಿನ ರೆಸಾಲ್ವರ್ನಲ್ಲೇ ಉತ್ತರಿಸಬೇಕಿದ್ದರೆ, ಅಲ್ಲೇ ಪ್ರಕಟಿಸಿ ಮತ್ತು ಸಾರ್ವಜನಿಕ ರೆಸಾಲ್ವರ್ಗಳಿಗೆ ಸೋರಿಕೆಯಾಗುವುದನ್ನು ನಿಲ್ಲಿಸಿ, ಆಗ ವಿನಾಯಿತಿ ಪ್ರತಿ ಮಾರ್ಗವಲ್ಲ, ಒಂದು ಮಾರ್ಗವನ್ನು ಆವರಿಸುತ್ತದೆ.

ಸಂಪನ್ಮೂಲ ಮತ್ತು ಸಂರಕ್ಷಣೆಯನ್ನು ಮತ್ತೆ ಪರೀಕ್ಷಿಸಿ

ಮತ್ತೆ ಪ್ರಶ್ನಿಸಿ, ನಂತರ ಸೇವೆಗೆ ಸಂಪರ್ಕಿಸಿ ಕ್ಲೈಂಟ್ ಏನನ್ನು ನೋಡುತ್ತದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ. ಕೆಲಸ ಮಾಡುವ ಅವಧಿಯೊಂದಿಗೆ ಸರಿಯಾದ ಖಾಸಗಿ ಉತ್ತರ ಎಂದರೆ ವಿನಾಯಿತಿ ಜಾರಿಗೆ ಬಂದಿದೆ. ನಿಂತಿರುವ ಅವಧಿಯೊಂದಿಗೆ ಸರಿಯಾದ ಉತ್ತರ ಎಂದರೆ ಮುಂದಿನ ಸಂಶಯ ಮಾರ್ಗ ಅಥವಾ ಸೇವೆಯ ಗುರುತಿನ ಮೇಲಿದೆ.

# the internal name and the public control should behave differently
dig +short db.corp.example @10.40.0.1
dig +short www.example.com @10.40.0.1

# and the service itself, with the certificate it presents
curl -sS -o /dev/null -w '%{http_code}\n' https://db.corp.example/health

ಸಾರ್ವಜನಿಕ ಹೆಸರನ್ನೂ ಅದೇ ರೆಸಾಲ್ವರ್ ಮೂಲಕ ಪರೀಕ್ಷಿಸಿ. ವಿನಾಯಿತಿಯ ಹೊರಗಿನ ಹೆಸರುಗಳಿಗೆ ಸಂರಕ್ಷಣೆ ಇನ್ನೂ ಸರಿಯಾಗಿ ವರ್ತಿಸಬೇಕು, ಮತ್ತು ಆ ಪರಿಶೀಲನೆ ವಿಫಲವಾದರೆ ಬದಲಾವಣೆ ಉದ್ದೇಶಿಸಿದ್ದಕ್ಕಿಂತ ವಿಶಾಲವಾಗಿತ್ತು. ಪ್ರಮಾಣಪತ್ರಗಳ ಪರಿಶೀಲನೆಯನ್ನು ಪೂರ್ತಿ ಸಮಯ ಬದಲಾಗದೆ ಇರಿಸಿ, ಏಕೆಂದರೆ ಸರಿಯಾಗಿ ಪರಿಹರಿಸುವ ಹೆಸರು ಸಹ ಸೇವೆ ಒದಗಿಸುವ ಪ್ರಮಾಣಪತ್ರಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗಬೇಕು.

ಟಿಕೆಟ್ನಲ್ಲಿ ನಿರಾಕರಿಸಿದ ಉತ್ತರ, ಡೊಮೇನ್, ರೆಸಾಲ್ವರ್ ಮತ್ತು ನೀತಿಯ ಮಾಲೀಕರು ಯಾರು ಎಂಬುದನ್ನು ದಾಖಲಿಸಿ. ಆ ದಾಖಲೆಯೇ ನಿಗೂಢ ಒಳಗಿನ ವೈಫಲ್ಯವನ್ನು ಯಾರಾದರೂ ಪರಿಶೀಲಿಸಬಹುದಾದ ಸಂರಚನಾ ಬದಲಾವಣೆಯಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ.