ಹೋಸ್ಟ್ VPN-ಗೆ ಸೇರಿದ ನಂತರ VirtualBox ಅತಿಥಿಯ DNS ಮುರಿಯುತ್ತದೆ

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

ನೀವು ಯಾವ ಅಡಾಪ್ಟರ್ ಮೋಡ್ ಡೀಬಗ್ ಮಾಡುತ್ತಿದ್ದೀರಿ ಎಂದು ಖಚಿತಪಡಿಸಿ

ಸರಳ NAT ಮೋಡ್ನಲ್ಲಿರುವ ಅಡಾಪ್ಟರ್ ಮಾತ್ರ ಈ ಲೇಖನ ವಿವರಿಸಿದಂತೆ ವರ್ತಿಸುತ್ತದೆ. ಬ್ರಿಡ್ಜ್ ಅಡಾಪ್ಟರ್ ತನ್ನದೇ ಗುರುತಿನೊಂದಿಗೆ ಭೌತಿಕ ಜಾಲದಲ್ಲಿ ಕುಳಿತಿರುತ್ತದೆ, NAT ಜಾಲವು ತನ್ನದೇ DHCP ಮತ್ತು DNS ಸೆಟ್ಟಿಂಗ್ಗಳಿರುವ ಹೆಸರಿಸಿದ ವರ್ಚುವಲ್ ಸ್ವಿಚ್, ಮತ್ತು ಅತಿಥಿಯ ಒಳಗಿನ VPN ಕ್ಲೈಂಟ್ ಸಂಪೂರ್ಣ ಎರಡನೇ ರಿಸಾಲ್ವರ್ ಸೇರಿಸುತ್ತದೆ. ಓದುವ ಮೊದಲು ಮೋಡ್ ಖಚಿತಪಡಿಸಿ, ಏಕೆಂದರೆ ಈ ಪ್ರತಿಯೊಂದು ಸಂದರ್ಭದಲ್ಲೂ ದುರಸ್ತಿ ಬೇರೆಯಾಗಿರುತ್ತದೆ.

ಒಂದು VM ಬೇರೆ ಬೇರೆ ಮೋಡ್ಗಳಲ್ಲಿ ಎರಡು ಅಡಾಪ್ಟರ್ಗಳನ್ನು ಹೊಂದಬಹುದು, ಮತ್ತು ಪರಿಣಾಮಕ್ಕೊಳಗಾದದ್ದು ಯಾವಾಗಲೂ ಮೊದಲನೆಯದಲ್ಲ.

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

ಅತಿಥಿಯ ರಿಸಾಲ್ವರ್ ಮೂಲಕ ಒಂದು ಹೆಸರನ್ನು ಅನುಸರಿಸಿ

ಒಂದು ಆಂತರಿಕ ಹೆಸರು ಮತ್ತು ಒಂದು ಸಾರ್ವಜನಿಕ ನಿಯಂತ್ರಣ ಹೆಸರು ಆರಿಸಿ, ನಂತರ ಎರಡನ್ನೂ ಎರಡೂ ಸ್ಥಳಗಳಲ್ಲಿ ಪರೀಕ್ಷಿಸಿ. ಖಾಸಗಿ ಹೆಸರು ರಿಸಾಲ್ವ್ ಆಗದಿರುವಾಗ ಸಾರ್ವಜನಿಕ ಹೆಸರು ರಿಸಾಲ್ವ್ ಆಗುವುದು ದೋಷವನ್ನು ಸಾಮಾನ್ಯ ಹೆಸರು ರಿಸಾಲ್ವಿಂಗ್ನಲ್ಲಿ ಅಲ್ಲ, ಖಾಸಗಿ ಪಥದಲ್ಲಿ ಗುರುತಿಸುತ್ತದೆ. ಕೇವಲ ಖಾಸಗಿ ಹೆಸರನ್ನು ಪರೀಕ್ಷಿಸಿದರೆ ಮುರಿದ ರಿಸಾಲ್ವರ್ ಮತ್ತು ಮುರಿದ ಮಾರ್ಗವನ್ನು ಪ್ರತ್ಯೇಕಿಸಲು ಸಾಧ್ಯವಾಗದು.

ಅತಿಥಿಯ ಒಳಗೆ ರಿಸಾಲ್ವರ್ ವಾಸ್ತವವಾಗಿ ಯಾವುದಕ್ಕೆ ಸಂರಚಿಸಲಾಗಿದೆ ಎಂದು ನೋಡಿ. systemd-resolved ಚಲಾಯಿಸುವ Ubuntu ಅತಿಥಿಯಲ್ಲಿ ಪ್ರತಿ-ಲಿಂಕ್ ಸ್ಥಿತಿ ಬಂದ ಸರ್ವರ್ಗಳನ್ನು ತೋರಿಸುತ್ತದೆ, ಮತ್ತು resolv.conf ಕಡತದಲ್ಲಿ ಸ್ಟಬ್ ವಿಳಾಸ ಮಾತ್ರ ಇರಬಹುದು, ಅದು ಸರಿಯಾದದ್ದೇ, ಸಂಶಯಾಸ್ಪದವಲ್ಲ. ಕೈಯಿಂದ ಸಂಪಾದಿಸಿದ ಕಡತ ಅಥವಾ ಪ್ರತ್ಯೇಕ ಎನ್ಕ್ರಿಪ್ಟೆಡ್-DNS ಕ್ಲೈಂಟ್ ಹುಡುಕಾಟಗಳನ್ನು ಬೇರೆಡೆಗೆ ಕಳುಹಿಸಬಹುದು. ಬದಲಾಯಿಸುವ ಮೊದಲು ಕಂಡದ್ದನ್ನು ಬರೆದಿಡಿ.

resolvectl status
resolvectl query app.internal.example

ಇಲ್ಲಿ ರಿಸಾಲ್ವಿಂಗ್ ಅನ್ನು ತಲುಪುವಿಕೆಯಿಂದ ಬೇರ್ಪಡಿಸಿ. ಸೇವೆ ತಲುಪಲಾಗದಿದ್ದಾಗ ಬರುವ ವಿಳಾಸ DNS ಅಲ್ಲ, ರೌಟಿಂಗ್ ಅಥವಾ ನೀತಿಯ ಪ್ರಶ್ನೆ.

ಆ ಅಡಾಪ್ಟರ್ನಲ್ಲಿ ಹೋಸ್ಟ್ ರಿಸಾಲ್ವರ್ ಮೋಡ್ ಪ್ರಯತ್ನಿಸಿ

VirtualBox ನ NAT DNS ಆಯ್ಕೆಗಳು ವಿಭಿನ್ನ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ವಿವರಿಸುತ್ತವೆ, ಮತ್ತು ಹೋಸ್ಟ್ನ ಸ್ವಂತ ರಿಸಾಲ್ವರ್ ಟನೆಲ್ನೊಂದಿಗೆ ಬದಲಾದಾಗ ಈ ವ್ಯತ್ಯಾಸ ಮುಖ್ಯವಾಗುತ್ತದೆ. DNS ಪ್ರಾಕ್ಸಿ ಅತಿಥಿಯ ವಿನಂತಿಗಳನ್ನು ತನಗೆ ನೀಡಿದ ಸರ್ವರ್ಗಳಿಗೆ ರವಾನಿಸುತ್ತದೆ. ಹೋಸ್ಟ್ ರಿಸಾಲ್ವರ್ ಮೋಡ್ ವಿನಂತಿಗಳನ್ನು ತಡೆಹಿಡಿದು ಹೋಸ್ಟ್ನ DNS API ಕರೆಯುತ್ತದೆ, ಮತ್ತು VPN ಕ್ಲೈಂಟ್ ಮರುಸಂರಚಿಸಿದ Windows ರಿಸಾಲ್ವರ್ ಅನುಸರಿಸುವ ಮೋಡ್ ಅದೇ.

ತಪ್ಪು ಕಾರ್ಯವಿಧಾನ ಸಕ್ರಿಯಗೊಳಿಸಿದರೆ ಆದೇಶ ಯಶಸ್ವಿಯಾಗುತ್ತದೆ ಆದರೆ ವರ್ತನೆ ಬದಲಾಗದು, ಇದು ಮಧ್ಯಾಹ್ನವನ್ನು ಕಳೆದುಕೊಳ್ಳುವ ಗೊಂದಲಮಯ ದಾರಿ.

VBoxManage modifyvm "work-ubuntu" --natdnshostresolver1 on

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

VPN ಮರುಸಂಪರ್ಕದ ಉದ್ದಕ್ಕೂ ಅದೇ ಪರೀಕ್ಷೆಗಳನ್ನು ಪುನರಾವರ್ತಿಸಿ

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

ಸಾರ್ವಜನಿಕ ರಿಸಾಲ್ವಿಂಗ್ ಕೆಲಸ ಮಾಡುವುದು ಖಾಸಗಿ ಪ್ರಶ್ನೆಗಳು ನಿಮ್ಮ ನೀತಿ ಬೇಡುವ ಪಥದಲ್ಲೇ ಉಳಿದವು ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.

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