ಖಾಸಗಿ DNS ಹೆಸರುಗಳು VPN ಕ್ಲೈಂಟ್‌ಗಳಲ್ಲಿ ಏಕೆ ವಿಫಲವಾಗುತ್ತವೆ ಮತ್ತು ಎಲ್ಲಿ ಪರಿಶೀಲಿಸಬೇಕು

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

ಯಾವುದೇ ಪ್ರೊಫೈಲ್ ಸಂಪಾದಿಸುವ ಮೊದಲು ಕ್ಲೈಂಟ್ ಹೆಸರಿನೊಂದಿಗೆ ಏನು ಮಾಡುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ. Linux ನಲ್ಲಿ resolvectl query files.corp.example ಯಾವ ಲಿಂಕ್ ಮತ್ತು ಯಾವ ರಿಸಾಲ್ವರ್ ಉತ್ತರವನ್ನು ರಚಿಸಿದವು ಎಂದು ತೋರಿಸುತ್ತದೆ. Windows ನಲ್ಲಿ Resolve-DnsName files.corp.example ಉತ್ತರಿಸಿದ ಸರ್ವರ್ ಮತ್ತು ಅದು ಹಿಂತಿರುಗಿಸಿದ ವಿಳಾಸವನ್ನು ತೋರಿಸುತ್ತದೆ.

ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ಉತ್ತರವನ್ನು ಓದಿ

ಹೆಸರು ಕೆಲವು ಮಿಲಿಸೆಕೆಂಡುಗಳಲ್ಲಿ NXDOMAIN ಆಗಿ ಹಿಂತಿರುಗಿದರೆ, ಪ್ರಶ್ನೆ ನಿಮ್ಮ ವಲಯವನ್ನು ತಲುಪಲೇ ಇಲ್ಲ ಮತ್ತು ಯಾವುದೋ ಸಾರ್ವಜನಿಕ ಅಥವಾ ಹೋಟೆಲ್ ರಿಸಾಲ್ವರ್ ಉತ್ತರಿಸಿದೆ. ದೀರ್ಘ ವಿರಾಮದ ನಂತರ ಹಿಂತಿರುಗಿದರೆ, ದಾರಿಯಲ್ಲಿ ಯಾವುದೋ UDP ಪೋರ್ಟ್ 53 ಅನ್ನು ಬೀಳಿಸುತ್ತಿದೆ ಮತ್ತು ಕ್ಲೈಂಟ್ ಕೊನೆಗೆ ಪರ್ಯಾಯಕ್ಕೆ ಇಳಿಯಿತು. ಸರಿಯಾದ ವಿಳಾಸದೊಂದಿಗೆ ಉತ್ತರಿಸುತ್ತದೆ ಆದರೆ ಸಂಪರ್ಕ ಇನ್ನೂ ಅಡಚಣೆಯಾಗುತ್ತಿದ್ದರೆ, ಹುಡುಕಾಟ ಸರಿಯಾಗಿದೆ ಮತ್ತು ನಿಮ್ಮ ಸಮಸ್ಯೆ ಮಾರ್ಗನಿರ್ದೇಶನದಲ್ಲಿದೆ ಅಥವಾ ಸೇವೆಯಲ್ಲಿಯೇ ಇದೆ.

ಈ ಮೂರು ವಿಭಾಗಗಳ ವಿಂಗಡಣೆ ಒಂದು ಗಂಟೆಯ ಊಹೆಯನ್ನು ಉಳಿಸುತ್ತದೆ. VPN ಗೆ ಕೈ ಹಾಕಬೇಕೇ ಬೇಡವೇ ಎಂದೂ ಹೇಳುತ್ತದೆ: ಸರಿಯಾದ ಖಾಸಗಿ ವಿಳಾಸಕ್ಕೆ ಬಗೆಹರಿಯುವ ಹೆಸರು ರಿಸಾಲ್ವರ್‌ನ ಮಾರ್ಗವನ್ನು ಈಗಾಗಲೇ ಸಾಬೀತು ಮಾಡಿದೆ, ಆದ್ದರಿಂದ ಉಳಿದ ಕೆಲಸ ಡೇಟಾ ಮಾರ್ಗದಲ್ಲಿದೆ.

ರಿಸಾಲ್ವರ್ ಅನ್ನು ಟನೆಲ್‌ನ ಒಳಗಿನಿಂದ ಹಂಚಿ

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

OpenVPN ಮೊದಲ ಗುಂಪಿನಲ್ಲಿದೆ. ಸರ್ವರ್‌ನಲ್ಲಿ push "dhcp-option DNS 10.8.0.53" ಮತ್ತು push "dhcp-option DOMAIN corp.example" ನಿಯಂತ್ರಣ ಚಾನೆಲ್ ಮೂಲಕ ಕೆಳಗೆ ಹೋಗುತ್ತವೆ, ಆದರೆ ಕ್ಲೈಂಟ್‌ನ ಸಂರಚನೆಯಲ್ಲಿ pull ಇನ್ನೂ ಸಕ್ರಿಯವಾಗಿದ್ದರೆ ಮಾತ್ರ. ಕೈಯಿಂದ ಸಂಪಾದಿಸಿ pull-filter ignore "dhcp-option" ಹೊತ್ತಿರುವ ಕ್ಲೈಂಟ್ ಅವುಗಳನ್ನು ಎಂದಿಗೂ ನೋಡಲಾರದು, ಮತ್ತು ಆ ಒಂದೇ ಸಾಲು «ಸರ್ವರ್ ಅದನ್ನು ತಳ್ಳುತ್ತಿದೆ ಆದರೆ ನನ್ನ ಲ್ಯಾಪ್‌ಟಾಪ್ ಒಪ್ಪುತ್ತಿಲ್ಲ» ಎಂಬಂತಹ ಬೆಚ್ಚಿಬೀಳಿಸುವ ಹಲವು ಸಂದರ್ಭಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ.

WireGuard ಎರಡನೇ ಗುಂಪಿನಲ್ಲಿದೆ, ಏಕೆಂದರೆ ಪ್ರೋಟೋಕಾಲ್‌ನಲ್ಲಿ ಆಯ್ಕೆಗಳ ಚರ್ಚೆಯೇ ಇಲ್ಲ. ರಿಸಾಲ್ವರ್ ಮತ್ತು ಹುಡುಕಾಟ ಡೊಮೇನ್ ಕ್ಲೈಂಟ್‌ನ ಸ್ವಂತ [Interface] ಬ್ಲಾಕ್‌ಗೆ DNS = 10.8.0.53, corp.example ರೂಪದಲ್ಲಿ ಸೇರುತ್ತವೆ. wg-quick ಅದನ್ನು resolvconf ಅಥವಾ systemd-resolved ಮೂಲಕ ಅನ್ವಯಿಸುತ್ತದೆ, ಮತ್ತು Windows ನಲ್ಲಿ ಅಧಿಕೃತ ಕ್ಲೈಂಟ್ ಟನೆಲ್ ನಿಂತಿರುವವರೆಗೆ ಮಾತ್ರ ಇರುವ NRPT ನಿಯಮಗಳನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ: Get-DnsClientNrptPolicy ಅವುಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ, ಇದು ಕ್ಲೈಂಟ್ ನಿಮ್ಮ ಫೈಲ್ ಅನ್ನು ಎಂದಾದರೂ ಅನ್ವಯಿಸಿದೆಯೇ ಎಂದು ನೋಡಲು ವೇಗದ ದಾರಿಯಾಗಿಸುತ್ತದೆ.

IPsec/IKEv2 ನಡುವೆ ಇದೆ. strongSwan ನ attr ಪ್ಲಗಿನ್ ಕೊಳದಿಂದ ತೆಗೆದ DNS ಸರ್ವರ್ ಅನ್ನು ಹಿಂತಿರುಗಿಸಬಹುದು, Windows ಕ್ಲೈಂಟ್ ಅದನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಒಪ್ಪುತ್ತದೆ, ಆದರೆ ತನ್ನದೇ ಹೆಸರು ಸರ್ವರ್ ಅನ್ನು ಬಿಗಿಗೊಳಿಸುವ ಪ್ರೊಫೈಲ್ ಗೇಟ್‌ವೇ ನೀಡುವ ಎಲ್ಲದಕ್ಕೂ ಮಿಗಿಲಾಗುತ್ತದೆ. Linux ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ ಸಮಾನವಾದ ಕೈ ಹೆಜ್ಜೆ resolvectl dns wg0 10.8.0.53 ಮತ್ತು ನಂತರ resolvectl domain wg0 '~corp.example'; ಎರಡೂ ಇಂಟರ್‌ಫೇಸ್‌ನೊಂದಿಗೆ ಮಾಯವಾಗುತ್ತವೆ, ಇದು ಟನೆಲ್‌ಗೆ ಸೀಮಿತವಾದ ಸೆಟ್ಟಿಂಗ್‌ಗೆ ನೀವು ಬಯಸುವುದು ನಿಖರವಾಗಿ ಅದೇ.

ಪ್ರತಿ ಪ್ರಶ್ನೆಯನ್ನು ನುಂಗುವ ಬದಲು ಪ್ರತ್ಯಯವನ್ನು ಸೀಮಿತಗೊಳಿಸಿ

ಕ್ಲೈಂಟ್‌ನ ಇಡೀ ರಿಸಾಲ್ವರ್ ಪಟ್ಟಿಯನ್ನು ನಿಮ್ಮ ಆಂತರಿಕ ಸರ್ವರ್‌ಗೆ ತಿರುಗಿಸುವುದು ಸುಲಭ ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ತಪ್ಪು. ಆಗ ಪ್ರತಿ ಸಾರ್ವಜನಿಕ ಹೆಸರೂ ನಿಮ್ಮ ಡೇಟಾ ಕೇಂದ್ರದ ನಿರ್ಗಮನದ ಮೂಲಕ ಬಗೆಹರಿಯುತ್ತದೆ, CDN ಗಳು ದೂರದ ವಿಳಾಸಗಳನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತವೆ, ಮತ್ತು ರಿಸಾಲ್ವರ್‌ನ ಒಂದು ಅಡಚಣೆ ಬಳಕೆದಾರರ ಬ್ರೌಸಿಂಗ್ ಅನ್ನೂ ಜೊತೆಗೆ ಕೊಂಡೊಯ್ಯುತ್ತದೆ.

ಒಳಗೆ ಖಾಸಗಿ ಪ್ರತ್ಯಯವನ್ನು ಮಾತ್ರ ಕಳುಹಿಸಿ. systemd-resolved ನಲ್ಲಿ ~ ನಿಂದ ಪ್ರಾರಂಭವಾಗುವ ಡೊಮೇನ್ ಮಾರ್ಗನಿರ್ದೇಶನಕ್ಕೆ ಮಾತ್ರ, ಆದ್ದರಿಂದ ~corp.example ಎಂದರೆ ಆ ಪ್ರತ್ಯಯದ ಅಡಿಯ ಪ್ರಶ್ನೆಗಳು ಆ ಲಿಂಕ್‌ನ ಸರ್ವರ್‌ಗಳಿಗೆ ಹೋಗುತ್ತವೆ, ಉಳಿದೆಲ್ಲವೂ ಭೌತಿಕ ಜಾಲಬಂಧವನ್ನೇ ಬಳಸುತ್ತವೆ. Windows ಇದೇ ಕೆಲಸವನ್ನು ಹೆಸರಿನ ಸ್ಥಳಕ್ಕೆ ಸೀಮಿತವಾದ NRPT ನಿಯಮಗಳಿಂದ ಮಾಡುತ್ತದೆ, macOS /etc/resolver/ ಅಡಿಯಲ್ಲಿ ಹೆಚ್ಚುವರಿ ರಿಸಾಲ್ವರ್ ಫೈಲ್‌ನಿಂದ ಮಾಡುತ್ತದೆ.

ಮಲ್ಟಿಕಾಸ್ಟ್ ಹೆಸರುಗಳು ತಮ್ಮದೇ ಉತ್ತರಕ್ಕೆ ಅರ್ಹವಾಗಿವೆ. .local ಹೆಸರುಗಳು ರಚನೆಯಿಂದ link-local (RFC 6762) ಮತ್ತು ಬಿಂದು-ಬಿಂದು tun ಇಂಟರ್‌ಫೇಸ್ ಆ ಮಲ್ಟಿಕಾಸ್ಟ್ ಗುಂಪನ್ನು ಹೊತ್ತೊಯ್ಯದು, ಆದ್ದರಿಂದ ಸಾರ್ವಜನಿಕ ರಿಸಾಲ್ವರ್ ಸೇರಿಸುವುದು ಅವನ್ನು ಪ್ರಕಟಿಸದು ಮತ್ತು ಆಂತರಿಕ unicast ರಿಸಾಲ್ವರ್‌ನಲ್ಲಿ ಅವುಗಳ ಬಗ್ಗೆ ಕೇಳಿದರೆ NXDOMAIN ಹಿಂತಿರುಗುತ್ತದೆ. avahi ಯಂತಹ ಪ್ರತಿಫಲಕ ಪ್ರತಿಫಲನ ಮೋಡ್‌ನಲ್ಲಿ ಎರಡು ವಿಭಾಗಗಳನ್ನು ಸೇರಿಸಬಹುದು, ಆದರೆ ಅದು ಸರ್ವರ್ ಬದಿಯ ನಿರ್ಣಯ, ಯಾವ ಕ್ಲೈಂಟ್ ಕೂಡ ಕೇಳಲಾರದು. ಮುದ್ರಕ ಅಥವಾ NAS ಹೆಸರಿನಿಂದ ತಲುಪಬಲ್ಲದಾಗಿರಬೇಕಾದರೆ, ಬದಲಿಗೆ ನಿಮ್ಮ ವಲಯದಲ್ಲಿ ಅದಕ್ಕೆ A ದಾಖಲೆ ಕೊಡಿ.

ಉತ್ತರ ಹಿಂತಿರುಗಬಲ್ಲದೆಂದು ಸಾಬೀತು ಮಾಡಿ

ತಲುಪಲಾಗದ ವಿಳಾಸದೆಡೆಗೆ ತೋರಿಸುವ ಸರಿಯಾದ ಉತ್ತರ, ನೀವು ಮಾರ್ಗವನ್ನು ಪರಿಶೀಲಿಸುವವರೆಗೆ ನಿಖರವಾಗಿ ರಿಸಾಲ್ವರ್ ಸಮಸ್ಯೆಯಂತೆಯೇ ಕಾಣುತ್ತದೆ. ಕರ್ನಲ್ ಅನ್ನು ಕೇಳಿ ಉತ್ತರ ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ: ip route get 10.20.5.20 ಇಂಟರ್‌ಫೇಸ್ ಮತ್ತು ಹೆಚ್ಚು ಉಪಯುಕ್ತವಾಗಿ ಅದು ಬಳಸುವ ಮೂಲ ವಿಳಾಸವನ್ನು ಹೆಸರಿಸುತ್ತದೆ.

ರಿಸಾಲ್ವರ್‌ನ ವಿಳಾಸವನ್ನೇ ಗಮನಿಸಿ. DNS = 10.8.0.53 ಜೊತೆಗೆ AllowedIPs = 10.20.0.0/16 ಇರುವ ಕ್ಲೈಂಟ್ ತನ್ನ ಪ್ರಶ್ನೆಗಳನ್ನು ಭೌತಿಕ NIC ಮೂಲಕ ಹೊರಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆ, ಅಲ್ಲಿ ಅವು ಮೌನವಾಗಿ ಸಾಯುತ್ತವೆ, ಏಕೆಂದರೆ ರಿಸಾಲ್ವರ್ ಟನೆಲ್ ಹಕ್ಕು ಸಲ್ಲಿಸುವ ಯಾವುದೇ ಪೂರ್ವಪ್ರತ್ಯಯದ ಒಳಗಿಲ್ಲ. ಈ ಅಸಾಮರಸ್ಯ ಈ ಇಡೀ ಕ್ಷೇತ್ರದಲ್ಲಿ ಅತ್ಯಂತ ಸಾಮಾನ್ಯ ಏಕ-ಕಾರಣ ವೈಫಲ್ಯ, ಮತ್ತು DNS ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಅನುಮತಿಸಿದ ಪೂರ್ವಪ್ರತ್ಯಯಗಳೊಂದಿಗೆ ಸಾಲು ಸಾಲಾಗಿ ಹೋಲಿಸುವವರೆಗೆ ಇದು ಕಾಣುವುದಿಲ್ಲ.

ಅತಿವ್ಯಾಪ್ತಿ ಶ್ರೇಣಿಗಳು ವಿರುದ್ಧ ವೈಫಲ್ಯವನ್ನು ಉಂಟುಮಾಡುತ್ತವೆ. ಉತ್ತರ ಸರಿಯಾಗಿದೆ, ಮಾರ್ಗವಿದೆ, ಮತ್ತು ಅದು ತಪ್ಪು ಆತಿಥೇಯನೆಡೆಗೆ ತೋರಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಮನೆಯಲ್ಲಿ 192.168.0.0/24 ಅದೇ ಶ್ರೇಣಿಗೆ ಟನೆಲ್‌ನ ಮಾರ್ಗಕ್ಕಿಂತ ಹೆಚ್ಚು ನಿರ್ದಿಷ್ಟವಾಗಿದೆ. ಒಂದು ಬದಿಯನ್ನು ಮರುಸಂಖ್ಯೆ ಮಾಡಿ ಅಥವಾ ಸಣ್ಣ ಮಾರ್ಗವನ್ನು ತಳ್ಳಿ, ನಂತರ ಸೇವಾ ಆತಿಥೇಯನ ಫೈರ್‌ವಾಲ್ ಮತ್ತು ಹಿಂತಿರುಗುವ ಮಾರ್ಗವನ್ನು ಖಚಿತಪಡಿಸಿ; strongSwan ನ ಮುನ್ನಡೆಸುವಿಕೆ ಬಗ್ಗೆ ಟಿಪ್ಪಣಿಗಳು ಆ ಮಾರ್ಗದ sysctl ಬದಿಯನ್ನು ಒಳಗೊಳ್ಳುತ್ತವೆ.

ಪ್ರಮಾಣಪತ್ರಗಳು ಜನರು DNS ಮೇಲೆ ಹೊರಿಸುವ ಪ್ರತ್ಯೇಕ ಗುರುತಿನ ಪರಿಶೀಲನೆ. ಬ್ರೌಸರ್ ಬಗೆಹರಿಸುವ ದೋಷದ ಬದಲು ಹೆಸರಿನ ಅಸಾಮರಸ್ಯವನ್ನು ವರದಿ ಮಾಡಿದರೆ, ಹುಡುಕಾಟ ಈಗಾಗಲೇ ಕೆಲಸ ಮಾಡಿದೆ ಮತ್ತು ಪ್ರಮಾಣಪತ್ರದಲ್ಲಿನ SAN ನ್ನೇ ಸರಿಪಡಿಸಬೇಕಾದದ್ದು. HTTPS ಅನ್ನು ಹೆಸರಿನ ಮೇಲೆ ಪರೀಕ್ಷಿಸಿ, ಎಂದಿಗೂ ಬರಿ IP ಮೇಲೆ ಅಲ್ಲ.

ಗೇಟ್‌ವೇನಿಂದ ಅಲ್ಲ, ಕ್ಲೈಂಟ್‌ನಿಂದ ಮತ್ತೆ ಪರೀಕ್ಷಿಸಿ

ಬಳಕೆದಾರರು ದೂರು ನೀಡುವ ಅಪ್ಲಿಕೇಶನ್‌ನ ಒಳಗೇನೇ ಪರೀಕ್ಷಿಸಿ, ಏಕೆಂದರೆ ಕಮಾಂಡ್ ಲೈನ್ ಹುಡುಕಾಟ ಬ್ರೌಸರ್ ಅದೇ ಮಾರ್ಗವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂದು ಸಾಬೀತು ಮಾಡುವುದಿಲ್ಲ. Chrome ನ ಸುರಕ್ಷಿತ DNS ಮತ್ತು Firefox ನ network.trr.mode ಸಿಸ್ಟಂ ರಿಸಾಲ್ವರ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬೈಪಾಸ್ ಮಾಡಬಲ್ಲವು, ಮತ್ತು ಹಾಗೆ ಮಾಡಿದಾಗ ಖಾಸಗಿ ಹೆಸರು ಒಂದೋ ವಿಫಲವಾಗುತ್ತದೆ ಅಥವಾ ಸಾರ್ವಜನಿಕ ರಿಸಾಲ್ವರ್‌ಗೆ ಸೋರುತ್ತದೆ. resolvectl query ಅನ್ನು ಕೈಯಿಂದ ನಡೆಸಿದ dig @10.8.0.53 files.corp.example ಜೊತೆ ಹೋಲಿಸುವುದು ಎರಡರಲ್ಲಿ ಯಾವುದು ಸಂಭವಿಸಿತು ಎಂದು ಹೇಳುತ್ತದೆ.

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

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