Android ಎಮ್ಯುಲೇಟರ್ ಮತ್ತು ಹೋಸ್ಟ್ VPN: DNS ಸ್ನ್ಯಾಪ್ಶಾಟ್ ಮತ್ತು NAT

ಎಮ್ಯುಲೇಟರ್, ಹೋಸ್ಟ್‌ನ ಬ್ರೌಸರ್‌ನಲ್ಲಿ ಸರಾಗವಾಗಿ ತೆರೆಯುವ build ಸರ್ವರ್ ಅನ್ನು ತಲುಪಲು ವಿಫಲವಾದಾಗ, ಉಪಯುಕ್ತ ಪ್ರಶ್ನೆ VPN ಕೆಲಸ ಮಾಡುತ್ತದೆಯೇ ಎಂಬುದಲ್ಲ. ಪ್ರಶ್ನೆ ಎಂದರೆ guest ಗೆ ಎರಡು ಯಾಂತ್ರಿಕೆಗಳಲ್ಲಿ ಯಾವುದು ಕಾಣೆಯಾಗಿದೆ ಎಂಬುದು. ವರ್ಚುವಲ್ ಸಾಧನವು ಎಮ್ಯುಲೇಟರ್ NAT ಹಿಂದೆ ತನ್ನದೇ ನೆಟ್‌ವರ್ಕ್ stack ಅನ್ನು ನಡೆಸುತ್ತದೆ, ಮತ್ತು ಅದರ resolver ಪಟ್ಟಿ boot ಸಮಯದಲ್ಲಿ ತೆಗೆದ ಪ್ರತಿ, ಹೀಗಾಗಿ ನಂತರ ಬಂದ tunnel ಹೋಸ್ಟ್ ಮಾರ್ಗವನ್ನು ಬದಲಿಸುತ್ತದೆ, ಆದರೆ guest ಕೇಳುವುದನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ. ಈ ಎರಡು ಪದರಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಈ ಸಮಸ್ಯೆಯ ಬಹುತೇಕ ಎಲ್ಲಾ ರೂಪಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ.

Guest ಸ್ಥಿರ NAT ಹಿಂದೆ ಪ್ರತ್ಯೇಕ stack

QEMU ನ user-mode ನೆಟ್‌ವರ್ಕಿಂಗ್ guest ಅನ್ನು 10.0.2.15 ನಲ್ಲಿ, gateway ಅನ್ನು 10.0.2.2 ನಲ್ಲಿ, ಮತ್ತು DNS ಸೇವೆಯನ್ನು 10.0.2.3 ರಿಂದ 10.0.2.6 ವರೆಗೆ ಇಡುತ್ತದೆ. Guest ನ ಹೊರಹೋಗುವ traffic ಅನ್ನು ಹೋಸ್ಟ್ kernel forward ಮಾಡುವುದಿಲ್ಲ; ಅದು ಹೋಸ್ಟ್ ಬದಿಯ socket ಗಳಾಗಿ ಪರಿವರ್ತನೆಯಾಗುತ್ತದೆ, ಪ್ರತಿ guest ಸಂಪರ್ಕಕ್ಕೆ ಒಂದು, ಮತ್ತು ಆ socket ಗಳು ಹೋಸ್ಟ್ ನ address space ನಿಂದ ಹೊರಬರುತ್ತವೆ. ಆದ್ದರಿಂದ guest ಸಂಪರ್ಕವು ಸೃಷ್ಟಿಯಾದ ಕ್ಷಣದಲ್ಲಿ ಹೋಸ್ಟ್ ನ routing ನಿರ್ಣಯವನ್ನು ಆನುವಂಶಿಕವಾಗಿ ಪಡೆಯುತ್ತದೆ, ಮತ್ತು ಆದ್ದರಿಂದ guest ನ route table ನಲ್ಲಿ ನಿಮ್ಮ tunnel ಅನ್ನು ಹೆಸರಿಸುವ ನಮೂದು ಇಲ್ಲ.

ಅದೇ ಯಾಂತ್ರಿಕೆ guest ಗೆ ಉಪಯುಕ್ತ ಹೊರದಾರಿ ನೀಡುತ್ತದೆ. 10.0.2.2 ಹೋಸ್ಟ್ ನ loopback ಇಂಟರ್ಫೇಸ್ ನ alias, ಆದ್ದರಿಂದ ಲ್ಯಾಪ್‌ಟಾಪ್‌ನ 127.0.0.1 ನಲ್ಲಿ ಕೇಳುತ್ತಿರುವ ಸೇವೆಯನ್ನು guest ನಿಂದ ಆ ವಿಳಾಸದಲ್ಲಿ ತಲುಪಬಹುದು. Client ಕೇವಲ loopback ನಲ್ಲಿ ಬಹಿರಂಗಪಡಿಸುವ ಯಾವುದನ್ನೂ ಆ ಮಾರ್ಗದಲ್ಲಿ ತಲುಪಬಹುದು, ಮತ್ತು ಇದೇ ಕೆಳಗೆ ವಿವರಿಸಿದ proxy ವ್ಯವಸ್ಥೆಯ ಆಧಾರ.

Guest ಮಾಡಲಾಗದ್ದು ಹೋಸ್ಟ್ ನೆಟ್‌ವರ್ಕ್ ಅನ್ನು ತನ್ನ namespace ಎಂಬಂತೆ ವೀಕ್ಷಿಸುವುದು. bridge ಇಲ್ಲ, ಹಂಚಿದ route table ಇಲ್ಲ ಮತ್ತು ಆನುವಂಶಿಕ resolver ಇಲ್ಲ; ಇರುವುದು ಅದರ packet ಗಳನ್ನು ಸ್ವೀಕರಿಸುವ NAT ಸೇವೆ ಮತ್ತು ವರ್ಚುವಲ್ ಸಾಧನ ಪ್ರಾರಂಭವಾದಾಗ launcher ತೆಗೆದ snapshot ಮಾತ್ರ.

DNS ಒಂದು snapshot, ಜೀವಂತ ನೋಟವಲ್ಲ

ಪ್ರಾರಂಭದಲ್ಲಿ ಎಮ್ಯುಲೇಟರ್ ಹೋಸ್ಟ್ ನ resolver ಪಟ್ಟಿಯನ್ನು ಓದಿ guest ಗೆ ನಾಲ್ಕರವರೆಗೆ ಸರ್ವರ್‌ಗಳನ್ನು ನೀಡುತ್ತದೆ, ಅವು 10.0.2.3 ರಿಂದ 10.0.2.6 ವಿಳಾಸಗಳಲ್ಲಿ ಬಹಿರಂಗವಾಗುತ್ತವೆ. ಆ ಕ್ಷಣದಲ್ಲಿ tunnel ಕೆಳಗಿದ್ದರೆ, snapshot ನಲ್ಲಿ ಲ್ಯಾಪ್‌ಟಾಪ್ ಬಳಸಿದ ಯಾವುದೇ public resolver ಇರುತ್ತದೆ, ಮತ್ತು guest ತನ್ನ ಜೀವಿತಾವಧಿಯ ಉದ್ದಕ್ಕೂ ಅದನ್ನೇ ಕೇಳುತ್ತದೆ. Public ಹೆಸರುಗಳು resolve ಆಗುತ್ತವೆ, ಒಳಗಿನ ಹೆಸರುಗಳು ವಿಫಲವಾಗುತ್ತವೆ, ಮತ್ತು ಎಲ್ಲಾ ಲಕ್ಷಣಗಳು VPN ಕಡೆ ತೋರಿಸುತ್ತವೆ, ಆದರೆ ನಿಜವಾದ ಹಳೆಯ ಮೌಲ್ಯ tunnel ಮೇಲೆ ಬರುವ ಕೆಲವು ನಿಮಿಷಗಳ ಮೊದಲು ಸೆರೆಹಿಡಿಯಲಾದ resolver ಪಟ್ಟಿ.

ಆದ್ದರಿಂದ ಕ್ರಮ ಸರಿಪಡಿಸುವುದು ಜನಪದವಲ್ಲ. ಮೊದಲು tunnel ಸಂಪರ್ಕಿಸಿ, ನಂತರ ಎಮ್ಯುಲೇಟರ್ ಮರುಪ್ರಾರಂಭಿಸಿ, ಮತ್ತು snapshot ಮರುಸ್ಥಾಪನೆಗಿಂತ cold boot ಆಯ್ಕೆಮಾಡಿ, ಏಕೆಂದರೆ quick-boot ಚಿತ್ರವು ಹಿಂದೆ ಉಳಿಸಿದ resolver ಮತ್ತು route ಸ್ಥಿತಿಯೊಂದಿಗೆ ಹಿಂತಿರುಗಬಹುದು. Guest ಈಗ ಏನು ಬಳಸುತ್ತಿದೆ ಎಂದು ನೋಡಬೇಕಿದ್ದರೆ, ಹೋಸ್ಟ್ ಅಲ್ಲ, ಸಾಧನವನ್ನೇ ಕೇಳಿ:

adb shell dumpsys connectivity | grep -i -A2 dns
adb shell ping -c 1 build.internal.example

ಎಮ್ಯುಲೇಟರ್ ಪ್ರಾರಂಭದಲ್ಲಿ ಸ್ಪಷ್ಟ resolver ಅನ್ನು ಸಹ ಸ್ವೀಕರಿಸುತ್ತದೆ, ಇದು guest ಯಾವ ಸರ್ವರ್ ಬಳಸಬೇಕೆಂದು ನಿಖರವಾಗಿ ತಿಳಿದಾಗ ಉಪಯುಕ್ತ ಮತ್ತು ಆ ಸರ್ವರ್ public ಆಗಿದ್ದಾಗ ಅಪಾಯಕಾರಿ:

emulator -avd Pixel_API_34 -dns-server 203.0.113.53

Public resolver ನಲ್ಲಿ ಒಳಗಿನ zone ನ ಪ್ರತಿ ಇಲ್ಲ, ಆದ್ದರಿಂದ ಒಂದನ್ನು ಪಿನ್ ಮಾಡುವುದು ಕ್ರಮದ ಸಮಸ್ಯೆಯನ್ನು ಶಾಶ್ವತ ವೈಫಲ್ಯವಾಗಿ ಬದಲಿಸುತ್ತದೆ. Profile private DNS push ಮಾಡಿದರೆ, tunnel ಅದನ್ನು ಒದಗಿಸಲಿ ಮತ್ತು ವಿಳಾಸವನ್ನು hard-code ಮಾಡುವ ಬದಲು guest ಅನ್ನು cold boot ಮಾಡಿ.

Routing ಸಂಪರ್ಕ ಸಮಯದಲ್ಲಿ ಹೋಸ್ಟ್ ಅನ್ನು ಅನುಸರಿಸುತ್ತದೆ

Guest ಸಂಪರ್ಕಗಳು ಹೋಸ್ಟ್ socket ಗಳಾಗುವುದರಿಂದ, routing ನಿರ್ಣಯ socket ಸೃಷ್ಟಿಯಾದಾಗ ತೆಗೆದುಕೊಳ್ಳಲಾಗುತ್ತದೆ. ವಿನಂತಿಗೆ ಮೊದಲು tunnel ಮೇಲಿದ್ದರೆ ವಿನಂತಿ profile route ಗಳಿಗೆ ಒಳಪಟ್ಟು tunnel ಮೂಲಕ ಹೊರಡುತ್ತದೆ. ಆಯ್ದ prefix ಗಳನ್ನು ಮಾತ್ರ ಸಾಗಿಸುವ split-tunnel profile ನಿಮ್ಮ private subnet ಅನ್ನು ಹೊರಗೆ ಬಿಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಹೋಸ್ಟ್ ತಲುಪುವಿಕೆ guest ಬಗ್ಗೆ ಒಂದು ಊಹೆ, ಫಲಿತಾಂಶವಲ್ಲ. ಇರುವ guest ಸಂಪರ್ಕಗಳು ಸೃಷ್ಟಿಯಾದ ಮಾರ್ಗವನ್ನೇ ಉಳಿಸಿಕೊಳ್ಳುತ್ತವೆ, ಆದ್ದರಿಂದ ಮರುಸಂಪರ್ಕಿಸುವ client ಎಮ್ಯುಲೇಟರ್ ಒಳಗೆ ನಿಂತಿರುವ ಡೌನ್‌ಲೋಡ್ ಅನ್ನು ಯಾವಾಗಲೂ ಸರಿಪಡಿಸುವುದಿಲ್ಲ.

ಪರಿಶೀಲನೆ ಹೋಸ್ಟ್ ಇಂಟರ್ಫೇಸ್ ನಲ್ಲಿ, guest ಅಂಕಿಅಂಶಗಳಲ್ಲಿ ಅಲ್ಲ:

sudo tcpdump -ni tun0 'host 203.0.113.10'

Guest ವಿನಂತಿ tunnel ಇಂಟರ್ಫೇಸ್ ನಲ್ಲಿ ಕಾಣಿಸಿದರೆ routing ಕೆಲಸ ಮಾಡುತ್ತಿದೆ ಮತ್ತು ಸಮಸ್ಯೆ ಅದರ ಮೇಲಿದೆ. ಅದು ಭೌತಿಕ ಇಂಟರ್ಫೇಸ್ ನಲ್ಲಿ ಕಾಣಿಸಿದರೆ profile ಆ prefix ಅನ್ನು ಒಳಗೊಳ್ಳುವುದಿಲ್ಲ, ಮತ್ತು guest ಬದಿಯ ಯಾವುದೇ ಮರುಸಂರಚನೆ ಅದನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ.

Client ಕೇವಲ loopback proxy ನೀಡಿದಾಗ

ಕೆಲವು ವಾಣಿಜ್ಯ client ಗಳು system tunnel ಅನ್ನು ಸೃಷ್ಟಿಸುವುದೇ ಇಲ್ಲ. ಅವು 127.0.0.1 ನಲ್ಲಿ HTTP ಅಥವಾ SOCKS listener ಬಹಿರಂಗಪಡಿಸಿ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಅದನ್ನು ಬಳಸುತ್ತವೆ ಎಂದು ನಿರೀಕ್ಷಿಸುತ್ತವೆ. Guest ಆ socket ಅನ್ನು ನೇರವಾಗಿ ನೋಡಲಾಗದು, ಆದರೆ ಎಮ್ಯುಲೇಟರ್‌ಗೆ ಅದನ್ನು ಬಳಸಲು ಹೇಳಬಹುದು, extended controls ಮೂಲಕ (Settings, ನಂತರ Proxy, manual mode, host 127.0.0.1 ಮತ್ತು client ಮುದ್ರಿಸಿದ port) ಅಥವಾ ಪ್ರಾರಂಭದಲ್ಲಿ:

emulator -avd Pixel_API_34 -http-proxy http://127.0.0.1:8080

Client ವಿಂಡೋದಿಂದ port ಅನ್ನು ನಕಲಿಸಿ; ಊಹಿಸಿದ port ಮೌನವಾಗಿ ವಿಫಲವಾಗಿ ಮುರಿದ tunnel ನಂತೆ ಕಾಣುತ್ತದೆ. ಇದು ಏನನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ ಎಂಬುದನ್ನು ನೆನಪಿಡಿ: HTTP proxy ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು proxy ಅರಿವಿರುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಗೌರವಿಸುತ್ತವೆ, ಮತ್ತು raw socket ಗಳು ಅದನ್ನು ಸಂಪೂರ್ಣ ನಿರ್ಲಕ್ಷಿಸುತ್ತವೆ. ಕೆಲಸ native binary ಆಗಿದ್ದು ತನ್ನದೇ ಸಂಪರ್ಕಗಳನ್ನು ತೆರೆದರೆ, proxy ಮಾರ್ಗ tunnel ಗೆ ಸಮಾನವಲ್ಲ ಮತ್ತು ಹೋಲಿಕೆಯನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಮಾಡಬೇಕು.

ಫಲಿತಾಂಶವನ್ನು guest ಒಳಗಿನಿಂದ ಸಾಬೀತುಪಡಿಸಿ

ಒಂದೇ session ನಲ್ಲಿ ಎರಡು ಪರೀಕ್ಷೆಗಳಿಂದ resolution ಮತ್ತು routing ಅನ್ನು ಬೇರ್ಪಡಿಸಿ. ಸಂಖ್ಯಾ ವಿಳಾಸ ಉತ್ತರಿಸುತ್ತಿರುವಾಗ ಹೆಸರು ವಿಫಲವಾದರೆ ಅದು DNS snapshot ಸಮಸ್ಯೆ, ಪರಿಹಾರ ಕ್ರಮ ಅಥವಾ ಸ್ಪಷ್ಟ resolver. ಎರಡೂ ವಿಫಲವಾದರೆ ಅದು routing ಅಥವಾ policy ಸೂಚಿಸುತ್ತದೆ, ಮತ್ತು ಮುಂದಿನ ಪರಿಶೀಲನೆ ಎಂದರೆ ಅಪ್ಲಿಕೇಶನ್ ತನ್ನದೇ ನೆಟ್‌ವರ್ಕ್ ನಿರ್ಬಂಧಗಳಿರುವ work profile ಒಳಗೆ ಓಡುತ್ತಿದೆಯೇ ಎಂಬುದು.

ಕೊನೆಯದಾಗಿ, ಯಾವ guest ನಲ್ಲಿ ಪರೀಕ್ಷಿಸುತ್ತಿದ್ದೀರಿ ಎಂದು ತಿಳಿಯಿರಿ. ಅತ್ಯಂತ ಹಳೆಯ ಎಮ್ಯುಲೇಟರ್ ಚಿತ್ರಗಳು guest ಬದಿಯ VPN client ಗೆ ಬೇಕಾದ tun ಬೆಂಬಲವಿಲ್ಲದೆ ಬಂದವು, ಆದ್ದರಿಂದ ಅಲ್ಲಿ ಯಾವ profile ಕೆಲಸ ಮಾಡಲಾಗಲಿಲ್ಲ; ಪ್ರಸ್ತುತ ಚಿತ್ರಗಳಲ್ಲಿ ಅದು ಇದೆ. ಪ್ರಸ್ತುತ ಚಿತ್ರದಲ್ಲಿ ವಿಫಲವಾಗುವ client client ಅಥವಾ profile ಸಮಸ್ಯೆ, ಮತ್ತು ಹೋಸ್ಟ್ tunnel ಮರುನಿರ್ಮಿಸುವುದು ಫಲಿತಾಂಶವನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ.