એક વપરાશકર્તા કનેક્ટ થઈ શકે છે અને બીજો નહીં, એક જ પોર્ટલ દ્વારા, એક જ દિવસે. બંનેની પાસે સર્વરમાં લૉક થયેલી પ્રોફાઇલ છે, બંને એક જ Access Server બિલ્ડ પર છે, અને એકમાત્ર ફરક એ છે કે તેમની પ્રોફાઇલ ક્યારે બની હતી. આ એ જ પેટર્ન છે જે ઓળખવા જેવી છે, કારણ કે "સર્વરમાં લૉક" એ કનેક્શન ક્રમ નહીં, પરંતુ નીતિ દર્શાવે છે. Access Server એ તે આર્ટિફેક્ટની બે પેઢીઓ મોકલી છે, અને TLS રિવર્સ પ્રોક્સી તેમના માત્ર એક માર્ગ સામે ઊભી છે. તમે કઈ શાખામાં છો તે ત્રણ શરતો નક્કી કરે છે.

બે પેઢીઓ, બે કનેક્શન ક્રમ

જૂની રચનામાં, જે 2.8 સુધી લાગુ છે, આયાત કરેલી ફાઇલ સ્યુડો-પ્રોફાઇલ છે. OpenVPN Connect તેનો ઉપયોગ HTTPS દ્વારા Access Server ની વેબ API સામે પ્રમાણીકરણ માટે કરે છે, કામચલાઉ વપરાશકર્તા-લૉક પ્રોફાઇલ અને સેશન ટોકન મેળવે છે, અને પછી જ VPN સ્થાપિત કરે છે. બે ટ્રાન્સપોર્ટ ક્રમિક રીતે ચાલે છે, અને પ્રથમ સામાન્ય વેબ વિનંતી છે.

2.9 સાથે દાખલ કરાયેલું ફોર્મેટ તે પ્રતિ-કનેક્શન બૂટસ્ટ્રેપ કરતું નથી. તે એક નેટિવ પ્રોફાઇલ છે જેનો ઉપયોગ સુસંગત OpenVPN ક્લાયન્ટ કરી શકે છે, ફક્ત OpenVPN Connect જ નહીં. તેને ડાઉનલોડ કરવું કે URL દ્વારા આયાત કરવું હજી પણ HTTPS સમાવી શકે છે — તે પ્રકાશનનું પગલું છે, પ્રતિ-કનેક્શન કામચલાઉ પ્રોફાઇલ મેળવવાનું નહીં.

Older server-locked (≤2.8)Newer server-locked (2.9+)
Before the tunnelWeb API call with credentialsNothing; the profile is already local
Client requirementOpenVPN ConnectAny compatible client
What a TLS web proxy can breakThe bootstrap, before any VPN attemptDownload only, not the connection
Expected HTTP log on connectA request from the clientOften nothing at all

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

તમારી શાખા પસંદ કરતી ત્રણ શરતો

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

બીજી શરત એ છે કે તમારું ફ્રન્ટએન્ડ ખરેખર શું સમાપ્ત કરે છે. સાતમા સ્તરની HTTP રિવર્સ પ્રોક્સી જે TLS ઉતારે છે તે ચોથા સ્તરના TCP ફોરવર્ડર જેવી વસ્તુ નથી, અને UDP ફોરવર્ડર પણ નથી. પોર્ટ 443 પર Access Server ની સામાન્ય ગોઠવણ OpenVPN TCP ડિમનને બ્રાઉઝર ટ્રાફિક ઓળખવા અને તેને વેબ સેવાઓને સોંપવા દે છે, તેથી સામે અસંબંધિત HTTPS ટર્મિનેટર મૂકવાથી તે ડિમનની પ્રોટોકોલ હેન્ડલિંગ જળવાતી નથી. સમાન સંખ્યા 443 વહેંચવી બે ડિઝાઇનને સમકક્ષ બનાવતી નથી.

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

જ્યારે આર્ટિફેક્ટ જૂનું હોય: બૂટસ્ટ્રેપ પહેલાં નિષ્ફળ જાય છે

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

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

TLS ચકાસણી બંધ કરીને કે પ્રમાણીકરણ નીતિ ઢીલી કરીને સરખામણી પાસ કરાવશો નહીં. તે નિદાનયોગ્ય ગોઠવણી અસંગતિને કામ કરતા પણ ચકાસાયેલા ન હોય તેવા માર્ગમાં ફેરવે છે, અને તે જ ફેરફાર કામચલાઉ પરીક્ષણને કાયમી છિદ્રમાં ફેરવે છે. Access Server ના કનેક્શન-પ્રોફાઇલ દસ્તાવેજીકરણ બંને પેઢીઓ અને કામચલાઉ-પ્રોફાઇલ પ્રવાહનું વર્ણન કરે છે, અને પ્રોક્સી દોષિત છે એમ ધારવા પહેલાં તે ચકાસવાનો સંદર્ભ છે.

જ્યારે આર્ટિફેક્ટ નવું હોય: તેના બદલે કંટ્રોલ ચેનલ વાંચો

2.9-શૈલીની પ્રોફાઇલ સાથે ક્લાયન્ટ સીધો નેટિવ VPN એન્ડપોઇન્ટ પર જાય છે. પ્રોફાઇલમાંના એન્ડપોઇન્ટ, વપરાયેલ ટ્રાન્સપોર્ટ, અને કંટ્રોલ-ચેનલ ભૂલની તપાસ કરો. જો ક્લાયન્ટ ક્યારેય HTTP વિનંતી કરતું નથી, તો તે ડિઝાઇન સાથે સુસંગત છે અને લક્ષણ નથી.

અહીં પ્રોક્સી પ્રશ્નનો આકાર પણ બદલાય છે. HTTPS અનલોડ એ ફક્ત-TCP સ્ટ્રીમ તોડી શકતું નથી જે તે ક્યારેય જોતું નથી, પણ તે પ્રોફાઇલ પ્રકાશિત કરતું ડાઉનલોડ હજી તોડી શકે છે, અને ફક્ત-TCP ફોરવર્ડર UDP બિલકુલ વહન કરશે નહીં. ફ્રન્ટએન્ડ અપ્રસ્તુત છે એમ તારણ કાઢતા પહેલાં પ્રોફાઇલ કયો ટ્રાન્સપોર્ટ માંગે છે તે તપાસો.

એક જ સ્ટ્રીમ માટે TLS પાસથ્રુ એ સાંકડી ગોઠવણ છે. તે UDP ફોરવર્ડિંગ પૂરું પાડતું નથી, અને 443 પર ડિમનની પોતાની સેવા-ફોરવર્ડિંગ વર્તણૂકનું પુનઃઉત્પાદન કરતું નથી. જો તમારું ફ્રન્ટએન્ડ તેમાંથી એક કરે છે, તો કયું તે કહો, કારણ કે ઉપાય અલગ છે.

સાંકડા રહેતા ઉપાયો

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

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

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

  • પ્રોક્સીને સ્પર્શ કરતા પહેલાં આર્ટિફેક્ટની પેઢી ઓળખો.
  • નિષ્ફળતા ટનલ પહેલાં થાય છે કે તેની અંદર તે નક્કી કરો.
  • ફ્રન્ટએન્ડ શું સમાપ્ત કરે છે તેની પુષ્ટિ કરો: HTTP, TCP સ્ટ્રીમ, અથવા UDP.
  • નીતિ અપરિવર્તિત રાખીને નવી જારી કરાયેલી પ્રોફાઇલ નેટિવ એન્ડપોઇન્ટ સામે પરીક્ષણ કરો.

સંબંધિત લેખો