.ovpn ફાઇલમાં ખરેખર શું હોય છે, અને તે શું કરી શકતી નથી

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

ફાઇલને તમારા ક્લાયન્ટને સંબોધિત વિનંતીઓની યાદી તરીકે વાંચો, અને તેની મોટાભાગની લાઇન સ્પષ્ટ થઈ જશે.

ફાઇલ તમારા ક્લાયન્ટનું વર્ણન કરે છે, સર્વરનું નહીં

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

તેથી જ એક જ ફાઇલ બે ક્લાયન્ટ પર અલગ રીતે વર્તે છે: ફાઇલ માંગે છે, અને ક્લાયન્ટ નક્કી કરે છે કે વિનંતીનો કેટલો ભાગ તે પૂરો કરી શકે.

ટ્રાન્સપોર્ટ લાઇન પહેલેથી અસ્તિત્વમાં હોય તેવા શ્રોતા સાથે મેળ ખાવી જોઈએ

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

પોર્ટ 443 લોકપ્રિય છે કારણ કે તે એવા નેટવર્કમાંથી પસાર થાય છે જે લગભગ બીજું કંઈ મંજૂર કરતા નથી, અને તે OpenVPN સત્ર જ રહે છે, HTTPS વિનંતી નહીં. જો ઓપરેટર ઘણી remote લાઇન પ્રકાશિત કરે, તો ક્લાયન્ટ તેમને ક્રમમાં અજમાવે છે, જે લોડ-બેલેન્સિંગ નિર્ણય નહીં પણ ફેલઓવર યાદી છે. ઓપરેટરે આપેલા સંયોજનો રાખો, એક એન્ટ્રીનું હોસ્ટ બીજી એન્ટ્રીના પોર્ટ સાથે ભેળવવાને બદલે.

એમ્બેડ કરેલી કી ફાઇલ સાથે વ્યવહાર કરવાની રીત બદલે છે

પ્રમાણપત્રો અને કી <ca>, <cert> અને <key> ટૅગ વચ્ચે ઇનલાઇન હોઈ શકે છે, અથવા અલગ ફાઇલ તરીકે સંદર્ભિત થઈ શકે છે. ઇનલાઇન સામગ્રી પ્રોફાઇલને સ્વયંપૂર્ણ બનાવે છે અને તેને ગુપ્ત પણ બનાવે છે, કારણ કે ક્લાયન્ટની ખાનગી કી તેની અંદર જ મુસાફરી કરે છે. CA પ્રમાણપત્ર જાહેર વિશ્વાસ સામગ્રી છે અને શેર કરવું સલામત છે; ખાનગી કી નથી, તે અવાંચ્યા લખાણના બ્લોક જેવી દેખાય ત્યારે પણ.

કીની રક્ષા કરતો પાસફ્રેઝ એકાઉન્ટ પાસવર્ડથી અલગ ગુપ્ત છે, અને બંને ભેળવવાથી પ્રમાણીકરણ નિષ્ફળતા થાય છે જે ખોટા ઓળખપત્ર જેવી લાગે છે.

રૂટ અને DNS કદાચ ફાઇલમાંથી જ આવતા ન હોય

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

DNS એ જ પેટર્ન અનુસરે છે: ધકેલાયેલી dhcp-option DNS ક્લાયન્ટ લાગુ કરી શકે, અવગણી શકે, અથવા સ્થાનિક રિઝોલ્વર મેનેજર તેને ઓવરરાઇડ કરી શકે. પ્રોફાઇલ ફરી વાંચવાને બદલે કનેક્ટ થયા પછી રિઝોલ્વરની સ્થિતિ તપાસો.

અસમર્થિત વિકલ્પો ક્લાયન્ટ આવૃત્તિનો પ્રશ્ન છે

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

તુલના માટે મૂળ ફાઇલ રાખો, તમારી વિનંતીમાં ચોક્કસ અસમર્થિત નિર્દેશ નોંધો, અને તમે ખરેખર ચલાવો છો તે ક્લાયન્ટ માટે બનેલી પ્રોફાઇલ માંગો.

કોઈપણ બદલી પછી, એપ કઈ પ્રોફાઇલ એન્ટ્રી વાપરે છે તેની પુષ્ટિ કરો, કારણ કે નવી ફાઇલ ઇમ્પોર્ટ કરવાથી જૂની હંમેશા ઓવરરાઇટ થતી નથી.