OpenVPN ಪುಷ್ ಮಾಡಿದ DNS ನಿರ್ಲಕ್ಷಿಸಲ್ಪಡುತ್ತದೆ: ಯಾವ ಘಟಕ ಅದನ್ನು ಅನ್ವಯಿಸುತ್ತದೆ

ಲಾಗ್ ಸರ್ವರ್ ಪುಷ್ ಮಾಡಿದ ಆಯ್ಕೆಯನ್ನು ತೋರಿಸುತ್ತದೆ, ಸುರಂಗ ಸಕ್ರಿಯವಾಗಿದೆ, ಮತ್ತು ಆಂತರಿಕ ಹೆಸರುಗಳು ಇನ್ನೂ ವಿಫಲವಾಗುತ್ತವೆ. ರಿಸಾಲ್ವರ್ಗೆ ನೇರ ಪ್ರಶ್ನೆ ಉತ್ತರಿಸುತ್ತದೆ, ಹಾಗಾಗಿ ಸರ್ವರ್ ಸರಿಯಾಗಿದೆ, ಆದರೆ ಪ್ರತಿ ಅಪ್ಲಿಕೇಶನ್ ಸ್ಥಳೀಯ ರೌಟರ್ ಅನ್ನೇ ಕೇಳುತ್ತಿದೆ. ಕ್ಲೈಂಟ್ಗೆ ತಲುಪಿದ್ದು ಪ್ರಸ್ತಾಪ, ರಿಸಾಲ್ವರ್ನಲ್ಲಿ ಬದಲಾವಣೆ ಅಲ್ಲ, ಮತ್ತು ಹೆಸರು ಪರಿಹರಿಸುವಿಕೆಯನ್ನು ಹೊಂದಿರುವ ಘಟಕ Linux, Windows ಮತ್ತು macOS ನಲ್ಲಿ ಭಿನ್ನವಾಗಿದೆ. ಆಯ್ಕೆಯನ್ನು ಅದರ ಒಡೆಯನಿಂದ ಬೇರ್ಪಡಿಸಿದರೆ, ನಾಲ್ಕು ದೋಷಗಳು ಬಹುತೇಕ ಪ್ರತಿ ವರದಿಯನ್ನು ಆವರಿಸುತ್ತವೆ: ಹುಕ್ ಇಲ್ಲ, ಎರಡು ಸ್ಪರ್ಧಿಸುವ ಹುಕ್ಗಳು, ವಿಭಜಿತ DNS ವಿನ್ಯಾಸದಂತೆ ಕೆಲಸ ಮಾಡುತ್ತಿದೆ, ಅಥವಾ ಸರ್ವರ್ ಬದಲು ಸಫಿಕ್ಸ್ ಬೇಕಾದ ಸಣ್ಣ ಹೆಸರು.

ಪುಷ್ ಮಾಡಿದ ಆಯ್ಕೆ ಪ್ರಸ್ತಾಪ, ಅನುಸ್ಥಾಪನೆ ಅಲ್ಲ

ಸರ್ವರ್ನಲ್ಲಿ ಎರಡು ನಿರ್ದೇಶನಗಳು ಪರಿಣಾಮವನ್ನಲ್ಲ, ಉದ್ದೇಶವನ್ನು ವಿವರಿಸುತ್ತವೆ:

push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"

ಕ್ಲೈಂಟ್ಗೆ ಸಂರಚಿತ ರಿಸಾಲ್ವರ್ ಸಿಗುವುದಿಲ್ಲ. ಅದಕ್ಕೆ ಪರಿಸರ ಚರಗಳು ಸಿಗುತ್ತವೆ, foreign_option_1 ಮತ್ತು ಮುಂದಿನವು, ಪುಷ್ ಮಾಡಿದ ಪ್ರತಿ ಸಾಲಿಗೆ ಒಂದು, ಮತ್ತು ಸ್ಥಳೀಯವಾದ ಯಾವುದೋ ಅವನ್ನು ಓದಿ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಂನ ರಿಸಾಲ್ವರ್ ಸ್ಥಿತಿಯನ್ನು ಮರುಬರೆಯಬೇಕು. Linux ನಲ್ಲಿ ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಯಾವುದೂ ಹಾಗೆ ಮಾಡುವುದಿಲ್ಲ, ಹಾಗಾಗಿ ಸರಿಯಾದ ಸರ್ವರ್ ಮತ್ತು ಸಂಪರ್ಕಿತ ಕ್ಲೈಂಟ್ ಇನ್ನೂ LAN ಮೂಲಕ ಹೆಸರುಗಳನ್ನು ಪರಿಹರಿಸಬಹುದು.

ಎರಡು ತುದಿಗಳ ನಡುವೆ ಮೂರು ಹಂತಗಳಿವೆ: ಪುಷ್ ತಲುಪಬೇಕು, ಕ್ಲೈಂಟ್ ಅದನ್ನು ಬಹಿರಂಗಪಡಿಸಬೇಕು, ಮತ್ತು ಹುಕ್ ಅದನ್ನು ಅನ್ವಯಿಸಬೇಕು. ಮಧ್ಯದ ಹಂತವನ್ನು ಕ್ಲೈಂಟ್ ಲಾಗ್ನಲ್ಲಿ ಮತ್ತು ಕೊನೆಯ ಹಂತವನ್ನು ರಿಸಾಲ್ವರ್ ಸ್ಥಿತಿಯಲ್ಲಿ ಓದಿ, ಎಂದಿಗೂ ತಿರುಗುಮುರುಗವಾಗಿ ಅಲ್ಲ, ಏಕೆಂದರೆ ಲಾಗ್ನ ಒಂದು ಸಾಲು ಮೊದಲ ಎರಡನ್ನು ಮಾತ್ರ ಸಾಬೀತು ಮಾಡುತ್ತದೆ.

ಪುಷ್ ತಲುಪಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ ಮತ್ತು ಒಡೆಯನನ್ನು ಹುಡುಕಿ

ಪ್ರಾರಂಭಕನನ್ನು ಹೆಸರಿಸುವುದರಿಂದ ಆರಂಭಿಸಿ: ಬರಿಯ openvpn ಆಜ್ಞೆ, systemd ಸಂದರ್ಭ, NetworkManager ಅಥವಾ ಮಾರಾಟಗಾರನ ಕ್ಲೈಂಟ್. ಇದು ಹುಕ್ ಎಲ್ಲಿ ವಾಸಿಸಬಹುದೆಂದು ನಿರ್ಧರಿಸುತ್ತದೆ. systemd-resolved ಇರುವ ಹೋಸ್ಟ್ನಲ್ಲಿ, resolvectl status ಪ್ರತಿ ಲಿಂಕ್ ಅನ್ನು ಅದು ನಿಜವಾಗಿ ಬಳಸುವ DNS ಸರ್ವರ್ಗಳು ಮತ್ತು ಹುಡುಕಾಟ ಕ್ಷೇತ್ರಗಳೊಂದಿಗೆ ಪಟ್ಟಿಮಾಡುತ್ತದೆ, ಮತ್ತು ಸುರಂಗದ ಲಿಂಕ್ ಯಾವಾಗಲೂ tun0 ಎಂದು ಕರೆಯಲ್ಪಡುವುದಿಲ್ಲ.

ಪುಷ್ ಮಾಡಿದ ವಿಳಾಸ ಲಾಗ್ನಲ್ಲಿದ್ದರೂ ಯಾವುದೇ ಲಿಂಕ್ನಲ್ಲಿ ಇಲ್ಲದಿದ್ದರೆ, ಸಂಯೋಜನೆ ಇಲ್ಲ. ಅದು ಲಿಂಕ್ನಲ್ಲಿದ್ದು ಪ್ರಶ್ನೆಗಳು ಇನ್ನೂ ಬೇರೆಡೆ ಹೋದರೆ, ಸಮಸ್ಯೆ ಏನೆಂದರೆ ಯಾವ ಪ್ರಶ್ನೆಗಳು ಆ ಲಿಂಕ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತವೆ. NetworkManager dns=dnsmasq ಫೈಲ್ನಲ್ಲಿ /etc/NetworkManager/NetworkManager.conf ಸ್ಥಳೀಯ ಮುಂದೂಡುಗವನ್ನು ನಡೆಸುತ್ತದೆ, ಅದು ವಿಭಜಿತ DNS ಅನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಅನ್ವಯಿಸುತ್ತದೆ: VPN ಕ್ಷೇತ್ರದೊಳಗಿನ ಹೆಸರುಗಳು VPN ರಿಸಾಲ್ವರ್ಗೆ ಹೋಗುತ್ತವೆ, ಉಳಿದೆಲ್ಲವೂ ತನ್ನ ಹಿಂದಿನ ಮಾರ್ಗವನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ. ಎಲ್ಲ ಸಂಚಾರ ಸರಿಯುತ್ತದೆ ಎಂದು ನಿರೀಕ್ಷಿಸಿದಾಗ ಈ ವರ್ತನೆ ದೋಷದಂತೆ ಕಾಣುತ್ತದೆ; ಪ್ರತಿ ಸಂಪರ್ಕದ ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ nmcli connection show "My VPN" ಮೂಲಕ, ಅಲ್ಲಿ ipv4.dns ಮತ್ತು ipv4.dns-search ಸಾಧನ ವರದಿ ಮಾಡುವುದರ ಹಿಂದಿನ ಮೌಲ್ಯಗಳನ್ನು ಹಿಡಿದಿಡುತ್ತವೆ, ಅದನ್ನು ಮುರಿದದ್ದು ಎಂದು ಕರೆಯುವ ಮೊದಲು. ಪ್ರತಿ ಪ್ರಶ್ನೆಯೂ ನಿಜವಾಗಿ VPN ರಿಸಾಲ್ವರ್ ತಲುಪಬೇಕಿದ್ದರೆ, ತೆಗೆದುಹಾಕಿ dns=dnsmasq ಅನ್ನು NetworkManager.conf ಫೈಲ್ನಿಂದ ಮತ್ತು NetworkManager ಮರುಪ್ರಾರಂಭಿಸಿ, ಅದು ಹೆಸರು ಪರಿಹರಿಸುವಿಕೆಯನ್ನು ಸಂಪರ್ಕ ಸೆಟ್ಟಿಂಗ್ಗಳಿಗೆ ಹಿಂತಿರುಗಿಸುತ್ತದೆ; ಇಲ್ಲದಿದ್ದರೆ ವಿಭಜಿತ DNS ಉಳಿಸಿ ಮತ್ತು ಪುಷ್ ಮಾಡಿದ ಕ್ಷೇತ್ರಗಳ ಪಟ್ಟಿಯನ್ನು ಸರಿಪಡಿಸಿ.

Linux: ಆಯ್ಕೆಗಳನ್ನು ರಿಸಾಲ್ವರ್ಗೆ ಒಪ್ಪಿಸಿ

ವಿತರಣಾ ಪ್ಯಾಕೇಜುಗಳು ಇದಕ್ಕಾಗಿ ಹುಕ್ ಒದಗಿಸುತ್ತವೆ, ಮತ್ತು ಕ್ಲೈಂಟ್ಗೆ ಅದನ್ನು ಚಲಾಯಿಸಲು ಅನುಮತಿ ಇರಬೇಕು. systemd-resolved ಇಲ್ಲದ ಹೋಸ್ಟ್ನಲ್ಲಿ ಸಾಮಾನ್ಯ ಜೋಡಣೆ:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

systemd-resolved ಇದ್ದಾಗ ಹಳೆಯ resolv.conf ಸ್ಕ್ರಿಪ್ಟ್ ಮುಖ್ಯವಾದದ್ದನ್ನು ಬದಲಿಸದಿರಬಹುದು, ಏಕೆಂದರೆ stub ರಿಸಾಲ್ವರ್ ಪ್ರತಿ ಲಿಂಕ್ಗೆ ಸ್ಥಿತಿ ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ. update-systemd-resolved ಸಹಾಯಕವು ಬಳಸುವ ಹುಕ್ ರೂಪವನ್ನು ದಾಖಲಿಸುತ್ತದೆ up-restart ಮತ್ತು down-pre, ಇದು ಇಂಟರ್ಫೇಸ್ ಒಂದೇ ಸಂಪರ್ಕ ಪ್ರಯತ್ನಕ್ಕಿಂತ ಹೆಚ್ಚು ಬದುಕಿದಾಗ ಮಹತ್ವದ್ದಾಗಿದೆ. ಯಾವುದೇ ಆಯ್ಕೆ ಮಾಡಿದರೂ, ಸ್ಥಿತಿಯ ಒಡೆತನ ಒಂದು ಘಟಕಕ್ಕೆ ಇರಬೇಕು. NetworkManager ಪಕ್ಕದಲ್ಲಿ ಸಂಬಂಧವಿಲ್ಲದ ಹುಕ್ ಸೇರಿಸಿದರೆ ಅದೇ ಲಿಂಕ್ಗೆ ಇಬ್ಬರು ಬರಹಗಾರರಾಗುತ್ತಾರೆ, ಮತ್ತು ಫಲಿತಾಂಶ ಆಗ ನಿಮ್ಮ ಸಂರಚನೆಯನ್ನಲ್ಲ, ಕ್ರಮವನ್ನೇ ಅವಲಂಬಿಸುತ್ತದೆ.

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

Windows ಮತ್ತು macOS ಬೇರೆ ಬೇರೆ ಭಾಗಗಳನ್ನು ಅನ್ವಯಿಸುತ್ತವೆ

Windows ಕ್ಲೈಂಟ್ VPN ಅಡಾಪ್ಟರ್ನ DNS ಸರ್ವರ್ಗಳನ್ನು ನಿಜವಾಗಿ ಸೆಟ್ ಮಾಡುತ್ತದೆ, ಆದರೆ Windows ಇನ್ನೂ ಮೆಟ್ರಿಕ್ನಿಂದ ಇಂಟರ್ಫೇಸ್ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಸಣ್ಣ ಹೆಸರನ್ನು ವಿಸ್ತರಿಸಲು ಇನ್ನೂ ಸಫಿಕ್ಸ್ ಬೇಕು. ಪ್ರೊಫೈಲ್ ಅಲ್ಲ, ಅಡಾಪ್ಟರ್ ಸ್ಥಿತಿಯನ್ನು ಖಚಿತಪಡಿಸಿ:

Get-DnsClientServerAddress -InterfaceAlias "My VPN"
Get-DnsClientNrptPolicy

ವಿಳಾಸ ಇಲ್ಲದಿದ್ದರೆ, ಅದನ್ನು ಇದರಿಂದ ಸೆಟ್ ಮಾಡಿ Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, ನಂತರ ಸಫಿಕ್ಸ್ ಅನ್ನು ಅಡಾಪ್ಟರ್ನ IPv4 ಗುಣಲಕ್ಷಣಗಳಿಗೆ ಸೇರಿಸಿ ಇದರಿಂದ fileserver ಆಗುತ್ತದೆ fileserver.corp.example. ಯಂತ್ರದಾದ್ಯಂತದ SearchList ಮೌಲ್ಯ Tcpip\Parameters ಅಡಿಯಲ್ಲಿ ಅದೇ ರೀತಿ ಮಾಡುತ್ತದೆ. ಉದ್ದ ಹೆಸರು ಪರಿಹರಿಸಿ ಬರಿಯ ಹೆಸರು ಪರಿಹರಿಸದಿದ್ದರೆ, ರಿಸಾಲ್ವರ್ ಈಗಾಗಲೇ ಸರಿಯಾಗಿದೆ ಮತ್ತು ತಪ್ಪು ಹುಡುಕಾಟ ಪಟ್ಟಿಯದು. ಸರಿಪಡಿಸುವಿಕೆಗಳು ಕ್ರಮವಾಗಿ: ಪುಷ್ ಮಾಡಿ DOMAIN ಕ್ಲೈಂಟ್ ಸಫಿಕ್ಸ್ ಕಲಿಯಲು, ಆ ಸಫಿಕ್ಸ್ ಅನ್ನು ಅಡಾಪ್ಟರ್ ಅಥವಾ ಸಂಪರ್ಕದ ಹುಡುಕಾಟ ಪಟ್ಟಿಗೆ ಸೇರಿಸಿ, ಮತ್ತು ತಾತ್ಕಾಲಿಕ ಕ್ರಮವಾಗಿ ಹೆಸರನ್ನು ಇಲ್ಲಿ ಸ್ಥಿರಗೊಳಿಸಿ hosts ಫೈಲ್ನಲ್ಲಿ, ಅಥವಾ LMHOSTS ನಲ್ಲಿ Windows ನಲ್ಲಿ; NetBIOS ಬ್ರೌಸಿಂಗ್ ರೌಟರ್ ದಾಟುವುದಿಲ್ಲ, ಹಾಗಾಗಿ ಕಚೇರಿ LAN ನಲ್ಲಿ ಸಣ್ಣ ಹೆಸರು ಹುಡುಕುವ ಪ್ರಸಾರ ಸುರಂಗ ಕ್ಲೈಂಟ್ಗೆ ಎಂದಿಗೂ ತಲುಪುವುದಿಲ್ಲ.

block-outside-dns block-outside-dns Windows ಕ್ಲೈಂಟ್ನ ವರ್ತನೆ, ಸಾಗಿಸಬಹುದಾದ ಪ್ರೊಫೈಲ್ ಸಾಲಲ್ಲ, ಮತ್ತು ಅದನ್ನು Linux ಅಥವಾ macOS ಪ್ರೊಫೈಲ್ಗೆ ನಕಲಿಸಿದರೆ ಅಲ್ಲಿ ಪುನರುತ್ಪಾದಿಸುವುದಿಲ್ಲ. Windows ನಲ್ಲಿ ಸಾರ್ವಜನಿಕ ಹೆಸರುಗಳು ಕೆಲಸ ಮಾಡಿ ಆಂತರಿಕವು ವಿಫಲವಾದರೆ, ಸುಧಾರಿತ ಸೆಟ್ಟಿಂಗ್ಗಳ ಅಡಿಯಲ್ಲಿ ಅಡಾಪ್ಟರ್ ಕ್ರಮವನ್ನು ಹೋಲಿಸಿ ipconfig /all ಜೊತೆಗೆ. macOS ನಲ್ಲಿ ಪ್ರತಿ ಸೇವೆಯ ರಿಸಾಲ್ವರ್ ಕ್ರಮ ವ್ಯವಸ್ಥೆಗೆ ಸೇರಿದ್ದು, ಆದ್ದರಿಂದ ಬಳಸಿ scutil --dns ಯಾವ ಕ್ಷೇತ್ರಕ್ಕೆ ಯಾವ ರಿಸಾಲ್ವರ್ ಕೇಳಲ್ಪಡುತ್ತದೆ ಎಂದು ನೋಡಲು, ಮತ್ತು ವರದಿಯಾದ ಯಾವುದೇ ಒಂಟಿ ಪ್ರೊಫೈಲ್ ಸರಿಪಡಿಸುವಿಕೆಯನ್ನು ಸಾಮಾನ್ಯವಲ್ಲ, ಕ್ಲೈಂಟ್ ಅವಲಂಬಿತ ಎಂದು ಪರಿಗಣಿಸಿ.

ಅದೇ ಲ್ಯಾಪ್ಟಾಪ್ನಲ್ಲಿರುವ ವರ್ಚುವಲ್ ಯಂತ್ರ ಇದರಿಂದ ಏನನ್ನೂ ಆನುವಂಶಿಕವಾಗಿ ಪಡೆಯುವುದಿಲ್ಲ. ಅತಿಥಿಗೆ ಆಂತರಿಕ ಕ್ಷೇತ್ರಕ್ಕಾಗಿ ತನ್ನದೇ ರಿಸಾಲ್ವರ್ ನಮೂದನ್ನು ನೀಡಿ, ಅಥವಾ ಹೈಪರ್ವೈಸರ್ನ NAT ಅದರ ಪ್ರಶ್ನೆಗಳನ್ನು ಹೋಸ್ಟ್ ಮೂಲಕ ಮುಂದೂಡಲಿ, ಇದು ಹೋಸ್ಟ್ನ ಸುರಂಗ ಸಕ್ರಿಯವಾಗಿರುವವರೆಗೆ ಮಾತ್ರ ಸರಿ.

ಇತಿಹಾಸವೇ ಮೂರನೇ ಕಾರಣ. ಹಿಂದಿನ ಪ್ರೊಫೈಲ್ನ DNS ಸರ್ವರ್ಗಳು ಅಥವಾ ಸಫಿಕ್ಸ್ ಸೆಟ್ಟಿಂಗ್ಗಳು ಮರುಸಂಪರ್ಕಗಳನ್ನು ಉಳಿದುಕೊಳ್ಳಬಹುದು, ಆದ್ದರಿಂದ ಅಡಾಪ್ಟರ್ ಸರಿಯಾಗಿ ಕಾಣುತ್ತಿದ್ದು ಹುಡುಕಾಟಗಳು ಇನ್ನೂ ವಿಫಲವಾದರೆ, ಜೀವಂತ ಅಡಾಪ್ಟರ್ ಅನ್ನು ಹೋಲಿಸಿ Get-VpnConnection ಜೊತೆಗೆ ಮತ್ತು ಸರ್ವರ್ ಮುಟ್ಟುವ ಮೊದಲು ಹಳೆಯ ನಮೂದನ್ನು ಅಳಿಸಿ ಅಥವಾ ಮೇಲೆಬರೆಯಿರಿ.

ಪ್ರಶ್ನೆ ಎಲ್ಲಿಗೆ ಹೋಯಿತು ಎಂದು ಸಾಬೀತು ಮಾಡಿ

ಒಂದು ಹುಡುಕಾಟದ ಸಮಯದಲ್ಲಿ ಸೆರೆಹಿಡಿಯುವಿಕೆ ವಾದವನ್ನು ತೀರ್ಮಾನಿಸುತ್ತದೆ: tcpdump -ni eth0 port 53 ಭೌತಿಕ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಪ್ರಶ್ನೆಗಳನ್ನು ತೋರಿಸುತ್ತದೆ, ಅಂದರೆ ಅವು ಸುರಂಗದ ಹೊರಗೆ ಹೋಗುತ್ತಿವೆ ಮತ್ತು ರಿಸಾಲ್ವರ್ ಎಂದಿಗೂ ಬದಲಾಗಿಲ್ಲ. dig @10.8.0.1 name.corp.example ನಂತರ ಉಳಿದ ಎರಡು ಸಂದರ್ಭಗಳನ್ನು ಬೇರ್ಪಡಿಸುತ್ತದೆ. ನೇರ ಪ್ರಶ್ನೆ ಉತ್ತರಿಸಿದರೆ, ರಿಸಾಲ್ವರ್ ಕೆಲಸ ಮಾಡುತ್ತಿದೆ ಮತ್ತು ಕ್ಲೈಂಟ್ ಅದನ್ನು ಬಳಸುತ್ತಿಲ್ಲ; ಸಮಯ ಮೀರಿದರೆ, ರಿಸಾಲ್ವರ್ ಸುರಂಗದ ಮೂಲಕ ತಲುಪಲಾಗದು ಮತ್ತು ಯಾವುದೇ ಸ್ಥಳೀಯ ಬದಲಾವಣೆ ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ.

ಇನ್ನೂ ಬಳಕೆಯಲ್ಲಿರುವ ರಿಸಾಲ್ವರ್ ಒದಗಿಸುವವರು ಹಂಚಿದ್ದೇ ಆದರೆ, ಸುರಂಗ ಸಂಚಾರವನ್ನು ಗೂಢಲಿಪೀಕರಿಸುತ್ತದೆ ಆದರೆ ಹೆಸರುಗಳು ಆ ಒದಗಿಸುವವರಿಗೆ ಗೋಚರವಾಗಿ ಉಳಿಯುತ್ತವೆ. ಇದು ಕಾರ್ಯಕ್ಷಮತೆಯಲ್ಲ, ಸೋರಿಕೆಯ ಪ್ರಶ್ನೆ, ಮತ್ತು ಅದೇ ಸೆರೆಹಿಡಿಯುವಿಕೆ ಉತ್ತರಿಸುತ್ತದೆ: ಭೌತಿಕ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿನ ಪ್ರಶ್ನೆ ಸುರಂಗದ ಹೊರಗಿನ ಯಾರಿಗೋ ಹೋಗುತ್ತಿದೆ.

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

ಒಬ್ಬ ಒಡೆಯನನ್ನು ಇಟ್ಟುಕೊಳ್ಳಿ ಮತ್ತು ಕ್ರಮವಾಗಿ ಪರಿಶೀಲಿಸಿ

ಊಹಿಸಿದ ಸುರಂಗ ಸ್ಥಿತಿಯ ಆಧಾರದಲ್ಲಿ ಅಡಾಪ್ಟರ್ DNS ಅನ್ನು ಮರುಬರೆಯುವ ಸ್ಕ್ರಿಪ್ಟ್ ಪ್ರೊಫೈಲ್ ಈಗಾಗಲೇ ಹೊತ್ತಿರುವ ಸಂರಚನೆಯನ್ನು ನಕಲಿಸುತ್ತದೆ, ಮತ್ತು ಊಹೆ ಮೊದಲ ಬಾರಿ ತಪ್ಪಾದಾಗ ಸದ್ದಿಲ್ಲದೆ ವಿಫಲವಾಗುತ್ತದೆ. ಸಂಪರ್ಕದ ಸ್ವಂತ DNS ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ಅಥವಾ ಒಂದು ದಾಖಲಿತ ಹುಕ್ ಅನ್ನು ಆದ್ಯತೆ ನೀಡಿ, ಮತ್ತು ಯಾವುದನ್ನು ಆಯ್ಕೆ ಮಾಡಿದಿರಿ ಎಂದು ದಾಖಲಿಸಿ, ಮುಂದಿನ ವ್ಯಕ್ತಿ ಎರಡನೆಯದನ್ನು ಸೇರಿಸದಿರಲಿ.

ನಾಲ್ಕು ಪರಿಶೀಲನೆಗಳಿಂದ ಚಕ್ರವನ್ನು ಮುಚ್ಚಿ: ಪುಷ್ ಮಾಡಿದ ವಿಳಾಸ ಸುರಂಗ ಲಿಂಕ್ನಲ್ಲಿದೆ, ಆಂತರಿಕ ಹೆಸರು ಪೂರ್ಣ ಅರ್ಹ ಹೆಸರಾಗಿ ಪರಿಹರಿಸಲ್ಪಡುತ್ತದೆ, ಅದೇ ಹೆಸರು ಸಫಿಕ್ಸ್ ಇಲ್ಲದೆ ಪರಿಹರಿಸಲ್ಪಡುತ್ತದೆ, ಮತ್ತು ಒಂದು ಮರುಸಂಪರ್ಕದ ನಂತರವೂ ಎರಡೂ ನಿಜ. ಒಂದು ಸೆರೆಹಿಡಿಯುವಿಕೆ ನಾಲ್ಕರಲ್ಲಿ ಯಾವುದು ವಿಫಲವಾಯಿತು ಎಂದು ಹೇಳುತ್ತದೆ. OpenVPN 2.6 ಕೈಪಿಡಿ ಪಟ್ಟಿಮಾಡುತ್ತದೆ dhcp-option ಮತ್ತು ಸ್ಕ್ರಿಪ್ಟ್ ನಿರ್ದೇಶನಗಳನ್ನು ಅವುಗಳ ಪ್ಲಾಟ್ಫಾರ್ಮ್ ಟಿಪ್ಪಣಿಗಳೊಂದಿಗೆ.