iPhone VPN MTU: નંબર બદલતા પહેલા માલિક નક્કી કરો
ત્રણ પ્રશ્નો નક્કી કરે છે કે એપ, ગેટવે પ્રોફાઇલ કે ફોનમાં કોઈ પણ આકાર બદલી શકે છે કે નહીં. Mac માંથી નંબર ઉછીના લેતા પહેલા તેમના જવાબ આપો.
iPhone VPN પેકેટ આકાર વિશેની દરેક ચર્ચા આખરે ppp0 નામના ઇન્ટરફેસ સામે એ જ Mac આદેશ સૂચવે છે, સામાન્ય રીતે સાથે એક નંબર હોય છે. તે લાગુ પડતો નથી, અને જો એ ઇન્ટરફેસ સંબંધિત કનેક્શનનું ન હોય તો Mac પર પણ તે યોગ્ય નિયંત્રણ ન હોત. ફોનમાં નંબરનો માલિક તે છે જે ટનલ લાગુ કરે છે: સ્થાનિક પ્રોફાઇલ માટે ઓપરેટિંગ સિસ્ટમ, એપ માટે પેકેટ-ટનલ પ્રદાતા, અથવા દસ્તાવેજીકૃત એટ્રિબ્યુટ વાટાઘાટ થાય ત્યારે ગેટવે. આ ત્રણમાંથી કયા કેસ સાથે તમારો સંબંધ છે તે ત્રણ પ્રશ્નો નક્કી કરે છે.
પ્રશ્ન એક: કયો ક્લાયન્ટ ચાલી રહ્યો છે
સ્થાનિક IKEv2 પ્રોફાઇલ, બિલ્ટ-ઇન Cisco IPsec પ્રોફાઇલ અને તૃતીય-પક્ષ Cisco ક્લાયન્ટ એ ત્રણ અલગ અમલીકરણો છે, જેમની પાસે સમર્થિત એટ્રિબ્યુટના ત્રણ અલગ સમૂહો છે. સેટિંગ્સમાંનો પ્રોફાઇલ પ્રકાર કહે છે કે ફોને ખરેખર કયો શરૂ કર્યો, અને એપ યાદી કહે છે કે માર્ગમાં પ્રદાતા છે કે નહીં. ત્યાંથી શરૂ કરો, કારણ કે બાકીનો નિર્ણય તેમાંથી જ નીકળે છે. જો એપ યાદીમાં કોઈ પ્રદાતા ન દેખાય, તો ટનલ ઓપરેટિંગ સિસ્ટમની છે.
ગેટવે વેન્ડર પરથી અમલીકરણ અનુમાન ન કરો. Cisco હેડએન્ડ એવા ક્લાયન્ટની કનેક્શન સમાપ્ત કરી શકે છે જે વેન્ડરના નામ સિવાય કંઈ જ સહિયારું ધરાવતા નથી. જૂની રિલીઝ પર જૂના બિલ્ડનો સ્ક્રીનશોટ કહે છે કે એ જોડીએ શું સમર્થન આપ્યું, એ નહીં કે તમારા હાથમાંનો ફોન શું કરે છે.
પ્રશ્ન બે: મૂલ્યનો માલિક કોણ છે
Apple નેટવર્ક એક્સ્ટેન્શન સેટિંગ્સ ઑબ્જેક્ટ દ્વારા પેકેટ-ટનલ ડેવલપર્સને MTU પ્રોપર્ટી આપે છે. આ તે પ્રદાતા માટે API છે જે પોતાની ટનલ ગોઠવે છે, એવો સ્વિચ નહીં જે વપરાશકર્તા કે એડમિનિસ્ટ્રેટર બીજાના ઇન્સ્ટોલ કરેલા ક્લાયન્ટ પર ચાલુ કરી શકે. તૃતીય-પક્ષ એપ તેને દર્શાવવા, અવગણવા કે મૂલ્ય હાર્ડ-કોડ કરવાનું પસંદ કરી શકે છે.
સ્થાનિક પ્રોફાઇલ માટે ઇન્ટરફેસનો આકાર ઓપરેટિંગ સિસ્ટમ પસંદ કરે છે, અને ફોન તેના માટે કોઈ એડિટર આપતું નથી. Cisco રિમોટ-એક્સેસ ગેટવે માટે કનેક્શન પ્રોફાઇલનું દસ્તાવેજીકૃત એટ્રિબ્યુટ છે, અને તે લાગુ પડે છે કે નહીં તે ક્લાયન્ટ, રિલીઝ અને વાટાઘાટ થયેલા ટ્રાન્સપોર્ટ પર આધાર રાખે છે. દસ્તાવેજીકૃત અને પાળવામાં આવેલા વચ્ચેની એ જ ખાલી જગ્યામાં નકલ કરેલો નંબર ખોટો જાય છે.
| Owner | Who can change it | Reachable from the phone |
|---|---|---|
| Packet-tunnel provider | The app vendor through its API | Only if the app exposes a setting |
| Native IKEv2 or Cisco IPsec profile | The operating system | No user control |
| Gateway group policy attribute | The gateway administrator | If the client honours it |
પ્રશ્ન ત્રણ: લક્ષણ આકાર પર આધાર રાખે છે ખરું
આકારની સમસ્યાઓની એક સહી હોય છે: નાની વિનંતીઓ સફળ થાય છે, મોટા અપલોડ કે મોટા પ્રતિભાવ અટકી જાય છે, અને એ જ સેવા બીજા એક્સેસ નેટવર્ક પર કામ કરે છે. ફિલ્ટરિંગ, એપની પેલોડ મર્યાદા અને અટકેલું સર્વર સમાન ફરિયાદ ઊભી કરી શકે છે, તેથી જે એક કામગીરી નિષ્ફળ જાય તેને કામ કરતી કામગીરીની બાજુમાં નોંધો. એપ સમય અને આકાર જણાવે તો બંને તેમના સાથે લખો. એ જોડી વિના પછીનો દરેક ફેરફાર અનુમાન છે.
એ જ પરીક્ષણ Wi-Fi અને મોબાઇલ નેટવર્ક પર ચલાવો. નેટવર્કને અનુસરતી નિષ્ફળતા માર્ગ તરફ ઇશારો કરે છે; ઉપકરણને અનુસરતી નિષ્ફળતા ક્લાયન્ટ કે પ્રોફાઇલ તરફ, અને બંનેને અલગ માલિકની જરૂર છે. બંને રન માટે એ જ સેવા અને એ જ ખાતું વાપરો, નહીં તો સરખામણી કંઈ કહેતી નથી.
Mac ની રેસીપી વારંવાર કેમ આવે છે
PPP આધારિત ડેસ્કટોપ VPN ના વર્ષોએ ઇન્ટરફેસ આકાર બદલવાને કાયદેસર સ્થાનિક ઉપાય બનાવ્યો, અને એ સૂચનાઓ મોબાઇલ ચર્ચાઓમાં નકલ થઈ ગઈ. ફોનમાં ન શેલ છે, ન એવું ઇન્ટરફેસ નામ, ન ફરી જોડાણ પછી ટકાઉપણું. 2011 માં ડેસ્કટોપ સમસ્યા હલ કરનારી રેસીપી તેને સાચી બનાવતી પરિસ્થિતિઓ કરતાં ઘણી દૂર ગઈ. ચર્ચા ગમે તે દાવો કરે, મોબાઇલ ક્લાયન્ટ આ માટે કોઈ શેલ આદેશ સ્વીકારતા નથી.
નકલ કરેલા મૂલ્યને સેટિંગ નહીં, પરંતુ માર્ગ વિશેની પરિકલ્પના તરીકે લો. જો નાનો આકાર ટ્રાન્સફર કામ કરે અને મોટો વિશ્વસનીય રીતે નિષ્ફળ જાય, તો માર્ગ વિશે તમારી પાસે પુરાવા છે; તેના પર કાર્ય કરવાની પરવાનગી ધરાવતો ઘટક હજી શોધવો પડશે. એ શોધ સામાન્ય રીતે ગેટવે પ્રોફાઇલ કે એપ વેન્ડર પાસે પૂરી થાય છે, અને ભાગ્યે જ ફોન પાસે.
ટ્રાન્સપોર્ટ જવાબ બદલે છે
જો સેશન IPsec ને બદલે TLS પર ચાલતું હોય, તો ગેટવે પર TCP સેગ્મેન્ટેશન ગોઠવણ મદદ કરી શકે, કારણ કે તે TCP પ્રવાહો માટે જાહેર કરેલ સેગ્મેન્ટ આકાર ફરી લખે છે. UDP ટ્રાફિક માટે તે કંઈ કરતું નથી, અને તેમાં લોકો ધારે તેના કરતાં આધુનિક વેબનો વધુ ભાગ આવે છે. ફેરફાર સૂચવતા પહેલા વાટાઘાટ થયેલ ટ્રાન્સપોર્ટ તપાસો, અને ટિકિટમાં લખો કે કયા ટ્રાન્સપોર્ટ પર અસર થવાની અપેક્ષા છે.
પાથ MTU શોધ એટલા માટે છે કે છેડા અનુમાનને બદલે ખરી મર્યાદા જાણી શકે. પ્રતિસાદ અવરોધવો અને નાનો આકાર હાર્ડ-કોડ કરવો એ કામ કરતા મોટા ટ્રાન્સફરને દરેક કનેક્શન પર કાયમી, છુપાયેલા ખર્ચ સાથે બદલે છે.
ગેટવે ટીમને શું પૂછવું
ત્રણ વસ્તુઓ માંગો: એટ્રિબ્યુટનું ચોક્કસ નામ અને તેનો વ્યાપ, તૈનાત ક્લાયન્ટ તેને પાળે છે કે નહીં, અને સેશને કયા ટ્રાન્સપોર્ટ પર વાટાઘાટ કરી. એક ગ્રુપ પોલિસી પર લાગુ ફેરફાર ચકાસી શકાય છે; વૈશ્વિક સંપાદન નહીં, અને તે જોખમ એવા વપરાશકર્તાઓ પર ખસેડે છે જેમણે કદી સમસ્યા જણાવી નથી. દસ્તાવેજનો સંદર્ભ પણ માંગો, કારણ કે એટ્રિબ્યુટના નામ રિલીઝ વચ્ચે બદલાય છે.
પછી એક વસ્તુ બદલો અને મૂળ નિષ્ફળ કામગીરી ફરી ચકાસો, સ્પીડ-ટેસ્ટ ડાઉનલોડ નહીં. ક્લાયન્ટ આવૃત્તિ અને એક્સેસ નેટવર્ક સાથે પહેલાં-પછીનો રેકોર્ડ રાખો, જેથી આગળનો અહેવાલ ફરી ચર્ચાવાને બદલે સરખાવી શકાય.
જો કામગીરી મૂળ આકારે હજી નિષ્ફળ જાય, તો આકાર કારણ ન હતો. એ નિષ્કર્ષ પણ નોંધો, જેથી આગલી વ્યક્તિ એ જ પરિકલ્પના ફરી ન ખોલે.