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 સેવા રાખો. સ્પષ્ટ હેતુ ધરાવતી બે સેવાઓનો ટેકો આપવો બધા માટે અડધું કામ કરતી એક કરતાં સરળ છે.