dnsmasq ನಲ್ಲಿ ನಿಮ್ಮ VPN ಡೊಮೇನ್ ವಲಯ ವರ್ಗಾವಣೆ ಅಲ್ಲ

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

ಕ್ಲೈಂಟ್ ಸ್ವೀಕರಿಸಿದ್ದು ಗೇಟ್‌ವೇ ನೀಡಿದ್ದಲ್ಲ

ಗೇಟ್‌ವೇ ಒಂದು resolver, ಒಂದು ಡೊಮೇನ್ ಮತ್ತು ಆ resolver ತಲುಪಲು ಬೇಕಾದ ಮಾರ್ಗವನ್ನು ನೀಡಬಹುದು, ಕ್ಲೈಂಟ್ ಮೂರನ್ನೂ ಅಥವಾ ಯಾವುದನ್ನೂ ಸ್ವೀಕರಿಸಬಹುದು. ಆಮದು ಮಾಡಿದ ಪ್ರೊಫೈಲ್, ಸಹಾಯಕ ಸ್ಕ್ರಿಪ್ಟ್ ಅಥವಾ ತಳ್ಳಲಾದ ಆಯ್ಕೆಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸುವ ನೀತಿ ಸ್ವೀಕರಿಸಿದ ಸೆಟ್ ಅನ್ನು ಖಾಲಿ ಬಿಡಬಹುದು, ಆದರೆ ಸರ್ವರ್ ಭಾಗ ಸರಿಯಾಗಿ ಕಾಣುತ್ತದೆ. ಸರ್ವರ್ ಕಾನ್ಫಿಗರೇಶನ್ ಬದಲು ಕ್ಲೈಂಟ್ ದಾಖಲಿಸಿದ ಸ್ಥಿತಿಯಿಂದ ಪ್ರಾರಂಭಿಸಿ, ಏಕೆಂದರೆ resolver ನಿಜವಾಗಿ ಪಡೆಯುವುದು ಆ ಸ್ಥಿತಿಯೇ. ಸ್ವೀಕರಿಸಿದ ಡೊಮೇನ್ ಇಲ್ಲದಿದ್ದರೆ, ಮುಂದೆ ಏನೂ ಮುಖ್ಯವಲ್ಲ. ಯಾವುದೇ ಕ್ಯಾಶ್ ಪರಿಶೀಲಿಸುವ ಮೊದಲು ಸಂಪರ್ಕದ DNS ಗುಣಲಕ್ಷಣಗಳನ್ನು ಪರಿಶೀಲಿಸಿ.

ಆ ವ್ಯತ್ಯಾಸವು ಎಂದಿಗೂ ಬಾರದ ಡೊಮೇನ್ ಬಗ್ಗೆ ಹೆಚ್ಚಿನ ವರದಿಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ. ಅದನ್ನು ನೀಡಲಾಯಿತು, ಮತ್ತು ಅನ್ವಯಿಸಲಿಲ್ಲ.

ಎರಡು ರೀತಿಯ ಡೊಮೇನ್ ನಮೂದುಗಳು

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

ಖಾಸಗಿ ನೆಮ್‌ಸ್ಪೇಸ್‌ಗೆ ಸಾಮಾನ್ಯವಾಗಿ ಮಾರ್ಗ-ಮಾತ್ರ ರೂಪವೇ ಬೇಕು. ಅದು ಕಾರ್ಪೊರೇಟ್ ಸಫಿಕ್ಸ್ ಅನ್ನು ಕಾರ್ಪೊರೇಟ್ resolver ಕಡೆಗೆ ಇಡುತ್ತದೆ ಮತ್ತು ಉಳಿದೆಲ್ಲವನ್ನೂ ಒಂಟಿಯಾಗಿ ಬಿಡುತ್ತದೆ.

resolv.conf ನಲ್ಲಿ localhost ಒಂದು ಬಗ್ ಅಲ್ಲ

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

ಆ ನಮೂದನ್ನು ಸಾರ್ವಜನಿಕ resolver ನಿಂದ ಬದಲಾಯಿಸುವುದು ಕ್ಲಾಸಿಕ್ ತಪ್ಪು ಸರಿಪಡಿಸುವಿಕೆ. ಅದು ಸಾರ್ವಜನಿಕ ಹೆಸರು ಪರಿಹಾರವನ್ನು ಮರುಸ್ಥಾಪಿಸುತ್ತದೆ ಮತ್ತು ಅದೇ ಸಂಪಾದನೆಯಲ್ಲಿ ಷರತ್ತುಬದ್ಧ ನೀತಿಯನ್ನು ತ್ಯಜಿಸುತ್ತದೆ.

backend ಗಳನ್ನು ಬೆರೆಸಬೇಡಿ

ನಿರ್ವಹಿಸಲಾದ dnsmasq ನಿದರ್ಶನ ಮತ್ತು ಸಿಸ್ಟಮ್ resolver ವಿಭಿನ್ನ ಕಾನ್ಫಿಗರೇಶನ್ ಮತ್ತು ವಿಭಿನ್ನ ಸ್ಥಿತಿ ನೋಟಗಳನ್ನು ಹೊಂದಿರುವ ವಿಭಿನ್ನ ಪ್ರೋಗ್ರಾಮ್‌ಗಳು. ಒಂದಕ್ಕೆ ಸ್ಥಿತಿ ಆಜ್ಞೆ ಇನ್ನೊಂದರ ಬಗ್ಗೆ ಉಪಯುಕ್ತವಾದದ್ದನ್ನು ಹೇಳುವುದಿಲ್ಲ.

ನಿರ್ವಾಹಕರು ಯಾವ backend ಬಳಸಲು ಕಾನ್ಫಿಗರ್ ಆಗಿದ್ದಾರೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಿ, ನಂತರ ಆ backend ನ ಉತ್ಪಾದಿತ ಕಾನ್ಫಿಗರೇಶನ್ ಓದಿ, ಆಕಸ್ಮಿಕವಾಗಿ ಇರುವ ಸಂಪೂರ್ಣ ವಿತರಣಾ-ವ್ಯಾಪಿ ಫೈಲ್ ಅಲ್ಲ. ನಿರ್ವಾಹಕರು ತಮ್ಮದೇ ನಿದರ್ಶನ ಕಾನ್ಫಿಗರೇಶನ್ ಬರೆಯುತ್ತಾರೆ ಮತ್ತು ಆ ನಿದರ್ಶನಕ್ಕೆ ಕಸ್ಟಮ್ ಆಯ್ಕೆಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತಾರೆ, ಆದ್ದರಿಂದ ಸಂಬಂಧವಿಲ್ಲದ ಜಾಗತಿಕ ಫೈಲ್ ಸಂಪಾದಿಸುವುದು ಏನನ್ನೂ ಬದಲಿಸುವುದಿಲ್ಲ ಮತ್ತು ಪರಿಣಾಮವಿಲ್ಲದ ಬದಲಾವಣೆಯಂತೆ ಕಾಣುತ್ತದೆ. ಪೋರ್ಟ್ 53 ನಲ್ಲಿ ಎರಡನೇ ಡೀಮನ್ ಪ್ರಾರಂಭಿಸುವುದು ನಿರುಪಯುಕ್ತಕ್ಕಿಂತ ಕೆಟ್ಟದು, ಏಕೆಂದರೆ ಈಗ ಎರಡು ಪ್ರೋಗ್ರಾಮ್‌ಗಳು ಪೋರ್ಟ್ ಯಾರದ್ದು ಎಂಬುದರಲ್ಲಿ ಒಪ್ಪುವುದಿಲ್ಲ. ಮೊದಲು ಮಾಲೀಕರನ್ನು ನಿರ್ಧರಿಸಿ, ನಂತರ ಆ ಮಾಲೀಕರು ಓದುವ ಸ್ಥಳದಲ್ಲಿ ಸಂಪಾದಿಸಿ.

ನೆಮ್‌ಸ್ಪೇಸ್ ಪರೀಕ್ಷಿಸಿ, ಉತ್ತರವನ್ನು ಮಾತ್ರವಲ್ಲ

ಅಪ್ಲಿಕೇಶನ್‌ನ ಸಾಮಾನ್ಯ ಮಾರ್ಗದ ಮೂಲಕ ಒಂದು ಅನುಮತಿಸಲಾದ ಖಾಸಗಿ ಹೆಸರು ಮತ್ತು ಒಂದು ಸಾರ್ವಜನಿಕ ನಿಯಂತ್ರಣ ಹೆಸರನ್ನು ಕೇಳಿ. ಕಾರ್ಪೊರೇಟ್ ಸರ್ವರ್‌ಗೆ ನೇರ ಪ್ರಶ್ನೆ ದಾಖಲೆ ಇದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ; ಕ್ಲೈಂಟ್ ಆ ಸರ್ವರ್ ಆಯ್ಕೆ ಮಾಡಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ಎರಡನೇ ಪ್ರಶ್ನೆ ನೀತಿಯನ್ನು ಪರೀಕ್ಷಿಸುವುದು.

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