proto udp કે tcp-client: તમારો સર્વર કઈ સાંભળે છે?

ગયા મહિને કામ કરતી પ્રોફાઇલ હવે સમયસીમા પર પહોંચે છે, અને કોઈ proto udp ને proto tcp-client થી બદલવાનું સૂચવે છે। કેટલીકવાર તે સાચું પગલું હોય છે, અને કેટલીકવાર તે એવો ક્લાયન્ટ બનાવે છે જે એવા પોર્ટ સાથે જોડાય છે જ્યાં કંઈ સાંભળતું નથી, કારણ કે સર્વરને ક્યારેય બીજા પરિવહન માટે ગોઠવવામાં આવ્યું નથી। આ નિર્દેશ વર્ણવે છે કે તમારો છેડો કેવી રીતે બોલે છે; તે સામેના છેડે શ્રોતા બનાવી શકતો નથી। કોઈપણ બદલતા પહેલા પ્રોફાઇલ અને સર્વર સાથે વાંચો।

પસંદ કરેલ જોડાણ જે પરિવહન વાપરે છે તે વાંચો

એક પ્રોફાઇલમાં અનેક remote એન્ટ્રીઓ હોઈ શકે છે, અને દરેક પોતાનું પરિવહન જણાવી શકે છે। ક્લાયન્ટ તેમને ક્રમમાં પસાર કરે છે, તેથી તમે પહેલી જે લાઇન જુઓ તે જ લાગુ પડે એવું જરૂરી નથી।

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

જો ફાઇલમાં ઉપર એક proto લાઇન હોય અને નીચે અનેક remote એન્ટ્રીઓ હોય, તો એ લાઇન એવા કોઈપણ remote માટે ડિફૉલ્ટ છે જે તેને ઓવરરાઇડ કરતું નથી। ડિફૉલ્ટમાં સ્થાનિક ફેરફાર પોતાનું પરિવહન જણાવતી remote એન્ટ્રી માટે કંઈ કરતું નથી।

grep -nE '^(remote|proto)\b' client.ovpn

UDP અને TCP ઝડપનું સેટિંગ નથી

UDP ક્રમબદ્ધ સ્ટ્રીમ બનાવ્યા વિના ડેટાગ્રામ મોકલે છે, તેથી ટનલનો પોતાનો ટ્રાફિક બીજા વિશ્વસનીય પરિવહનમાં લપેટાતો નથી। TCP તમને એવા નેટવર્કમાંથી માર્ગ આપે છે જે UDP નાખી દે છે અથવા બ્લોક કરે છે, પણ તેની કિંમત નેસ્ટેડ પુનઃપ્રસારણ છે જે નુકસાનવાળી કડીને વધુ ખરાબ અનુભવાવી શકે છે।

આ પહોંચની આપલે છે, સાર્વત્રિક ક્રમ નથી। સાચી પસંદ એ છે જે ક્લાયન્ટ સામેનું નેટવર્ક પરવાનગી આપે છે। જે માર્ગ VPN પોર્ટ પર UDP નાખી દે છે તે ક્યારેય વાટાઘાટ કરશે નહીં, પ્રોફાઇલ કેટલી સારી લખાયેલી હોય તે પ્રશ્ન નથી। માર્ગ ચકાસો, પછી પરિવહન પસંદ કરો।

ફક્ત માપના આધારે તેમની વચ્ચે પસંદગી કરવી ભૂલ છે, કારણ કે જવાબ તમારા સામેનું નેટવર્ક શું પરવાનગી આપે છે તેના પર આધાર રાખે છે। હોટેલ કે કોર્પોરેટ પ્રોક્સી 443 પર ફક્ત બહાર જતું TCP પરવાનગી આપી શકે છે અને બીજું કંઈ નહીં, તેથી પ્રદાતાઓ એ વેરિઅન્ટ આપે છે। પોર્ટ નંબર પરિચિત હોવા છતાં તે એ પોર્ટ પરનું OpenVPN જોડાણ જ રહે છે, HTTPS સત્ર નહીં।

tcp-client નો ખરેખર અર્થ શું છે

ક્લાયન્ટ બાજુનો નિર્દેશ TCP જોડાણ શરૂ કરતા છેડાને નામ આપે છે। સર્વર બાજુ પોતાનું સાંભળવાનું સ્વરૂપ વાપરે છે, અને ક્લાયન્ટનો શબ્દ સર્વર રૂપરેખામાં નકલ કરવાથી એવો શ્રોતા બને છે જે કૉલ થવાની અપેક્ષા રાખે છે, સ્વીકારનાર નહીં।

મેળ ખાવાનો અર્થ એ છે કે બંને છેડા પરિવહન પર સહમત છે, એ નહીં કે તેઓ એક જ શબ્દમાળા વહેંચે છે।

grep -nE '^proto\b' /etc/openvpn/server/server.conf
ss -lntp | grep openvpn

પ્રોફાઇલ ખોટી છે એમ માનતા પહેલા સર્વરને પૂછો કે તે શું સાંભળે છે। UDP શ્રોતા TCP સોકેટ યાદીમાં દેખાતો નથી, અને ઊલટું પણ સાચું છે, તેથી સામાન્ય દૃશ્યને બદલે પ્રોટોકોલ-વિશિષ્ટ દૃશ્ય જુઓ।

જ્યારે પ્રોફાઇલ આયાત થાય છે પણ ક્યારેય જોડાતી નથી

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

માર્ગને શક્ય તેટલી સરળ રીતે ચકાસો: નિષ્ફળ જતા ક્લાયન્ટ જેવા જ નેટવર્કથી, પ્રોફાઇલ જે પરિવહનનો દાવો કરે તેની સાથે એ જ હોસ્ટ અને પોર્ટ સાથે જોડાઓ।

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

કાર્યક્ષમ પરિવહન નોંધો

એકવાર સંયોજન કામ કરે, તો તેને સર્વર, પોર્ટ અને પ્રોટોકોલ સાથે લખો, અને નોંધો કે તે કયા નેટવર્કથી ચકાસાયું હતું।

નહીં તો સમયસીમા સાથે અથડાતી આગલી વ્યક્તિ એ જ પ્રયોગ વિરુદ્ધ દિશામાં કરશે, અને કદાચ ઠીક હતા એવા સર્વરને બદલી નાખશે।

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