MULTI: ક્લાયન્ટ તરફથી ખોટું સ્રોત સરનામું: આ કોનું સરનામું હતું?
આંતરિક સ્રોત તેને પહોંચાડનાર ક્લાયન્ટ સાથે મેળ ખાતો નથી. તેને ટનલ ફાળવણી, ક્લાયન્ટ પાછળની LAN, અથવા નકલી ઓળખ સાથે મેળવો.
સર્વર લોગ MULTI: bad source address from client છાપે છે, પેકેટ કાઢી નાખે છે, અને સત્ર જોડાયેલું રહે છે. આ સંયોજન એવા લોકોને મૂંઝવે છે જે સંદેશને પ્રમાણીકરણની નિષ્ફળતા તરીકે વાંચે છે. એવું નથી: ક્લાયન્ટ પ્રમાણિત થયો છે, અને જે પેકેટ આવ્યું તે આંતરિક સ્રોત સરનામું ધરાવતું હતું જે સર્વર આ ક્લાયન્ટ ઇન્સ્ટન્સ સાથે જોડી શક્યું નહીં. તપાસ ડિલિવરી પહેલાં થાય છે, તેથી ટનલ સ્વસ્થ દેખાય છે જ્યારે તેમાંથી કંઈ ઉપયોગી પસાર થતું નથી.
ડિલિવરી પહેલાં સર્વર શું સરખાવે છે
ક્લાયન્ટથી આવતા દરેક પેકેટ માટે, યુઝર-સ્પેસ સર્વર ટનલની અંદરના સ્રોત સરનામા તરફ જુએ છે અને તેની આંતરિક રૂટિંગ સ્થિતિને પૂછે છે કે તે સરનામું કયા ક્લાયન્ટનું છે. જો માલિક બીજું ઇન્સ્ટન્સ હોય, અથવા કોઈ માલિક જ ન હોય, તો પેકેટ દૂર થાય છે અને ચેતવણી બહાર પડે છે.
ટનલ ઇન્ટરફેસ દ્વારા સામાન્ય ડિલિવરી ક્યારેય થતી નથી.
આ ક્રમ એવી વિગત સમજાવે છે જે લોકોને આશ્ચર્યમાં મૂકે છે: હોસ્ટ ફાયરવોલના કાઉન્ટર ખસતા નથી, કારણ કે પેકેટ ક્યારેય ફાયરવોલ સુધી પહોંચ્યું જ નહીં. હોસ્ટ પર રિવર્સ-પાથ ફિલ્ટરિંગ ગોઠવવાથી અહીં કંઈ બદલાતું નથી, કારણ કે અસ્વીકાર ડેમનની પોતાની સંકળામણ-તપાસમાં થયો હતો. સંદેશને માલિકી વિશેના નિવેદન તરીકે વાંચો, પછી શોધો કે ત્રણમાંથી કઈ સ્થિતિએ તેને ઉત્પન્ન કરી.
ન મળતા આંતરિક સરનામાના ત્રણ સ્રોત
ક્લાયન્ટ એવા સરનામેથી મોકલી રહ્યો હોઈ શકે જે તેને ફાળવવામાં આવ્યું નથી, એવા નેટવર્કથી જેને કોઈએ તેનું જાહેર કર્યું નથી, અથવા એવી ઓળખની નકલથી જેનો પહેલેથી માલિક છે. ત્રણેય એક જ લોગ લાઇન બનાવે છે. તેઓ એમાં અલગ પડે છે કે તમારે શું બદલવું છે. સરનામું અને વર્તમાન ફાળવણી યાદી સાથે શરૂ કરો, અને આ બે તથ્યોને કેસ પસંદ કરવા દો.
તેમને અલગ પાડવા બે તથ્યો જોઈએ: લોગમાં અસ્વીકૃત સરનામું, અને સર્વર જે ફાળવણીઓને વર્તમાન માને છે. બીજું ચાલુ ઇન્સ્ટન્સના સ્ટેટસ અથવા મેનેજમેન્ટ દૃશ્યમાંથી મળે છે, અને તે જ એકમાત્ર સત્તા છે જેની સલાહ લેવા યોગ્ય છે, કારણ કે કન્ફિગરેશન ફાઇલ ઇરાદા નોંધે છે, વર્તમાન સ્થિતિ નહીં.
કંઈપણ બદલતા પહેલાં બંને નોંધો, પછી વર્ગીકરણ કરો. પછી લીધેલો સ્ક્રીનશોટ એ સ્થિતિનો રેકોર્ડ નથી જેણે ચેતવણી ઉત્પન્ન કરી. ટાઇમસ્ટેમ્પ પણ રાખો, કારણ કે ફાળવણીઓ સત્રો વચ્ચે ખસે છે.
| Rejected source is | Likely cause |
|---|---|
| The client's own tunnel address | Static assignment conflict, wrong profile, or manual address change |
| A host behind that client | Missing internal ownership for that prefix |
| An address belonging to another session | Two devices sharing one identity or one static address |
ક્લાયન્ટ પાછળની LAN અને iroute
જ્યારે સાઇટ ક્લાયન્ટ પોતાનું ખાનગી નેટવર્ક રૂટ કરે છે, ત્યારે તે નેટવર્કને ક્લાયન્ટનું જાહેર કરવું પડે છે. iroute એન્ટ્રી સાથેની ક્લાયન્ટ-વિશિષ્ટ ફાઇલ તે કરે છે, અને એન્ટ્રી એ પ્રીફિક્સનું નામ આપે છે જે ક્લાયન્ટને વહન કરવાની પરવાનગી છે.
સમાન પ્રીફિક્સને ટનલ તરફ નિર્દેશ કરતો કર્નલ રૂટ અલગ આવશ્યકતા છે, અને તેને ઉમેરવાથી ડેમનની આંતરિક માલિકીમાં કંઈ બદલાતું નથી.
# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0ખાતરી કરો કે અસરકારક ઓળખ ફાઇલ નામ સાથે મેળ ખાય છે, કારણ કે ન મળવું એટલે ફાઇલ ક્યારેય લોડ થતી નથી અને લક્ષણ ગુમ થયેલી એન્ટ્રી જેવું જ છે. ચેતવણી શાંત કરવા માટે પહોળો iroute ઉમેરશો નહીં, કારણ કે તે અણધાર્યા સ્રોતને અધિકૃત બનાવે છે અને ક્લાયન્ટે તે કેમ મોકલ્યું તેનો જવાબ આપતું નથી. OpenVPN 2.6 માર્ગદર્શિકા iroute, duplicate-cn અને ઓળખ મેપિંગને અલગ નિયંત્રણો તરીકે દસ્તાવેજ કરે છે.
બે મશીનો પર એક જ ઓળખ
બીજા લેપટોપ પર નકલ કરેલી પ્રોફાઇલ એ જ પ્રમાણપત્ર અને એ જ સામાન્ય નામ ધરાવે છે. સર્વરની સેટિંગ્સ પર આધાર રાખીને, નવું જોડાણ જૂનાને બદલી શકે છે, અને જે ઇન્સ્ટન્સ માલિકી ધરાવે છે તે સંકળામણ-તપાસ જીતે છે.
આ ખામીને અનિયમિત દેખાડે છે અને ફક્ત ત્યારે જ દેખાય છે જ્યારે બંને ઉપકરણો જાગ્રત હોય.
નકલી સામાન્ય નામોની પરવાનગી બંનેને જોડાવા દે છે, પરંતુ તેમને સ્વતંત્ર સ્થિર સરનામાં કે સ્વતંત્ર માલિકી આપતી નથી. જો બે ઉપકરણો સાથે રહેવા જોઈએ, તો તેમને અલગથી નોંધણી કરો જેથી દરેકની પોતાની ઓળખ અને પોતાની ફાળવણી હોય. નકલ સેટિંગને આ ચેતવણીનો ઉપાય ગણવાથી રહસ્ય યથાવત્ રહે છે અને બીજું ઉમેરાય છે.
સાબિત કરો કે સંકળામણ બદલાઈ
કન્ફિગરેશન માલિક દ્વારા સુધારો લાગુ કરો, પછી નવી નીતિ લોડ થાય તે માટે અસરગ્રસ્ત ક્લાયન્ટને ફરી જોડો.
એ જ પ્રવાહનું પુનરાવર્તન કરો અને ત્રણ વસ્તુઓની ખાતરી કરો: પેકેટનો આંતરિક સ્રોત, સર્વર જે ક્લાયન્ટ ઇન્સ્ટન્સ સાથે તેને જોડે છે, અને પછી ગંતવ્યનું વર્તન.
જો ચેતવણી અટકે પણ એપ્લિકેશન હજી નિષ્ફળ જાય, તો સમસ્યા ગાયબ થવાને બદલે ખસી ગઈ છે. ફોરવર્ડિંગ, ફાયરવોલ નિયમો અને પરત માર્ગ અલગ તબક્કા છે, અને સંકળામણ-તપાસ પસાર કરવાનો અર્થ ફક્ત એટલો જ છે કે પેકેટને ટનલ છોડવાની પરવાનગી મળી.