Android VpnService ની મંજૂરી-સૂચિ: મંજૂર પૃષ્ઠો હજી કેમ અટકી જાય છે

તમે એક ડોમેન મંજૂરી-સૂચિમાં ઉમેર્યું, ક્વેરી તમારી એપ સુધી પહોંચે છે, મેચર મંજૂર પરત આપે છે, અને પૃષ્ઠ હજી પણ ક્યારેય લોડ થતું નથી. તે સમયે મોટાભાગના લોકો મેચર ફરીથી લખવા લાગે છે અને વાઇલ્ડકાર્ડ સરખામણી ઉમેરે છે. મારા અનુભવમાં મેચર સામાન્ય રીતે સાચું હોય છે, અને ખામી એક સ્તર નીચે બેસે છે: તમે બનાવેલા DNS જવાબમાં, તમે ઇન્સ્ટોલ કરેલા રૂટમાં, અથવા ક્વેરી ફોરવર્ડ કરવા માટે વાપરેલા સોકેટમાં. સૂચિ સહેલો ભાગ છે; પેકેટનો માર્ગ એ જગ્યા છે જ્યાં મંજૂરી-સૂચિઓ તૂટે છે.

મેચર ભાગ્યે જ દોષિત હોય છે

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

ખાલી A રેકોર્ડ પરંપરાગત ભૂલ છે. શૂન્ય જવાબો સાથે NOERROR પરત આપવું માન્ય જવાબ જેવું લાગે છે, તેથી stub રિઝોલ્વર તેને સ્વીકારે છે, બ્રાઉઝર ફરી પ્રયાસ કરે છે, AAAA અજમાવે છે, બીજું રિઝોલ્વર અજમાવે છે, અને ઘણું મોડું હાર માને છે. પ્રશ્ન વિભાગનું પુનરાવર્તન અને ટ્રાન્ઝેક્શન ID ની નકલ સાથેનો જવાબ કોડ 3, એટલે કે NXDOMAIN, વાતચીત તરત જ સમાપ્ત કરે છે. તમે જાણી જોઈને નકારો તે દરેક નામ માટે તેનો ઉપયોગ કરો.

IPv6 પણ ડિફોલ્ટને બદલે એ જ નિર્ણયને લાયક છે. જો તમે A માટે NXDOMAIN જવાબ આપો અને AAAA ને પસાર થવા દો, તો ક્લાયન્ટ IPv6 દ્વારા બ્લોક કરેલા નામ સુધી પહોંચી શકે છે અને ફિલ્ટર લીક થાય છે. કેટલાક અમલીકરણો બ્લોક કરેલી AAAA ક્વેરીનો જવાબ loopback સરનામા સાથે આપે છે જેથી કનેક્શન વૈકલ્પિક માર્ગ પર જવાને બદલે તરત નિષ્ફળ થાય. એક નીતિ પસંદ કરો, તેને બંને રેકોર્ડ પ્રકારો પર લાગુ કરો, અને બંનેનું લોગ રાખો.

જે બધું પકડે છે તે બધાનો માલિક છે

ફક્ત DNS આધારિત રચના ક્યારેય addRoute("0.0.0.0", 0) ઉમેરતી નથી, તેથી TUN ઇન્ટરફેસમાં ફક્ત ક્વેરી પ્રવેશે છે અને બાકીનું બધું અંતર્ગત નેટવર્ક વાપરતું રહે છે. એ જ સુરક્ષિત આકાર છે, અને તે એ પણ સમજાવે છે કે કેમ કેટલીક મંજૂરી-સૂચિઓ Wi-Fi પર કામ કરતી દેખાય છે અને મોબાઇલ નેટવર્ક પર નિષ્ફળ જાય છે.

જે ક્ષણે ડિફોલ્ટ રૂટ અસ્તિત્વમાં આવે, દરેક ફ્લો તમારો છે. ઇન્ટરફેસ પર આવતું અને ન તો ફોરવર્ડ થતું ન તો જવાબ મળતું TCP પેકેટ ત્યાં સુધી કતારમાં બેસે છે જ્યાં સુધી ક્લાયન્ટનો સમય પૂરો ન થાય, અને લોગ કરવા જેવી કોઈ ભૂલ નથી કારણ કે કંઈ ખોટું થયું નથી. મેં કોઈને આખી બપોર તૂટેલી મંજૂરી-સૂચિ પર ગુમાવતા જોયા છે જે વાસ્તવમાં પોર્ટ 443 માટે ખૂટતું ફોરવર્ડર હતું. તમે કાઢી નાખવાનું નક્કી કરો તે દરેક પેકેટનો પ્રોટોકોલ અને ગંતવ્યનું લોગ રાખો.

રિઝોલ્વર સોકેટે ટનલમાંથી બહાર નીકળવું પડે

ફોરવર્ડિંગ એ જગ્યા છે જ્યાં આગળનું જાળ બેસે છે. કેરિયર રિઝોલ્વર ઘણી વાર એવા ખાનગી સરનામે રહે છે જ્યાં ટનલ પહોંચી શકતી નથી, તેથી તમે ફોરવર્ડ કરેલી ક્વેરી ક્યાંય જતી નથી અને એપ વાંચન સમયસમાપ્તિ જણાવે છે. મંજૂર ક્વેરી એવા રિઝોલ્વરને મોકલો જે પહોંચવા યોગ્ય છે તેમ તમે જાણો છો, અને પહેલાં તે સોકેટ VpnService.protect() ને આપો. અસુરક્ષિત સોકેટ ક્વેરીને તમારી પોતાની ટનલમાં પાછી મોકલે છે, જ્યાં તે ફરી એપ સુધી પહોંચે છે અને સમયસમાપ્તિ ન થાય ત્યાં સુધી ફરે છે.

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

કદ અને ચેકસમ વિના સંદેશે નિષ્ફળ જાય છે

શાંત ડ્રોપ કદને કારણે પણ આવે છે. મોટા જવાબ સમૂહવાળો DNS જવાબ, અથવા ઉદાર વિકલ્પો સાથેનો TCP હેન્ડશેક, તમે ક્યારેય સ્પષ્ટ રીતે સેટ ન કરેલા પાથ MTU ને વટાવી શકે છે; ફ્રેગમેન્ટ ઉપરના પ્રવાહમાં અદૃશ્ય થાય છે અને ક્લાયન્ટ કાં તો નાના કદમાં ફરી પ્રયાસ કરે છે કાં તો પ્રયાસ બંધ કરે છે. ઇન્ટરફેસ MTU 1280 પર સેટ કરવું એ રૂઢિચુસ્ત પસંદગી છે જે મોટાભાગના મોબાઇલ માર્ગો પર ટકે છે, અને કોઈએ માપ્યું ન હોય તેવા ડિફોલ્ટને વારસામાં લેવા કરતાં સ્પષ્ટ રહેવું સારું છે.

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

VpnService તમારા વતી શું કરશે નહીં

તેમની આસપાસ રચના કરતા પહેલાં બે મર્યાદા જાણવા લાયક છે. કોઈ સામાન્ય એપ Wi-Fi ની બહાર સિસ્ટમ-વ્યાપી પ્રોક્સી અથવા PAC ફાઇલ ઇન્સ્ટોલ કરી શકતી નથી, અને તે ભાગ બદલાયો નથી. પ્રતિ-એપ માર્ગ બદલાયો છે: API 29 પહેલાં VpnService.Builder પ્રોક્સી બિલકુલ વહન કરી શકતું ન હતું, અને API 29 થી setHttpProxy(ProxyInfo.buildPacProxy(uri)) પ્લેટફોર્મને VPN નેટવર્ક માટે મૂલ્યાંકન કરવા PAC સ્ક્રિપ્ટ આપે છે. જ્યારે તમે જૂની API ને લક્ષ્ય બનાવો અથવા PAC મોડેલ નિયમ વ્યક્ત કરી ન શકે ત્યારે નિયમો તમારા પોતાના કોડમાં મૂલ્યાંકન કરો. UDP પણ મફત નથી: બ્રાઉઝર SOCKS પ્રોક્સી દ્વારા ફક્ત TCP મોકલે છે, અને મોટાભાગના SOCKS5 ક્લાયન્ટ ક્યારેય UDP ASSOCIATE અમલમાં મૂકતા નથી, તેથી પ્રોક્સી આધારિત રચના TCP સ્વસ્થ દેખાય ત્યારે UDP કાઢી નાખે છે અથવા લીક કરે છે.

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

આ ક્રમમાં તપાસો

સૂચિ ક્રમમાં કરો અને નિષ્ફળ થતા પહેલા તબક્કે અટકો, કારણ કે અગાઉનું ટકે નહીં ત્યાં સુધી દરેક પછીની તપાસ ફક્ત ઘોંઘાટ છે.

1. ઇન્સ્ટોલ કરેલા રૂટની સૂચિ બનાવો અને ખાતરી કરો કે DNS સિવાયના પેકેટ બિલકુલ TUN ઇન્ટરફેસમાં પ્રવેશે છે કે નહીં.
2. એક બ્લોક કરેલા અને એક મંજૂર નામ માટે ક્વેરી નામ, નિર્ણય અને જવાબ કોડનું લોગ રાખો.
3. ખાતરી કરો કે રિઝોલ્વર સોકેટ સુરક્ષિત છે અને પસંદ કરેલો રિઝોલ્વર ટનલની અંદરથી જવાબ આપે છે.
4. ઇન્ટરફેસ MTU અને જાતે બનાવેલા એક જવાબના ચેકસમની ખાતરી કરો.
5. Wi-Fi અને મોબાઇલ નેટવર્ક પર એ જ પૃષ્ઠનું પુનરાવર્તન કરો, કારણ કે કેરિયર રિઝોલ્વર અને પાથ MTU અલગ હોય છે.

જો પાંચેય ટકે અને પૃષ્ઠ હજી અટકેલું રહે, તો આગળનો શંકાસ્પદ ફોરવર્ડર પોતે છે: પકડેલી વિનંતીની પકડેલા જવાબ સાથે સરખામણી કરો અને ખૂટતી બાઇટ ગણતરી કે અડધું બંધ સોકેટ શોધો. VpnService.Builder સંદર્ભ રૂટ, DNS અને MTU કરારો આવરી લે છે, અને protect() એ builder વિકલ્પ નહીં પણ અલગ VpnService કૉલ છે; જોડાયેલું ઇન્ટરફેસ ફક્ત એટલું જ કહે છે કે પહેલો કરાર પૂરો થયો છે.