આ માન્યતા એટલી સામાન્ય છે કે તેને હકીકત તરીકે ગણવામાં આવે છે: Android ફક્ત એક જ VPN ની મંજૂરી આપે છે, તેથી ફોન પર ચાલતું SSH સર્વર તે ટનલ દ્વારા કામ કરી શકતું નથી. પહેલો ભાગ સાચો છે અને તારણ તેમાંથી નીકળતું નથી. પ્લેટફોર્મની મર્યાદા એ વિશે છે કે કેટલી એપ્લિકેશનો VPN સેવાનું સ્લોટ ધરાવી શકે, એ વિશે નહીં કે કેટલા સોકેટ હોઈ શકે અથવા કોને ફોન સાથે જોડાવાની મંજૂરી છે. સાંભળતા સોકેટ સાથેનું SSH ડીમન સામાન્ય પોર્ટ સાથેની સામાન્ય એપ્લિકેશન છે, અને ટનલ એ તેના ટ્રાફિક જઈ શકે તેવા માર્ગોમાંનો એક છે.

એક-VPN નિયમ ખરેખર શું મર્યાદિત કરે છે

VpnService એ એક-સ્લોટ સંસાધન છે. જ્યારે કોઈ એપ્લિકેશન ટનલ સ્થાપિત કરે છે ત્યારે તે ઉપકરણનું VPN બની જાય છે, અને બીજી એપ્લિકેશન જે ટનલ સ્થાપિત કરવાનો પ્રયાસ કરે છે તેને પ્રથમ જાય ત્યાં સુધી નકારવામાં આવે છે. તે ટનલની માલિકી વિશેનો નિયમ છે, અને તે સમજાવે છે કે બે VPN ક્લાયંટ એકસાથે કેમ ચાલી શકતા નથી.

તે સાંભળતા સોકેટ વિશે કંઈ કહેતું નથી. SSH સર્વર VpnService ને કૉલ કરતું નથી, પેકેટને રોકતું નથી અને તે સ્લોટ માટે સ્પર્ધા કરતું નથી. તે પોર્ટ બાંધે છે અને કનેક્શન સ્વીકારે છે, જે VPN સ્થાપિત ન હોય ત્યારે પણ તે જ કરતું. તેથી દંતકથા ટનલ પ્રદાતાઓની મર્યાદાને નેટવર્ક કનેક્શનની મર્યાદા સાથે ભેળવી દે છે, અને બંને વચ્ચે કોઈ સંબંધ નથી.

લિસનર એ લક્ષ્ય છે, ટનલનો ભાગ નહીં

ટનલ અસ્તિત્વમાં આવે પછી ફોન પાસે તેના પર એક સરનામું હોય છે અને પીઅર ઉપકરણ પાસે તે સરનામા સુધીનો માર્ગ હોય છે. કંઈ જવાબ આપે છે કે નહીં તે લિસનર નક્કી કરે છે. loopback સાથે બંધાયેલું ડીમન ફક્ત ફોનમાંથી જ પહોંચી શકાય છે; જૂના ટનલ સરનામા સાથે બંધાયેલું ડીમન ફરી જોડાયા પછી તેનું બંધન જાળવી શકે છે જ્યારે તે જે સરનામા સાથે બંધાયું હતું તે બદલાઈ ગયું હોય.

બંધનના નિયમો સામાન્ય SSH રૂપરેખાંકન છે: સાંભળવાનું સરનામું અને પોર્ટ, અને કોણ પ્રમાણીકરણ કરી શકે. Android પર તે સેટિંગ્સ એપ્લિકેશનના પોતાના રૂપરેખાંકનમાં રહે છે, અને એપ્લિકેશનની પ્રક્રિયાના માલિકને વિશેષાધિકાર પોર્ટ વાપરવાની મંજૂરી ન પણ હોય, તેથી રૂટ તરીકે પોર્ટ 22 બાંધવાની ડેસ્કટોપની ટેવ યથાવત્ સ્થાનાંતરિત થતી નથી.

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

પછી માર્ગ પર જ પરવાનગી છે. બહાર જતા વેબ ટ્રાફિકને આનંદથી વહન કરતું ગ્રાહક VPN તેના ક્લાયંટ માટે અંદર આવતા કનેક્શનને જરાય મંજૂરી આપવાની જરૂર નથી; ઘણાં આપતાં નથી, કારણ કે તે એક ગ્રાહકને બીજા સામે ખુલ્લો મૂકશે. જો પીઅર ક્યાંયથી પણ ફોનના ટનલ સરનામા સુધી પહોંચી ન શકે, તો સમસ્યા સેવાની નીતિમાં છે, ફોનમાં નહીં.

રિપ્લાય પાથ એ છે જ્યાં સામાન્ય રીતે તૂટે છે

ધારો કે પીઅર ફોનના ટનલ સરનામા સુધી પહોંચે છે અને SYN આવે છે. હવે જવાબ તે જ માર્ગે જવો પડે છે, અને તે ફોનની અંદરનો રૂટિંગ નિર્ણય છે. જો જવાબ Wi-Fi દ્વારા જાય કારણ કે તે ડિફૉલ્ટ નેટવર્ક છે, તો પીઅરને એવું કનેક્શન દેખાય છે જે ક્યારેય પૂરું થતું નથી, જે ફાયરવૉલ જેવું બરાબર દેખાય છે.

Android આને ડેસ્કટોપ કરતાં વધુ જટિલ બનાવે છે કારણ કે ડિફૉલ્ટ નેટવર્ક પ્રક્રિયા દીઠ પસંદ થાય છે અને VPN એપ્લિકેશનની નીતિ તેને બદલી શકે છે. VPN ક્લાયંટ ફક્ત મંજૂર એપ્લિકેશનોની યાદીને રૂટ કરી શકે છે, તેથી તે યાદીની બહારની સર્વર એપ્લિકેશન તેના જવાબો માટે ભૌતિક નેટવર્ક વાપરતી રહે છે જ્યારે પીઅર તેમને ટનલ દ્વારા અપેક્ષા રાખે છે.

એપ્લિકેશન તેના પોતાના સોકેટને ચોક્કસ નેટવર્ક સાથે પણ બાંધી શકે છે, જે ડિફૉલ્ટને બદલી નાખે છે. જ્યારે તમે એવો રિપોર્ટ વાંચો કે સેવા એક સરનામાથી પહોંચી શકાય છે અને બીજાથી નહીં, ત્યારે સામાન્ય રીતે આ જ તેની પાછળની ક્રિયાવિધિ હોય છે.

VPN ટાળવાથી અંદર આવતી સેવા સુધરતી નથી

લોકપ્રિય ઉપાય, SSH એપ્લિકેશનને VPNમાંથી બહાર રાખવી જેથી તેનો ટ્રાફિક ફરી વાળવાનું બંધ થાય, વિરુદ્ધ સમસ્યાનો ઉકેલ છે. તે ત્યારે મદદ કરે છે જ્યારે બહાર જતા SSH ક્લાયંટનું પરિવહન ટનલને કારણે વારંવાર તૂટે છે. હોસ્ટ કરેલા સર્વર માટે તે જવાબોને પીઅર જે ટનલ વાપરે છે તેમાંથી બહાર ખસેડી શકે છે, જે આંશિક નિષ્ફળતાને સંપૂર્ણ નિષ્ફળતામાં ફેરવે છે.

રાઉટર પર જાહેર પોર્ટ ખોલવા વિશે પણ એ જ લાગુ પડે છે. જો જરૂરિયાત એ હોય કે એક અધિકૃત ઉપકરણ VPN દ્વારા ફોન સુધી પહોંચે, તો SSH ને ઇન્ટરનેટ પર ખુલ્લું મૂકવું એ અલગ જોખમ-મૉડેલ છે અને સમારકામ નથી.

પહેલા સેવાનું સરનામું નક્કી કરો: ફોનનું LAN સરનામું, તેનું ટનલ સરનામું, અથવા જાણી જોઈને ફોરવર્ડ કરેલો એન્ડપૉઇન્ટ. દરેકનો પોતાનો પહોંચ અને જોખમનો કરાર છે, અને તેમને ભેળવવાથી જ નાની ઍક્સેસ સમસ્યા કાયમી છિદ્ર બની જાય છે.

એક સમયે એક દિશાનું નિદાન કરો

રૂપરેખાંકન બદલતા પહેલા ચાર હકીકતો લખો: પીઅર જે સરનામા સાથે જોડાય છે તે, ફોન પર લિસનરની સ્થિતિ, તેને ધરાવતું એપ્લિકેશન અને વપરાશકર્તા સંદર્ભ, અને દરેક દિશામાં જોવા મળેલો માર્ગ. જે રિપોર્ટ કહે છે કે VPN SSH ને ડિસ્કનેક્ટ કરે છે તેમાં આમાંથી એક પણ નથી હોતું અને તે ક્લાયંટ પરિવહન સમસ્યાને પહોંચી ન શકાય તેવા સર્વરથી અલગ નથી કરી શકતું.

adb shell ip -br addr
adb shell ip route get 10.90.0.9
nc -vz 10.90.0.4 2222

પોર્ટ તપાસ પીઅર પરથી ચલાવો, ફોન પરથી નહીં, અને SSH ક્લાયંટનું વિગતવાર આઉટપુટ વાંચો કે તે TCP હેન્ડશેક પહેલા કે પછી નિષ્ફળ જાય છે. જે સોકેટ ક્યારેય જોડાતું નથી અને નકારવામાં આવેલું લૉગિન એ ભિન્ન તબક્કા છે, જેમના જવાબદાર ભિન્ન છે.

ડિબગ કરતી વખતે હોસ્ટ-કી ચકાસણી અને ખાતાના નિયંત્રણો અકબંધ રાખો. લિસનર અને મંજૂર વપરાશકર્તાઓને મર્યાદિત કરવું એ જ પહોંચી શકાય તેવા સર્વરને સ્વીકાર્ય બનાવે છે; કનેક્શન કામ કરે તે માટે તેમને ઢીલા કરવાથી એક સમસ્યા વધુ ખરાબ સાથે બદલાય છે. જો તમારું Android અમલીકરણ એ જ રૂપરેખાંકન નામો અનુસરે તો OpenSSH સર્વર સંદર્ભ સાંભળવા અને ઍક્સેસ નિયંત્રણોને આવરી લે છે.

સંબંધિત લેખો