Pritunl ನ ಖಾಸಗಿ DNS ವಿಫಲವಾಗಿದೆಯೇ? ಕಿರಿದಾದ resolver ಮಾರ್ಗವನ್ನು ಸೇರಿಸಿ

ಖಾಸಗಿ ಹೆಸರುಗಳು ಕಾರ್ಪೊರೇಟ್ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಎಲ್ಲರಿಗೂ ಪರಿಹರಿಸಲ್ಪಡುತ್ತವೆ ಮತ್ತು VPN ನಲ್ಲಿ ಎಲ್ಲರಿಗೂ ಸಮಯ ಮೀರಿ ಹೋಗುತ್ತವೆ. Resolver ಗೇಟ್ವೇಗೆ ಉತ್ತರಿಸುತ್ತದೆ, ಅಲ್ಲಿಗೆ ಮಾರ್ಗವಿದೆ, ಆದರೂ ಕ್ವೆರಿಗೆ ಎಂದಿಗೂ ಉತ್ತರ ಸಿಗುವುದಿಲ್ಲ. ಕೊರತೆಯಿರುವುದು ಇನ್ನೊಂದು ಸಾರ್ವಜನಿಕ resolver ಅಲ್ಲ ಅಥವಾ ವಿಶಾಲ ಮಾರ್ಗವಲ್ಲ: ಖಾಸಗಿ DNS ಸರ್ವರ್ ಉತ್ತರಿಸಲು ಸಿದ್ಧವಿರುವ ಮೂಲ ವಿಳಾಸ.

Resolver ನಿಮ್ಮ ಕ್ಲೈಂಟ್ ಪೂಲ್ ಅನ್ನು ನಿರಾಕರಿಸುತ್ತಿದೆ ಎಂದು ದೃಢೀಕರಿಸಿ

ವೈಫಲ್ಯವು ತಲುಪುವಿಕೆಯಲ್ಲ, ಮೂಲಕ್ಕೆ ಸಂಬಂಧಿಸಿದ್ದು ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದರಿಂದ ಪ್ರಾರಂಭಿಸಿ. ಸಂಪರ್ಕಿತ ಕ್ಲೈಂಟ್ನಿಂದ ಖಾಸಗಿ resolver ಗೆ ನೇರವಾಗಿ ಕ್ವೆರಿ ಮಾಡಿ ಮತ್ತು ವಿನಂತಿಯು ಸಮಯ ಮೀರಿ ಹೋಗುತ್ತದೆಯೇ ಅಥವಾ ನಿರಾಕರಣೆಯಾಗಿ ಹಿಂತಿರುಗುತ್ತದೆಯೇ ಎಂದು ಗಮನಿಸಿ. dig @10.40.0.53 intranet.example.net +time=2 +tries=1 ಸಮಯ ಮೀರಿ ಹೋಗುತ್ತಿರುವಾಗ ಗೇಟ್ವೇನಿಂದ ಅದೇ ಕ್ವೆರಿ ಯಶಸ್ವಿಯಾದರೆ ಅದು resolver ನಲ್ಲಿ ಪ್ರವೇಶ ನೀತಿಯನ್ನು ಸೂಚಿಸುತ್ತದೆ. SERVFAIL ಉತ್ತರವು ಸಂಪೂರ್ಣವಾಗಿ ಬೇರೆಡೆಗೆ, ಸಾಮಾನ್ಯವಾಗಿ ವಲಯ ಅಥವಾ ಮೇಲ್ಮುಖ ಫಾರ್ವರ್ಡರ್ಗೆ ಸೂಚಿಸುತ್ತದೆ.

ಪರೀಕ್ಷಿಸುವ ಮೊದಲು ಕ್ಲೈಂಟ್ನ ವಿಳಾಸವನ್ನು ದಾಖಲಿಸಿ. ಕ್ಲೈಂಟ್ನಲ್ಲಿ ip -4 addr show tun0, ಅಥವಾ ಕನ್ಸೋಲ್ನಲ್ಲಿ ತೋರಿಸಿದ ಲೀಜ್, resolver ಯಾವ ಪೂಲ್ ಅನ್ನು ನೋಡುತ್ತದೆ ಎಂದು ಹೇಳುತ್ತದೆ.

ನಂತರ ಮಾರ್ಗವು ಇದೆಯೇ ಎಂದು ದೃಢೀಕರಿಸಿ. Resolver ವಿಳಾಸವನ್ನು ಟನೆಲ್ಗೆ ಕಳುಹಿಸುವ ಮಾರ್ಗವು ಪೂರ್ವಶರತ್ತು, ಪರಿಹಾರವಲ್ಲ; ಪ್ಯಾಕೆಟ್ಗಳು ಎಂದಿಗೂ ತಲುಪದಿದ್ದರೆ, ಮೂಲ ನೀತಿಯನ್ನು ಎಂದಿಗೂ ಪರಿಶೀಲಿಸಲಾಗುವುದಿಲ್ಲ. ಕ್ಲೈಂಟ್ನಲ್ಲಿ ip route get 10.40.0.53 ಮೂಲಕ ಅದನ್ನು ಪರಿಶೀಲಿಸಿ.

ಎಲ್ಲವನ್ನೂ ಅನುವಾದಿಸುವ ಬದಲು ಒಂದು ಹೋಸ್ಟ್ ಮಾರ್ಗವನ್ನು ಸೇರಿಸಿ

Pritunl ನ ಖಾಸಗಿ DNS ಮಾರ್ಗದರ್ಶನವು ಕಿರಿದಾದ ಪರಿಹಾರವನ್ನು ವಿವರಿಸುತ್ತದೆ: resolver ವಿಳಾಸಕ್ಕಾಗಿ NAT ಸಕ್ರಿಯ /32 ಮಾರ್ಗ, ಆ ವಿಳಾಸವನ್ನು ಕ್ಲೈಂಟ್ಗಳ DNS ಸರ್ವರ್ ಆಗಿ ಆಯ್ಕೆಮಾಡಿ. ಮಾರ್ಗವು resolver ನೋಡುವ ಮೂಲವನ್ನು DNS ಸಂಚಾರಕ್ಕೆ ಮಾತ್ರ ಬದಲಾಯಿಸುತ್ತದೆ. ಅಪ್ಲಿಕೇಶನ್ ಸಂಚಾರವು ಅದಕ್ಕಾಗಿ ನೀವು ಆಯ್ಕೆಮಾಡಿದ ಮೂಲ-ಸಂರಕ್ಷಣಾ ವಿನ್ಯಾಸವನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ.

ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಮಾರ್ಗಗಳನ್ನು ಅತಿಕ್ರಮಣಕ್ಕಾಗಿ ಪರಿಶೀಲಿಸಿದ ನಂತರ, ಸರ್ವರ್ನ ಬೆಂಬಲಿತ ಮಾರ್ಗ ಮಾಲೀಕರ ಮೂಲಕ ಅದನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿ. ಮೇಲಿನ ಉದಾಹರಣೆಯಲ್ಲಿ ಗಮ್ಯಸ್ಥಾನ NAT ಸಕ್ರಿಯ 10.40.0.53/32, ಮತ್ತು ಕ್ಲೈಂಟ್ ಪೂಲ್ 10.90.0.0/24 ಆಗಿ ಉಳಿಯುತ್ತದೆ. ಒಂದು ಸೇವೆಯನ್ನು ಸರಿಪಡಿಸಲು ಇಡೀ ಖಾಸಗಿ ಶ್ರೇಣಿಯನ್ನು ಅನುವಾದಿಸಬೇಡಿ, ಏಕೆಂದರೆ ಕ್ಲೈಂಟ್ನ ನಿಜವಾದ ವಿಳಾಸವನ್ನು ಅವಲಂಬಿಸಿರುವ ಪ್ರತಿಯೊಂದು ಕೆಳಮುಖ ನೀತಿಯು ಬದಲಿಗೆ ಗೇಟ್ವೇಯನ್ನು ನೋಡಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಪರೀಕ್ಷಾ ಹುಡುಕಾಟದ ಸಮಯದಲ್ಲಿ resolver ನ ಕ್ವೆರಿ ಲಾಗ್ ಅನ್ನು ನೋಡಿ ಅದು ನಿಜವಾಗಿ ಪಡೆಯುವ ವಿಳಾಸವನ್ನು ದೃಢೀಕರಿಸಿ. ಹೋಸ್ಟ್ ಮಾರ್ಗವೊಂದೇ ಅನುವಾದ ಅಥವಾ ಅನುಮತಿಯ ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.

Resolver ಇನ್ನೂ UDP ಮತ್ತು TCP ನಲ್ಲಿ ಅನುವಾದಿತ ಮೂಲವನ್ನು ಅನುಮತಿಸಬೇಕು, ಮತ್ತು ಅದರ ಉತ್ತರಗಳು ಹಿಂತಿರುಗಲು ಸಾಧ್ಯವಾಗಬೇಕು. ಮೂಲವನ್ನು ಬದಲಾಯಿಸುವುದು ಕಾಣೆಯಾದ ವಲಯ ಅಥವಾ ದಾಖಲೆಯನ್ನು ಸೃಷ್ಟಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.

ಕ್ವೆರಿಯನ್ನು ಸರ್ವರ್ ಕಳುಹಿಸುತ್ತದೆಯೇ ಅಥವಾ ಕ್ಲೈಂಟ್ ಎಂದು ನಿರ್ಧರಿಸಿ

Pritunl, VPN Client DNS Mapping ಗೆ ಸಂಬಂಧಿಸಿದ DNS-ಪ್ರಾಕ್ಸಿ ವ್ಯವಸ್ಥೆಯನ್ನು ಸಹ ದಾಖಲಿಸುತ್ತದೆ, ಅಲ್ಲಿ ಸರ್ವರ್ ಕ್ಲೈಂಟ್ಗಳಿಗಾಗಿ ಮೇಲ್ಮುಖ ಕ್ವೆರಿಗಳನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡುತ್ತದೆ. ಆ ಮಾದರಿಯಲ್ಲಿ ಮೇಲ್ಮುಖ ಮೂಲವು ಸರ್ವರ್ನ ಸ್ವಂತ ನೆಟ್ವರ್ಕ್ ಸಂದರ್ಭಕ್ಕೆ ಸೇರಿದೆ, ಮತ್ತು ಕ್ಲೈಂಟ್-ಬದಿಯ ಅಪವಾದವು ತಪ್ಪು ಪರಿಹಾರ.

ಏನನ್ನಾದರೂ ಸೇರಿಸುವ ಮೊದಲು ಯಾವ ಮಾದರಿ ಸಕ್ರಿಯವಾಗಿದೆ ಎಂದು ಗುರುತಿಸಿ. ಮೂರು ಅತಿಕ್ರಮಿಸುವ ಸರಿಪಡಿಸುವಿಕೆಗಳು, ಒಂದು ಪ್ರಾಕ್ಸಿ, ಕ್ಲೈಂಟ್ನಲ್ಲಿ resolver ಬದಲಾವಣೆ ಮತ್ತು ಕೈಯಿಂದ NAT ಸ್ಕ್ರಿಪ್ಟ್ ಸಾಮಾನ್ಯವಾಗಿ ಯಾರೂ ಸ್ಥಾಪಿಸಿಲ್ಲ ಎಂದು ಅರ್ಥ: ಕ್ವೆರಿಯನ್ನು ಯಾವ ಘಟಕವು ಕಳುಹಿಸಬೇಕು. bootstrap ಅನ್ನು ಸಹ ಪರಿಶೀಲಿಸಿ: ಟನೆಲ್ ಇರುವ ಮೊದಲು ಎಂಡ್ಪಾಯಿಂಟ್ ಹುಡುಕುವ ಏಕೈಕ ದಾರಿ ಖಾಸಗಿ resolver ಮಾತ್ರ ಆಗಿರಲು ಸಾಧ್ಯವಿಲ್ಲ, ಮತ್ತು ಶಾಶ್ವತ resolver ಬದಲಾವಣೆಯು ಸಂಪರ್ಕಕ್ಕಿಂತ ಹೆಚ್ಚು ಬದುಕಬಾರದು.

ಸಾರ್ವಜನಿಕ ವೆಬ್ ಪುಟವಲ್ಲ, ಖಾಸಗಿ ಹುಡುಕಾಟವನ್ನು ಪರೀಕ್ಷಿಸಿ

ಬದಲಾವಣೆಯನ್ನು ಅನ್ವಯಿಸಿ ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿದ ನಂತರ, ಕ್ಲೈಂಟ್ನ ಪರಿಣಾಮಕಾರಿ resolver ಸಂರಚನೆಯನ್ನು ಪರಿಶೀಲಿಸಿ, ನಂತರ ಖಾಸಗಿ ವಲಯದಲ್ಲಿ ಮಾತ್ರ ಇದೆ ಎಂದು ನಿಮಗೆ ತಿಳಿದಿರುವ ಹೆಸರನ್ನು ಪರಿಹರಿಸಿ. ಸ್ಪಷ್ಟ ಸರ್ವರ್ ಇಲ್ಲದೆ dig intranet.example.net ಕ್ಲೈಂಟ್ ನಿಜವಾಗಿ ಏನನ್ನು ಬಳಸುತ್ತದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ. ನಂತರ ಆ ಹುಡುಕಾಟವು ಹಿಂತಿರುಗಿಸಿದ ವಿಳಾಸಕ್ಕೆ ವಿನಂತಿ ಕಳುಹಿಸಿ, ಏಕೆಂದರೆ ಪರಿಹಾರ ಮತ್ತು ಸೇವಾ ಪ್ರವೇಶ ಪ್ರತ್ಯೇಕ ಹಂತಗಳು. DNS-over-HTTPS ಮೂಲಕ ಸಾರ್ವಜನಿಕ ಸೈಟ್ಗಳನ್ನು ಲೋಡ್ ಮಾಡುವ ಬ್ರೌಸರ್ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ನ ಖಾಸಗಿ resolver ಮಾರ್ಗದ ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ಸಾರ್ವಜನಿಕ ದ್ವಿತೀಯ resolver ಸಹ ಆಂತರಿಕ ವಲಯಕ್ಕೆ ಪ್ರಾಧಿಕಾರವಲ್ಲ.

Resolver ವಿಳಾಸ, /32 ಮಾರ್ಗ ಮತ್ತು ಕ್ಲೈಂಟ್ DNS ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಒಟ್ಟಿಗೆ ಸರ್ವರ್ ಟಿಪ್ಪಣಿಗಳಲ್ಲಿ ದಾಖಲಿಸಿ. ಆ ಸಂರಚನೆಯ ಅರ್ಧ ಭಾಗವನ್ನು ಮಾತ್ರ ಮರುಸ್ಥಾಪಿಸಿದರೆ ಮೂಲ ವೈಫಲ್ಯ ಮತ್ತೆ ಸಂಭವಿಸುತ್ತದೆ.

ಕೊನೆಯದಾಗಿ, DNS ಯಶಸ್ವಿಯಾದ ನಂತರ ಟನೆಲ್ ಇನ್ನೂ ಅಪ್ಲಿಕೇಶನ್ ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಮಾರ್ಗವನ್ನು ನೀಡುತ್ತದೆ ಎಂದು ದೃಢೀಕರಿಸಿ. ಮಾರ್ಗ, ಸೇವಾ ಪ್ರವೇಶ ಮತ್ತು ದೃಢೀಕರಣವು ಹೆಸರು ಪರಿಹಾರದಿಂದ ಸ್ವತಂತ್ರವಾಗಿ ಉಳಿಯುತ್ತವೆ, ಮತ್ತು ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಹುಡುಕಾಟವು ಥ್ರೂಪುಟ್ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಖಾಸಗಿ ಪುಟ ನಿಧಾನವಾಗಿದ್ದರೂ ಪರಿಹರಿಸಲ್ಪಟ್ಟರೆ, resolver ತನ್ನ ಕೆಲಸ ಮಾಡಿದೆ ಮತ್ತು ಸಮಸ್ಯೆ ಮಾರ್ಗಕ್ಕೆ ಸರಿದಿದೆ.