TAP ಅಥವಾ TUN? Android OpenVPN ಕ್ಲೈಂಟ್‌ಗಳು ಮತ್ತು ಬ್ರಿಡ್ಜ್ ಮಾಡಿದ ಸರ್ವರ್‌ಗಳು
TAP ಇಥರ್ನೆಟ್ ಫ್ರೇಮ್‌ಗಳನ್ನು ಸಾಗಿಸುತ್ತದೆ, TUN IP ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಸಾಗಿಸುತ್ತದೆ, ಮತ್ತು Android ಆ್ಯಪ್ ಎರಡನೇ ಪ್ರಕಾರವನ್ನು ಮಾತ್ರ ಪಡೆಯುತ್ತದೆ. ಎರಡನ್ನೂ ಹೋಲಿಸಿ, ನಂತರ ಸರ್ವರ್ ಬದಿಯನ್ನು ಸರಿಪಡಿಸಿ.
ಲ್ಯಾಪ್‌ಟಾಪ್‌ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಪ್ರೊಫೈಲ್ ಫೋನ್‌ನಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ. ಸ್ಪಷ್ಟ ಹೆಜ್ಜೆ ಕ್ಲೈಂಟ್ ಕಾನ್ಫಿಗ್‌ನಲ್ಲಿ ಒಂದು ಪದ ಬದಲಾಯಿಸುವುದು. ಆ ಪದ ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಎರಡೂ ತುದಿಗಳು ಒಂದೇ ರೀತಿಯ ಸಂಚಾರದ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿಲ್ಲ.
TAP ಇಥರ್ನೆಟ್ ಫ್ರೇಮ್‌ಗಳನ್ನು ಸಾಗಿಸುತ್ತದೆ. TUN IP ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಸಾಗಿಸುತ್ತದೆ. Android VPN ಆ್ಯಪ್‌ಗೆ IP ಇಂಟರ್‌ಫೇಸ್ ನೀಡಲಾಗುತ್ತದೆ, ಇದು ಎರಡು ಜೋಡಣೆಗಳಲ್ಲಿ ಒಂದನ್ನು ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ ಮತ್ತು ಇನ್ನೊಂದನ್ನು ಅಲ್ಲ, ಕಾನ್ಫಿಗ್ ಏನೇ ಹೇಳಲಿ.
ಹೋಲಿಕೆ ಚಿಕ್ಕದು, ಆದರೆ ಇದನ್ನು ಫೋನ್‌ನಲ್ಲೇ ಸರಿಪಡಿಸಬಹುದೇ ಅಥವಾ ಸೇವೆಯನ್ನೇ ಬದಲಾಯಿಸಬೇಕೇ ಎಂದು ಅದು ನಿರ್ಧರಿಸುತ್ತದೆ.
ಬೇರೆ ಬೇರೆ ಪೇಲೋಡ್‌ಗಳ ಎರಡು ರೀತಿಯ ಟನೆಲ್
TAP ಇಂಟರ್‌ಫೇಸ್ ಇಥರ್ನೆಟ್ ಅಡಾಪ್ಟರ್‌ನಂತೆ ವರ್ತಿಸುತ್ತದೆ. ಅದು ಫ್ರೇಮ್‌ಗಳನ್ನು ಸಾಗಿಸುತ್ತದೆ, ಅಂದರೆ ARP, ಬ್ರಾಡ್‌ಕಾಸ್ಟ್ ಮತ್ತು IP ಯ ಕೆಳಗೆ LAN ಸಾಗಿಸುವ ಎಲ್ಲವನ್ನೂ. ಇದೇ ಬ್ರಿಡ್ಜಿಂಗ್ ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ: ಟನೆಲ್ ಬ್ರಾಡ್‌ಕಾಸ್ಟ್ ಡೊಮೇನ್ ಅನ್ನು ವಿಸ್ತರಿಸುತ್ತದೆ ಮತ್ತು ಕ್ಲೈಂಟ್‌ಗಳು ಸ್ವಿಚ್‌ಗೆ ಸೇರಿಸಲ್ಪಟ್ಟಂತೆ ವರ್ತಿಸುತ್ತವೆ.
TUN ಇಂಟರ್‌ಫೇಸ್ ತನಗೆ ವಿಳಾಸ ಮಾಡಿದ IP ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಸಾಗಿಸುತ್ತದೆ. ಮಾತುಕತೆಗೆ ಯಾವುದೇ ಲಿಂಕ್ ಲೇಯರ್ ಇಲ್ಲ, ARP ಇಲ್ಲ ಮತ್ತು ಬ್ರಾಡ್‌ಕಾಸ್ಟ್ ಇಲ್ಲ. ಟನೆಲ್‌ಗೆ ಏನು ಪ್ರವೇಶಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ರೂಟಿಂಗ್ ನಿರ್ಧರಿಸುತ್ತದೆ, ಮತ್ತು ಸರ್ವರ್ ಬದಿಯ ಕಾನ್ಫಿಗ್ ಬ್ರಿಡ್ಜ್ ಬದಲು ಸಬ್‌ನೆಟ್ ಬಳಸುತ್ತದೆ.
ಎರಡೂ ತುದಿಗಳು ಇವುಗಳಲ್ಲಿ ಯಾವುದನ್ನು ಮಾಡುತ್ತಿವೆ ಎಂದು ಒಪ್ಪಬೇಕು. ಒಂದು ಬದಿಯಲ್ಲಿ dev tap ಅನ್ನು dev tun ಗೆ ಬದಲಾಯಿಸುವುದು ಸೇವೆಯನ್ನು ಪರಿವರ್ತಿಸುವುದಿಲ್ಲ; ಅದು ರೂಟ್ ಆದ ಟನೆಲ್ ನಿರೀಕ್ಷಿಸುವ ಕ್ಲೈಂಟ್ ಮತ್ತು ಇನ್ನೂ ಫ್ರೇಮ್ ಕಳುಹಿಸುವ ಸರ್ವರ್ ಅನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ, ಮತ್ತು ಉಪಯುಕ್ತವಾದುದು ಏನೂ ದಾಟದಿದ್ದರೂ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಯಶಸ್ವಿಯಾಗಬಹುದು.
Android ಆ್ಯಪ್‌ಗೆ ವಾಸ್ತವವಾಗಿ ಏನನ್ನು ನೀಡುತ್ತದೆ
ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನ VpnService API ಆ್ಯಪ್‌ಗೆ IP ಪ್ಯಾಕೆಟ್‌ಗಳಿಗಾಗಿ ವರ್ಚುಯಲ್ ಇಂಟರ್‌ಫೇಸ್ ನೀಡುತ್ತದೆ, ಅದು ವಿಳಾಸಗಳು, ರೂಟ್‌ಗಳು ಮತ್ತು MTU ಯಿಂದ ಕಾನ್ಫಿಗರ್ ಆಗಿದೆ. ಆ API ಯಲ್ಲಿ ಯಾವುದೇ ಇಥರ್ನೆಟ್ ಅಡಾಪ್ಟರ್ ಇಲ್ಲ, ಮತ್ತು ಆ್ಯಪ್ ಒಂದನ್ನು ಸೃಷ್ಟಿಸುವ ದಾರಿಯೂ ಇಲ್ಲ.
ಅದಕ್ಕೇ OpenVPN Connect Android ನಲ್ಲಿ TAP ಬ್ರಿಡ್ಜಿಂಗ್ ಬದಲು ರೂಟ್ ಆದ TUN ಸಂಪರ್ಕಗಳ ಬೆಂಬಲವನ್ನು ದಾಖಲಿಸುತ್ತದೆ. Android FAQ ಈ ಮಿತಿಯ ಕ್ಲೈಂಟ್-ಬದಿಯ ಹೇಳಿಕೆ, ಮತ್ತು ಅದು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ API ಗೆ ಹೊಂದುತ್ತದೆ.
ರೂಟ್ ನೆಟ್‌ವರ್ಕಿಂಗ್ ಪರಿಕರಗಳು, ಕಸ್ಟಮ್ ಫರ್ಮ್‌ವೇರ್ ಅಥವಾ ಸ್ಪಷ್ಟ ಅನುವಾದ ಪದರವನ್ನು ಅಳವಡಿಸುವ ಉತ್ಪನ್ನ ಬೇರೆ ಜೋಡಣೆಗಳು. ಸಾಮಾನ್ಯ ಪ್ರಕರಣವೇ ಯೋಜನೆ ಮಾಡಬೇಕಾದದ್ದು: ನಿಮ್ಮ ಫೈಲ್ ಅನ್ನು ಆಮದು ಮಾಡಿಕೊಂಡು ಸಾಮಾನ್ಯ ಬಳಕೆದಾರರಾಗಿ ಚಲಿಸಬಲ್ಲ ಆ್ಯಪ್, IP ಇಂಟರ್‌ಫೇಸ್‌ನೊಂದಿಗೆ ಮತ್ತು ಅದರ ಕೆಳಗೆ ಏನೂ ಇಲ್ಲದೆ.
ಹಾಗಿದ್ದರೂ ಪ್ರಯತ್ನಿಸಿದಾಗ ಹೇಗೆ ಕಾಣುತ್ತದೆ
ಸಂಪರ್ಕ ಸಾಮಾನ್ಯವಾಗಿ ಸ್ಥಾಪನೆಯಾಗುತ್ತದೆ. ಅದೇ ವೈಫಲ್ಯವನ್ನು ಗೊಂದಲಮಯಗೊಳಿಸುತ್ತದೆ: ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕವಾಗಿದೆ ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ, ಸರ್ವರ್ ಲಾಗ್ ಸಹಭಾಗಿಯನ್ನು ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ಯಾವುದೇ ಅಪ್ಲಿಕೇಶನ್ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ.
ಫೋನ್‌ಗೆ ನಿಗದಿಪಡಿಸಿದ ವಿಳಾಸಕ್ಕೆ ಕಳುಹಿಸಿದ ಸಂಚಾರ ತಲುಪುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಸರ್ವರ್ ಫ್ರೇಮ್‌ಗಳನ್ನು ಫೋನ್ ಎಂದೂ ಹೊಂದಿರದ MAC ವಿಳಾಸಕ್ಕೆ ಬ್ರಿಡ್ಜ್ ಮಾಡುತ್ತದೆ. ಬ್ರಾಡ್‌ಕಾಸ್ಟ್ ಅವಲಂಬಿತ ಶೋಧ ಖಾಲಿಯಾಗಿರುತ್ತದೆ. LAN ಬ್ರಿಡ್ಜ್ ಮೂಲಕ DHCP ಅನ್ನು ಅವಲಂಬಿಸಿದರೆ, ಫೋನ್ ಆ ರೀತಿಯಲ್ಲಿ ಲೀಸ್ ಪಡೆಯುವುದಿಲ್ಲ, ಮತ್ತು ಬ್ರಿಡ್ಜ್ ಮಾಡಿದ ಸಬ್‌ನೆಟ್‌ನಲ್ಲಿ ಕೈಯಿಂದ ನೀಡಿದ ವಿಳಾಸವೂ ಕಾಣೆಯಾದ ಇಂಟರ್‌ಫೇಸ್ ಅನ್ನು ಸೃಷ್ಟಿಸುವುದಿಲ್ಲ.
ಕೆಲವು ಕ್ಲೈಂಟ್‌ಗಳು ಹಿಂದೆಯೇ ವಿಫಲವಾಗುತ್ತವೆ, ಪ್ರೊಫೈಲ್ ಆಮದಿನಲ್ಲಿ, ಅಳವಡಿಸಲಾಗದ ಸಾಧನ ಪ್ರಕಾರವನ್ನು ಕಂಡಾಗ. ಎರಡೂ ವರ್ತನೆಗಳು ಒಂದೇ ಅರ್ಥ, ಮತ್ತು ರೂಟ್ ಸೇರಿಸುವುದರಿಂದ, DNS ಬದಲಾಯಿಸುವುದರಿಂದ ಅಥವಾ ಟನೆಲ್‌ನ ವಿಳಾಸ ಶ್ರೇಣಿಯನ್ನು ವಿಸ್ತರಿಸುವುದರಿಂದ ಯಾವುದೂ ಸರಿಯಾಗುವುದಿಲ್ಲ.
ಸರ್ವರ್ ಬದಿ ಏನನ್ನು ಬದಲಾಯಿಸಬೇಕು
ಸರಿಪಡಿಸುವುದು VPN ಸೇವೆ ನಡೆಸುವವರಿಗೆ ಸೇರಿದ್ದು, ಮತ್ತು ಅದು ಸಾಮಾನ್ಯವಾಗಿ ಸ್ಥಳಾಂತರವಲ್ಲ, ಹೆಚ್ಚಳ. ರೂಟ್ ಆದ ಸಾಧನ, ತನ್ನದೇ ಕ್ಲೈಂಟ್ ಸಬ್‌ನೆಟ್ ಮತ್ತು ವಿಳಾಸಗಳನ್ನು ನೀಡಿ ಫೋನ್‌ಗಳಿಗೆ ಬೇಕಾದ ರೂಟ್‌ಗಳನ್ನು ತಳ್ಳುವ ಸರ್ವರ್ ಬದಿಯ ಕಾನ್ಫಿಗ್‌ನೊಂದಿಗೆ ಎರಡನೇ OpenVPN ಪ್ರತಿಯನ್ನು ಚಲಾಯಿಸಿ. ಇರುವ ಬ್ರಿಡ್ಜ್ ಪ್ರತಿ ನಿಜವಾಗಿ ಇಥರ್ನೆಟ್ ಬೇಕಾದ ಸಾಧನಗಳಿಗೆ ಸೇವೆ ಸಲ್ಲಿಸುತ್ತಲೇ ಇರುತ್ತದೆ.
ಎರಡು ವಿವರಗಳು ಇದನ್ನು ಆಚರಣೆಯಲ್ಲಿ ಕೆಲಸ ಮಾಡಿಸುತ್ತವೆ. LAN ಗೆ ಹೊಸ ಕ್ಲೈಂಟ್ ಸಬ್‌ನೆಟ್‌ಗಾಗಿ VPN ಹೋಸ್ಟ್‌ನತ್ತ ತೋರಿಸುವ ರಿಟರ್ನ್ ರೂಟ್ ಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ ಉತ್ತರಗಳು ಎಂದೂ ಹಿಂತಿರುಗುವುದಿಲ್ಲ. ಮತ್ತು ಟನೆಲ್ ಹೋಸ್ಟ್‌ನ ಫೈರ್‌ವಾಲ್ ಟನೆಲ್ ಇಂಟರ್‌ಫೇಸ್ ಮತ್ತು LAN ನಡುವೆ ಫಾರ್ವರ್ಡ್ ಮಾಡಬೇಕು, ಮತ್ತು ಹೋಸ್ಟ್‌ನಿಂದಲೇ ಮಾಡಿದ ಪರೀಕ್ಷೆ ಯಶಸ್ವಿಯಾದಾಗ ಇದು ಹೆಚ್ಚಾಗಿ ಮರೆತುಹೋಗುವ ಹಂತ.
ನಿರ್ವಾಹಕರು ಸೇವೆ ಸೇರಿಸಲಾಗದಿದ್ದರೆ, ಪರ್ಯಾಯ ಬ್ರಿಡ್ಜ್‌ಗೆ ಸೇರಬಲ್ಲ ಸಾಧನ, ಅಂದರೆ ಫೋನ್ ಪರವಾಗಿ ಕೆಲಸ ಮಾಡುವ ಲ್ಯಾಪ್‌ಟಾಪ್ ಅಥವಾ ರೂಟರ್. ಇದು ತನ್ನದೇ ನಿರ್ವಹಣಾ ವೆಚ್ಚವಿರುವ ತಾತ್ಕಾಲಿಕ ಉಪಾಯ, Android ಕಾನ್ಫಿಗ್ ಅಲ್ಲ.
ಟನೆಲ್‌ನಿಂದಲ್ಲ, ಅಪ್ಲಿಕೇಶನ್‌ನಿಂದ ನಿರ್ಧರಿಸಿ
ಫೋನ್ ನಿಜವಾಗಿ ಯಾವುದನ್ನು ತಲುಪಬೇಕು ಎಂದು ಕೇಳಿ, ನಂತರ ಅದನ್ನು ನಕ್ಷೆ ಮಾಡಿ. ಹೆಸರು ಅಥವಾ ವಿಳಾಸದಿಂದ ತಲುಪುವ ಫೈಲ್ ಹಂಚಿಕೆ ಅಥವಾ ಇಂಟ್ರಾನೆಟ್ ಸೈಟ್ IP ಅಗತ್ಯವಾಗಿದೆ, ಮತ್ತು DNS ಹೆಸರನ್ನು ಬಿಡಿಸಿ ರೂಟ್ ಇದ್ದಾಗ ರೂಟ್ ಆದ ಟನೆಲ್ ಅದನ್ನು ಪೂರೈಸುತ್ತದೆ. ಸ್ಥಳೀಯ ಬ್ರಾಡ್‌ಕಾಸ್ಟ್ ಡೊಮೇನ್ ಅನ್ನು ಬ್ರೌಸ್ ಮಾಡುವ ಶೋಧ ಸಾಧನ IP ಅಗತ್ಯವಲ್ಲ, ಮತ್ತು ಎಷ್ಟೇ ರೂಟಿಂಗ್ ಅದನ್ನು ತುಂಬಲಾರದು.
| Requirement | Tunnel that satisfies it |
|---|---|
| File server or intranet by hostname | Routed TUN, with working DNS |
| Broadcast or ARP-based discovery | Ethernet bridging, so not an ordinary Android client |
| Multicast delivery | Bridging or an explicit multicast relay |
| One application to one address | Routed TUN, narrowest possible route |
ಆ ಕೋಷ್ಟಕವೇ ಕಳುಹಿಸಬೇಕಾದ ವಿನಂತಿ. ಅಪ್ಲಿಕೇಶನ್, ಅದು ಬಳಸುವ ವಿಳಾಸ ಅಥವಾ ಹೆಸರು, ಮತ್ತು ಅದು ಶೋಧವನ್ನು ಅವಲಂಬಿಸಿದೆಯೇ ಎಂದು ತಿಳಿಸಿ. ನಿರ್ವಾಹಕರು ಆ ವಿವರಣೆಯ ಮೇಲೆ ಕಾರ್ಯ ನಿರ್ವಹಿಸಬಹುದು, ಸಂಪರ್ಕವಾಗದ ಫೋನ್ ಮೇಲೆ ಯಾರೂ ಮಾಡಲಾರರು.
ಕೊನೆಯದಾಗಿ, ಪ್ರತಿ ಕ್ಲೈಂಟ್ LAN ಅಡಾಪ್ಟರ್ ಅನ್ನು ಅನುಕರಿಸುವಂತೆ ಮಾಡುವ ಬದಲು ಅಗತ್ಯವಿರುವ ಸಾಧನಗಳಿಗೆ TAP ಸೇವೆಯನ್ನು ಇಟ್ಟುಕೊಳ್ಳಿ. ಸ್ಪಷ್ಟ ಉದ್ದೇಶವಿರುವ ಎರಡು ಸೇವೆಗಳನ್ನು ಬೆಂಬಲಿಸುವುದು ಎಲ್ಲರಿಗೂ ಅರ್ಧ ಕೆಲಸ ಮಾಡುವ ಒಂದಕ್ಕಿಂತ ಸುಲಭ.