OpenVPN પ્રોફાઇલનું સર્વર આયાત કરતાં પહેલાં કેવી રીતે ચકાસવું

કોઈ તમને પ્રોફાઇલ મોકલે છે, તમે તેને આયાત કરો છો, અને ત્રીસ સેકન્ડ પછી કોઈ ક્લાયન્ટ એવા ગંતવ્યને ડાયલ કરી રહ્યું છે જે કોઈએ ચકાસ્યું નથી. પહેલાં ફાઇલને ટેક્સ્ટ એડિટરમાં વાંચો, કારણ કે જે મહત્વનું છે તે બધું મુઠ્ઠીભર ડિરેક્ટિવમાં સમાયેલું છે: remote, proto, port, ca, cert, tls-crypt અને verify-x509-name. બાકીનું બધું ડિફોલ્ટ છે, અને આશ્ચર્ય ડિફોલ્ટમાં જ રહે છે.

ફાઇલ જે પણ એન્ડપોઇન્ટ વાપરી શકે તે બધા યાદી કરો

એન્ડપોઇન્ટથી શરૂ કરો, કારણ કે એક પ્રોફાઇલમાં ઘણા હોઈ શકે. grep -nE '^[[:space:]]*(remote|proto|port|remote-random|connection)' profile.ovpn દરેક ઉમેદવારને ફાઇલના ક્રમમાં છાપે છે, જેમાં ઇનલાઇન <connection> બ્લોકની અંદર રહેલા પણ સામેલ છે.

જ્યારે ડિરેક્ટિવ પોર્ટ છોડી દે છે, ક્લાયન્ટ સાંભળનારના ડિફોલ્ટ પર પાછો ફરે છે, તેથી એકલું remote vpn.example.com એટલે પોર્ટ 1194, ફાઇલમાં પછી કોઈ પણ proto આવે. ઘણી સાદી remote લાઇનો વિકલ્પો છે: ક્લાયન્ટ તેમને ક્રમમાં અજમાવે છે જ્યાં સુધી remote-random તેમને મિશ્ર ન કરે, અને તે કદી ચૂપચાપ બીજા ઓપરેટરનું હોસ્ટ બદલતું નથી. અસંબંધિત ડોમેન પરની બે remote લાઇનો એ જગ્યા છે જ્યાં તમે થોભીને પૂછો કે કઈ ઇચ્છિત હતી.

proto ની જોડણી પણ ધ્યાનમાં લો. tcp ક્લાયન્ટ બાજુના tcp-client માટે સમાનાર્થી તરીકે સ્વીકારવામાં આવે છે, પણ ક્લાયન્ટ પ્રોફાઇલમાં tcp-server એ રૂપરેખા ભૂલ છે જે સ્વચ્છ નિષ્ફળ થવાને બદલે અટકી જવાની પ્રવૃત્તિ ધરાવે છે.

પહેલાં નામ, પછી પોર્ટની પુષ્ટિ કરો

dig +short vpn.example.com તમને કહે છે કે નામ અસ્તિત્વમાં છે કે નહીં અને કઈ સરનામાં પાછી આપે છે, અને બહુ-સરનામું અથવા પ્રોક્સી પાછળનું એન્ડપોઇન્ટ કાયદેસર રીતે ઘણાં પાછાં આપી શકે. નામનું રિઝોલ્યુશન પૂર્વશરત છે, માલિકીનો પુરાવો નહીં; કોઈ પણ નામને સરનામે દિશા આપી શકે, અને એક સરનામું ઘણાં નામો માટે જવાબ આપી શકે.

પછી તમે શોધેલા પોર્ટ પર સાંભળનારને ચકાસો, ટ્રાન્સપોર્ટ સાથે મેળ કરીને. TCP પર openssl s_client -connect vpn.example.com:1194 -servername vpn.example.com સર્વર જે સાંકળ રજૂ કરે છે તે છાપે છે. UDP પર તમને DTLS જોઈએ: openssl s_client -dtls1_2 -connect vpn.example.com:1194 ડેટાગ્રામ પર એ જ હેન્ડશેક ચલાવે છે. પૂર્ણ થયેલો હેન્ડશેક સાબિત કરે છે કે કંઈક સાંભળી રહ્યું છે અને પ્રમાણપત્ર ધરાવે છે, જે ping બતાવે તેનાથી વધુ અને પ્રોફાઇલની પોતાની ટ્રસ્ટ સેટિંગ્સ માગે તેનાથી ઓછું છે.

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

ટ્રસ્ટ પિન સરનામાથી અલગ વાંચો

સરનામું નક્કી કરે છે ક્લાયન્ટ ક્યાં જાય; ટ્રસ્ટ બ્લોક નક્કી કરે છે પહોંચ્યા પછી તે કોનો વિશ્વાસ કરે. verify-x509-name "vpn.example.com" name વિષયનું સામાન્ય નામ પિન કરે છે, અને remote-cert-tls server સર્વર પ્રમાણીકરણ માટે વિસ્તૃત કીના ઉપયોગની માગ કરે છે. ઓપરેટર આપેલી પ્રોફાઇલમાં બંને હોવા જોઈએ.

ca, ઇનલાઇન <ca> બ્લોક, અને tls-crypt કે tls-auth માંથી કોઈ એક શોધો. tls-auth વાપરતી પ્રોફાઇલને ક્લાયન્ટ પર key-direction 1 જરૂરી છે જ્યારે સર્વર બાજુ દિશા 0 વાપરે, અને અસંગતિ હેન્ડશેકને TLS ભૂલ સાથે નિષ્ફળ કરે છે જે પ્રમાણપત્રની ખામી જેવી વંચાય છે. ઇનલાઇન CA જે તમે હમણાં જ રિઝોલ્વ કરેલા ઓપરેટરનું નથી, એટલે ફાઇલ બે સ્રોતમાંથી જોડાઈ છે, અને એ જ એ કેસ છે જેને સ્પષ્ટપણે નકારવો જોઈએ.

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

જે વિકલ્પો ચૂપચાપ નિષ્ફળ જાય તે તપાસો

OpenVPN 2.6 data-ciphers દ્વારા સાઇફરની વાટાઘાટ કરે છે, અને ફક્ત જૂની cipher AES-256-CBC લાઇન ધરાવતી પ્રોફાઇલ નિયંત્રણ ચેનલ પૂરી કરીને પછી ડેટા પર અટકી શકે છે. તે મૂલ્ય વાંચવાથી ખબર પડે કે ફાઇલ તમે જોડાઈ રહ્યા છો તે સર્વર પહેલાંની છે કે નહીં; 2.6 નું મેન પેજ વાટાઘાટનો ક્રમ યાદી કરે છે જો ઓપરેટરને ટાંકવું હોય.

ફાઇલનામ વિનાનું auth-user-pass એટલે ક્લાયન્ટ પૂછશે, તેથી સ્વયં-સંપૂર્ણ દેખાતી પ્રોફાઇલને પણ ઓળખપત્રો જોઈએ. auth-user-pass credentials.txt એટલે તે એવી ફાઇલની અપેક્ષા રાખે છે જે સંભવતઃ તમને મોકલાઈ નથી. nobind અને resolv-retry infinite સામાન્ય અને નિરુપદ્રવી છે, જ્યારે explicit-exit-notify ફક્ત UDP માટે છે અને TCP પર નકામું છે.

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

નિર્ણય કરો, પછી તમે શું નક્કી કર્યું તે નોંધો

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

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

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

જો તમે તેને આયાત કરો અને પહેલી કોશિશ નિષ્ફળ જાય, તો ક્લાયન્ટને --verb 3 સાથે ચલાવો અને પહેલી દસ લાઇન વાંચો: રિઝોલ્વ થયેલું remote સરનામું, વાટાઘાટ થયેલો proto અને TLS ભૂલ એ જ ક્રમમાં આવે છે, જે કહે છે કે ઉપરના કયા ચકાસણી તમે છોડી દીધી.