સેશનની વચ્ચે પીઅરનું સરનામું બદલાયું: OpenVPN માં float શું કરે છે

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

float શું ઢીલું કરે છે, અને શું ક્યારેય ઢીલું કરતું નથી

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

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

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

સેશન ખસેડતું પેકેટ પ્રમાણિત થવું જોઈએ

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

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

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

શોધ એ સંપૂર્ણપણે અલગ કાર્યવિધિ છે

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

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

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

જ્યારે NetworkManager પ્રોફાઇલનો માલિક હોય

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

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

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

ધારવાને બદલે સંક્રમણ સાબિત કરો

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

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

છેલ્લે, ફક્ત એ જ કિસ્સાનું વર્ણન કરો જે તમે કર્યો છે. સેશન દરમિયાન સફળ સરનામા ફેરફાર એ પુરાવો નથી કે DNS સ્થળાંતર, બીજું ક્લાયન્ટ અમલીકરણ અથવા ફરી બનાવેલ પ્રોફાઇલ એ જ રીતે વર્તશે. link-options દસ્તાવેજીકરણ વિકલ્પનો વ્યાપ ચોક્કસપણે જણાવે છે; તમારા પરીક્ષણ લોગે જણાવવું જોઈએ કે તમે તે વ્યાપનો કયો ભાગ ખરેખર આવરી લીધો.