OpenVPN: સ્થાનિક સરનામું અને ટનલનું સરનામું — બે જુદા સોકેટ

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

બાઈન્ડ ભૂલ સ્થાનિક સરનામાનું નામ આપે છે

જ્યારે OpenVPN જણાવે છે કે તે સ્થાનિક સરનામું બાઈન્ડ કરી શકતું નથી, ત્યારે તે ટ્રાન્સપોર્ટ સોકેટની વાત કરે છે: UDP અથવા TCP અંતિમ બિંદુ, જે એન્ક્રિપ્ટેડ કનેક્શનને પીઅર સુધી પહોંચાડે છે.

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

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

local અને remote ખરેખર શું પસંદ કરે છે

remote સંપર્ક કરવાના પીઅરનું નામ આપે છે. local એ જ સોકેટના નજીકના છેડાને બાઈન્ડ કરે છે. nobind ઓપરેટિંગ સિસ્ટમને સ્થાનિક સરનામું અને પોર્ટ બંને પસંદ કરવા દે છે, અને તેથી ઘરના રાઉટર પાછળના ક્લાયન્ટ સામાન્ય રીતે બંનેમાંથી કોઈ સૂચના વિના કામ કરે છે.

બંનેમાંથી કોઈ સૂચનાનો ટનલની અંદરના સરનામા સાથે કોઈ સંબંધ નથી.

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

ip -brief address show
ip route get 203.0.113.10

અંદરનું સરનામું સર્વર તરફથી આવે છે

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

અંદરના સરનામા સાથે local લખવાથી સર્વરને તે સરનામું ફાળવવા માટે કહેવાતું નથી. સારામાં સારા કિસ્સામાં બાઈન્ડ નિષ્ફળ જાય છે; ખરાબમાં ખરાબ કિસ્સામાં ક્લાયન્ટ સમાન મૂલ્યનું અસંબંધિત હોસ્ટ સરનામું શોધી કાઢે છે અને ટ્રાન્સપોર્ટ માટે તેનો ઉપયોગ શરૂ કરે છે.

વાંચવાના ઇન્ટરફેસ પણ જુદા છે. ifconfig પરિમાણો અને પૂલ રૂપરેખાંકન અંદરની બાજુ વર્ણવે છે, જ્યારે remote, local, proto અને nobind બહારની બાજુ વર્ણવે છે. બે યાદીઓ અલગ રાખવાથી ફોરમ પર મળતું લગભગ દરેક ભ્રામક ઉદાહરણ સમજાય છે. OpenVPN 2.6 માર્ગદર્શિકા એ જ કારણસર તેમને અલગ વિભાગોમાં દસ્તાવેજ કરે છે.

જાળ: પોતાનું જ ટ્રાન્સપોર્ટ પકડી લેતી પૂર્ણ ટનલ

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

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

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

ગૂંચવણ અટકાવતી એક ટેવ

પ્રોફાઇલનું દરેક સરનામું વાંચો અને સંપાદિત કરતા પહેલાં નક્કી કરો કે તે કયા સ્તરનું છે.

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

બે યાદીઓ પ્રોફાઇલની બાજુમાંની ડિપ્લોયમેન્ટ નોંધોમાં લખો. પછીનું ટ્રબલશૂટિંગ સત્ર અનુમાનને બદલે સ્તરથી શરૂ થશે.