Android હોટસ્પોટ પોર્ટ ફોરવર્ડિંગ: ત્રણ પ્રવેશબિંદુની સમજ

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

સેવા ખરેખર જ્યાં ચાલે છે ત્યાંથી શરૂ કરો

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

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

ડિબગ કરી શકાય તેવા બિલ્ડમાં adb shell /proc/net/tcp દ્વારા સોકેટની યાદી બનાવે છે, પણ મોટાભાગના લોકો માટે એપની પોતાની સ્થિતિ પ્રામાણિક સ્રોત છે.

પ્રથમ પ્રવેશબિંદુ: હોટસ્પોટ પરનું બીજું ઉપકરણ

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

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

સેવા જોડાયેલા લેપટોપ પર ચાલતી હોય, તો ફોનનું હોટસ્પોટ સરનામું જ લક્ષ્ય નથી; લેપટોપનું હોટસ્પોટ ઇન્ટરફેસ પરનું સરનામું અને ત્યાં શ્રોતા જોઈએ.

બીજું પ્રવેશબિંદુ: ઓપરેટરનો માર્ગ

મોબાઇલ નેટવર્કથી ફોન સુધી પહોંચવું બીજી સમસ્યા છે, અને IPv4 માટે મોટે ભાગે તે કામ કરતું નથી. ઓપરેટરો ઉપકરણોને વહેંચાયેલા અનુવાદ પાછળ મૂકે છે, અને તેથી જ RFC 6598 એવી ગોઠવણ માટે વહેંચાયેલ સરનામા શ્રેણી ફાળવે છે. માંગ્યા વગરના આવતા સંપર્ક પાસે પહોંચવા માટે કોઈ મેપિંગ નથી, અને કોઈ સ્થાનિક રૂપરેખાંકન એક પણ બનાવતું નથી, કારણ કે અનુવાદક તમારું ઉપકરણ નથી.

રૂટ ઍક્સેસ પણ તેને બદલતું નથી; તે ફોનના સ્ટેક પર નિયંત્રણ આપે છે, ઓપરેટરના અનુવાદક પર નહીં. જ્યાં ઓપરેટર જાહેર IPv6 ઉપસર્ગ આપે છે ત્યાં આવતો માર્ગ હોઈ શકે, પણ શ્રોતા અને ફાયરવોલને હજી સ્પષ્ટ પરવાનગી જોઈએ.

ત્રીજું પ્રવેશબિંદુ: VPN એક્ઝિટ

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

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

એક માર્ગ શરૂઆતથી અંત સુધી ચકાસો, પછી માલિકને નામ આપો

ચકાસતાં પહેલાં ટ્યુપલ લખો: ઇચ્છિત સ્રોત, લક્ષ્ય સરનામું, પરિવહન, પોર્ટ અને સાંભળતું સોકેટ ધરાવતું મશીન. કોઈ પણ ઘટક અનુમાન હોય તો ચકાસણી કંઈ ઉપયોગી કહેશે નહીં.

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

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

• શ્રોતા સામેના પક્ષે પહોંચી શકે તેવા સરનામે છે, લૂપબેક પર નહીં.
• સામેનો પક્ષ તે પ્રવેશબિંદુનું સરનામું વાપરે છે, સ્થિતિ પૃષ્ઠનું એક્ઝિટ સરનામું નહીં.
• ઓપરેટર કે પ્રદાતાની બાજુનું કોઈ પણ મેપિંગ સમર્થિત સુવિધા છે, સ્થાનિક રીતે ઉમેરેલો નિયમ નહીં.
• વિનંતી અને જવાબ એક જ નેટવર્ક સંદર્ભમાંથી પસાર થાય છે, અને પ્રમાણીકરણ હજી પાસ થાય છે.