એકથી વધુ OpenVPN રિમોટ: ફેલઓવર યાદી, લિંક બોન્ડિંગ નહીં
બીજું રિમોટ એ બીજો પ્રયાસ છે, બીજી લેન નહીં: ક્લાયન્ટ endpoint ની યાદી સાથે શું કરે છે અને સાચા એગ્રિગેશનને શું જોઈએ.
એક પ્રોફાઇલમાં બે રિમોટ લીટીઓ બીજી લેન જેવી લાગે છે; તે બીજો પ્રયાસ છે. પહેલું endpoint જવાબ આપવાનું બંધ કરે ત્યારે ક્લાયન્ટ આગળ વધે છે અને સેશન પહોળું થતું નથી. યાદીને શરૂઆતમાં જ ફેલઓવર કહો, નહીંતર તમે ખોટો નોબ ટ્યુન કરશો.
રિમોટ યાદી તમને શું આપે છે
પ્રોફાઇલને પ્રયાસોના ક્રમબદ્ધ સમૂહ તરીકે જુઓ, ક્ષમતાના પૂલ તરીકે નહીં. દરેક એન્ટ્રીને ટનલ ઉપાડવાનો પોતાનો વારો મળે છે અને સેશન જેણે જવાબ આપ્યો તેના પર ચાલે છે. લાંબી યાદી જોડાવાની સંભાવના સુધારે છે, પાઇપનું કદ નહીં.
સાચું એગ્રિગેશન બીજું મશીન છે. એક પ્રવાહને અનેક માર્ગો પર વિભાજિત કરવા બંને છેડે સોફ્ટવેર જોઈએ, જે ટ્રાફિકને વહેંચીને ક્રમમાં ફરી જોડે.
વધુ સર્વરોથી ઝડપી ટનલનું વચન આપતો વિક્રેતા તે જ બીજું મોડેલ વેચે છે, લાંબી યાદી નહીં. જો ક્લાયન્ટ ફક્ત વારાફરતી endpoint અજમાવે, તો પાંચ એન્ટ્રીઓ તમારી સંભાવના બદલે છે અને બીજું કંઈ નહીં. વિક્ષેપ જુઓ: સેશન પડે છે અને બીજે ક્યાંક પાછું આવે છે, જે લોગ નવા endpoint તરીકે દર્શાવે છે, ક્યારેય પહોળા પાઇપ તરીકે નહીં.
એક endpoint સાથે સેટિંગ્સ રાખતા બ્લોક
સામાન્ય remote લીટી સરનામું લઈ જાય છે, અને ક્યારેક પોર્ટ તથા પ્રોટોકોલ પણ. જ્યારે endpoint ને પ્રોક્સી જોઈએ, અથવા એવું ટ્રાન્સપોર્ટ જે બાકીની ફાઇલ વાપરતી નથી, ત્યારે તે સેટિંગ્સને એક કનેક્શન બ્લોકમાં મૂકો જે તેમને તેની સાથે રાખે. ઇનલાઇન બ્લોક એક .ovpn ફાઇલમાં પણ કામ કરે છે, અને મોટાભાગના પ્રોફાઇલ આ રીતે આવે છે.
બ્લોકની બહારની દરેક વસ્તુ એ એન્ટ્રીઓ માટે ડિફોલ્ટ તરીકે વર્તે છે જે તેને ઓવરરાઇડ કરતી નથી. તેથી એક બનેલો બ્લોક અને ચાર સામાન્ય રિમોટ એ રીતે વર્તે છે જે સરનામાંની યાદી સમજાવી શકતી નથી.
તમે ઓળખતા ન હો તેવો બ્લોક ડિલીટ કરવું સૌંદર્યલક્ષી નથી. જે endpoint નો તે હતો તે ફાઇલના ડિફોલ્ટ પર પાછો જાય છે, જે તે સાંભળે છે તે ટ્રાન્સપોર્ટ કરતાં અલગ હોઈ શકે. ખોટું આવરણ કાઢો તો એક એન્ટ્રી નિષ્ફળ જાય છે જ્યારે બાકીની કામ કરે છે, તેથી તે તૂટેલા પ્રોફાઇલ કરતાં ખરાબ સર્વર જેવું લાગે છે. એડિટ કરતા પહેલા દરેક રિમોટ તેના ટ્રાન્સપોર્ટ, પોર્ટ અને પ્રોક્સી સાથે વાંચો.
ફરી પ્રયાસનો ક્રમ અને remote-random ની કિંમત
ક્રમ મહત્વનો છે કારણ કે દરેક મૃત એન્ટ્રી આગલા પ્રયાસ પહેલાં સમય લે છે. તમને જોઈતું endpoint પહેલું રાખો અને બાકીનાને ક્રમબદ્ધ વિકલ્પો ગણો.
remote-random શરૂઆતનો ક્રમ શફલ કરે છે, જે સમાન સર્વરો પર લોડ વહેંચે છે અને જ્યારે એક endpoint સ્પષ્ટપણે પ્રાથમિક હોય ત્યારે ઊંધું પડે છે. જેમ પણ હોય, ક્લાયન્ટે પસંદ કરેલું endpoint લોગ કરો; કનેક્શન ધીમું લાગે ત્યારે પ્રોફાઇલનું નામ કંઈ કહેતું નથી. વિગતવાર લોગમાંથી લિંક લીટી grep કરવાથી ખબર પડે કે સેશન ક્યાં ઉતર્યું.
ઓપરેટરો મિશ્ર કરવાથી વિશ્વાસનું નિવેદન તૂટે છે
પ્રોફાઇલ ઓળખ વિશેનું નિવેદન પણ છે: આ સરનામાં એ જ સેવા છે જ્યાં તમે પહોંચવા માંગતા હતા, અને પિન કરેલું પ્રમાણપત્ર તેનું જ છે. તે ફાઇલમાં મફત જાહેર સર્વરો નાખવાથી નિવેદન તૂટે છે: તેમના પ્રમાણપત્રો અને તમારું અલગ સેવાઓ વર્ણવે છે. સામાન્ય પરિણામ ઓળખ નિષ્ફળતા છે, અથવા તમારા પ્રદાતાના નેટવર્કની બહારના હોસ્ટને આપવામાં આવેલા ઓળખપત્રો. વિકલ્પોને તમારા ઓપરેટર વહેંચતા સમૂહની અંદર રાખો, મેળ ખાતા ઓળખપત્રો અને વિશ્વાસ સામગ્રી સાથે.
જો તમારે બે પ્રદાતાઓના endpoint જોઈએ, તો તે રૂટિંગ છે, પ્રોફાઇલ એડિટ નહીં. ટનલની ઉપર તેનો જવાબ આપો, જ્યાં તમે કહી શકો કે કયો ટ્રાફિક કયો માર્ગ લે છે.
ધારવાને બદલે દરેક એન્ટ્રીની કસોટી કરો
મંજૂર પ્રોફાઇલ અપડેટ પછી, દરેક જરૂરી endpoint સાથે જાણી જોઈને જોડાઓ અને ખાતરી કરો કે કયું ટ્રાન્સપોર્ટ ઉપર આવ્યું. વિગતવાર રન તેને દૃશ્યમાન કરે છે. openvpn --config office.ovpn --verb 4 શરૂ કરો અને જે સરનામાની અપેક્ષા હતી તે માટે લિંક લીટી વાંચો. પછી ટનલ પાછળના સંસાધનો તપાસો; એક એન્ટ્રી હેન્ડશેક પૂરો કરી શકે છે અને તો પણ તમને ક્યાંય રૂટ કરતી નથી.
ફેલઓવરને આશાને બદલે પોતાની કસોટી જોઈએ. પ્રયોગશાળામાં પહેલું endpoint અવરોધો, ક્લાયન્ટ શરૂ કરો અને આગળ વધવામાં કેટલો સમય લાગે તે માપો. ધીમી પહેલી એન્ટ્રી પાછળની લાંબી યાદી સારી રીતે શરૂ થતી ટૂંકી યાદી કરતાં ખરાબ છે.
ઓપરેટર યાદી બદલે ત્યારે તેને ફરી તપાસો. આયાત કરેલો સમૂહ ત્યારે જ ઉપયોગી છે જ્યારે તેની એન્ટ્રીઓ અસ્તિત્વમાં હોય અને તમારા બ્લોક જે ટ્રાન્સપોર્ટ વર્ણવે છે તે બોલે. OpenVPN 2.6 માર્ગદર્શિકા અહીં remote, connection અને random-order નિર્દેશો આવરી લે છે, અને સિન્ટેક્સ શંકાસ્પદ હોય ત્યારે તે ચકાસવાની આવૃત્તિ છે.