iPhone Always On VPN: બે ટનલ એક વર્ચ્યુઅલ IP શેર કરી શકે છે

મેનેજ કરેલા Always On પ્રોફાઇલ સાથેના દેખરેખ હેઠળના iPhone પર, ફોન દરેક સક્રિય IP ઇન્ટરફેસ માટે ટનલ રાખે છે, તેથી સેલ્યુલર અને Wi-Fi બંનેને પોતાની ટનલ મળે છે. પછી સર્વર એક ઉપકરણ માટે બે IKE સુરક્ષા સંગઠનોની યાદી બતાવે છે, ઘણી વાર એક વર્ચ્યુઅલ સરનામું શેર કરતા, અને પહેલી વૃત્તિ તેને rekey લૂપ કહેવાની અને ટાઇમર બદલવાનું શરૂ કરવાની હોય છે. એ વૃત્તિ સામાન્ય રીતે ખોટી હોય છે. નીચેનાં પગલાં એ ક્રમમાં કરો કે જે ક્રમમાં પુરાવા સર્વર પર દેખાય છે, અને સર્વર તમને કહે નહીં ત્યાં સુધી ફોનની સેટિંગ્સને અડ્યા વિના રાખો કે તમારો કયો કેસ છે.

સર્વર પાસે પહેલેથી હોય તેવી બે પંક્તિઓથી શરૂ કરો

સંગઠનોને swanctl --list-sas વડે યાદી કરો અને બંને એન્ટ્રીમાં ચાર ક્ષેત્રો વાંચો: દૂરનું સરનામું, પ્રમાણિત ઓળખ, ફાળવેલ વર્ચ્યુઅલ IP અને બનાવટનો સમય. એક ઓળખ અને એક વર્ચ્યુઅલ IP સાથે બે અલગ બાહ્ય સરનામાં એ જ આકાર છે જેણે આ પ્રશ્ન શરૂ કર્યો, અને કોઈપણ ફેરફાર પહેલાં તેને લખી લેવો યોગ્ય છે. પછી દરેક સાથે જોડાયેલા બાળ સંગઠનો તપાસો, કારણ કે ટ્રાફિક સિલેક્ટર નક્કી કરે છે કે લક્ષ્યની શોધ ક્યારેય બે ટનલને અલગ પાડી શકે કે નહીં. સેકન્ડોમાં દેખાઈને અદૃશ્ય થતી જોડી કલાકો સુધી જીવતી જોડી કરતાં બીજું પ્રાણી છે.

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

તમે કયું ઓવરલેપ જોઈ રહ્યા છો તે નક્કી કરો

IKEv2 rekey અને make-before-break પુનઃપ્રમાણીકરણ જાણી જોઈને ટૂંકું ઓવરલેપ બનાવે છે, જૂનું ડિલીટ કરતાં પહેલાં નવું સંગઠન સ્થાપિત કરીને. સમયચિહ્નો કેસ નક્કી કરે છે, કારણ કે નવું દેખાયાના એક-બે સેકન્ડ પછી અદૃશ્ય થતું જૂનું SA એ નવીકરણ છે જે પોતાનું કામ કરી રહ્યું છે. સ્વતંત્ર ઇન્ટરફેસ ટનલ ક્યારેય એવી દેખાતી નથી, કારણ કે દરેક તેના ઇન્ટરફેસ ચાલુ રહે ત્યાં સુધી ટકે છે, અને એકને ડિલીટ કરવું બીજાને બનાવવાથી આવતું નથી.

Apple નું મેનેજ કરેલું Always On વર્તન ઇન્ટરફેસ દીઠ છે, તેથી દેખરેખ હેઠળનું ઉપકરણ હાથે ગોઠવેલા પ્રોફાઇલ કરતાં કાયદેસર રીતે વધુ વ્યસ્ત દેખાઈ શકે છે. પ્રદાતા એપનું ઓટો-કનેક્ટ ટૉગલ એ જ બાબત સૂચવતું નથી, અને સામાન્ય on-demand નિયમ પણ નહીં. Apple નું ડિપ્લોયમેન્ટ ઝાંખી ઇન્ટરફેસ દીઠ મોડેલ વર્ણવે છે; લૂપ ધારવા પહેલાં તમારી બે પંક્તિઓની તેની સાથે તુલના કરો. બંને આકાર સર્વરના એક જ પૂલમાંથી લે છે, તેથી ઓવરલેપ તમારો એકમાત્ર વહેલો સંકેત છે.

જુઓ કે એક વર્ચ્યુઅલ સરનામું બે ટનલ માટે જવાબો કેમ તોડે છે

ફોનને જવાબ આંતરિક સરનામાંને સંબોધાય છે, અને કર્નલ લક્ષ્ય અને નીતિ પ્રમાણે આઉટબાઉન્ડ ટનલ પસંદ કરે છે, ફોન વાપરેલા ઇન્ટરફેસ પ્રમાણે નહીં. સમાન વર્ચ્યુઅલ IP સાથે મેળ ખાતી નીતિઓ ધરાવતા બે સાથોસાથ સંગઠનો રાઉટિંગ નિર્ણયને એ કહેવાનો કોઈ રસ્તો વગર છોડી દે છે કે જવાબ કઈ સત્રનો છે. કેટલાક જવાબ ખોટી ટનલ લે છે, અને ફોન એક દિશામાં ચાલતું અથવા Wi-Fi આવતાં મરી જતું જોડાણ દર્શાવે છે. બે આદેશ આઉટપુટ સ્થિતિ સાબિત કરે છે: swanctl --list-sas બંને SA પર સમાન વર્ચ્યુઅલ IP દર્શાવે છે, અને ip xfrm policy બે સમાન સિલેક્ટર દર્શાવે છે.

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

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

પૂલ અથવા સમાંતરતા મોડેલ બદલો, rekey ટાઇમર નહીં

swanctl રૂપરેખામાં, વિશિષ્ટતા જોડાણ પર સ્પષ્ટ નીતિ છે: unique = replace નવું સ્થપાય ત્યારે જૂનું જોડાણ દૂર કરે છે, અને unique = keep નવા આવનારને નકારે છે. બંને મૂલ્યો જોડાણ સ્થપાય ત્યારે કામ કરે છે, તેની અંદરના બાળ SA પર નહીં.

connections {
  ios-alwayson {
    unique = replace
  }
}

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

તમે ખરેખર ડિપ્લોય કરો તે સંક્રમણોનું પરીક્ષણ કરો

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

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