OpenVPN નો UDP જવાબ ખોટા સરનામેથી કેમ નીકળે છે

OpenVPN ક્લાયન્ટ એક સરનામું ડાયલ કરે છે, સર્વર બીજા સરનામેથી જવાબ આપે છે, અને ટનલ ક્યારેય ઉપર આવતી નથી. સર્વરનો લોગ પેકેટ આવતું દર્શાવે છે અને કેપ્ચર જવાબ જતો દર્શાવે છે, તેથી ભૂલ ક્લાયન્ટ પર નાખવામાં આવે છે. ઘણા ઇન્ટરફેસ ધરાવતા હોસ્ટ પર, અથવા એક જ ઇન્ટરફેસ પર ઘણા સરનામાં હોય ત્યારે, બંને બાજુઓ કયું સરનામું વપરાય છે તે અંગે સહેમત થતી નથી. જવાબ IP સ્તરે માન્ય છે, તેમ છતાં ઘણા ક્લાયન્ટ એવા ડેટાગ્રામને ફગાવી દે છે જેનું સ્રોત તેમણે સંપર્ક કરેલું સરનામું નથી.

સ્રોત બદલાય ત્યારે ક્લાયન્ટ શું જુએ છે

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

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

multihome વિકલ્પ ખરેખર શું કરે છે

આ નિર્દેશ કન્ફિગરેશન ફાઇલમાં multihome તરીકે અને કમાન્ડ લાઇન પર --multihome તરીકે લખાય છે, અને તે UDP સર્વરને ક્લાયન્ટનું પેકેટ જે સરનામા પર પહોંચ્યું તેમાંથી જવાબ આપવા મજબૂર કરે છે. કર્નલ સ્વીકારતી વખતે મૂળ ગંતવ્ય સરનામું વધારાના ડેટા તરીકે આપે છે, અને OpenVPN એ મૂલ્યને જવાબના સ્રોત તરીકે વાપરે છે. આમ વાઇલ્ડકાર્ડ સરનામા પર સાંભળતું સર્વર, IPv4 માટે local 0.0.0.0 અથવા તેના IPv6 સમકક્ષ, એવી રીતે વર્તે છે જાણે દરેક ક્લાયન્ટ સમર્પિત શ્રોતા સુધી પહોંચ્યો હોય. જાહેર સરનામા દ્વારા આવેલા ક્લાયન્ટને જાહેર સરનામેથી જવાબ મળે છે, અને આંતરિક સરનામા પરના ક્લાયન્ટને તે સરનામેથી મળે છે. પેકેટના માર્ગમાં બીજું કંઈ ખસતું નથી: રૂટ, ફિલ્ટર નિયમો અને ટનલ કન્ફિગરેશન જેવા હતા તેવા જ રહે છે.

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

ક્યારે નિશ્ચિત સ્થાનિક સરનામું ખોટું ડિફોલ્ટ છે

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

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

બહારથી જવાબનો સ્રોત સાબિત કરો

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

tcpdump -ni any udp port 1194
ss -lunp 'sport = :1194'
ip route get 203.0.113.10 from 198.51.100.20

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

રૂટિંગ, શોધ અને ફિલ્ટરિંગ અલગ રહે છે

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

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