એક Pi પર બે VPN હોપ: કયો રૂટ કયા પીઅરને વહન કરે છે

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

અલગ વાહક જોઈતા ત્રણ ગંતવ્યો

બે-હોપની સાંકળ એ ત્રણ ગંતવ્ય વર્ગોનું થર છે, અને દરેકને અલગ જોડાણ વહન કરે છે. બહારના પીઅર સુધી ભૌતિક લિંક પરથી પહોંચવું પડે. અંદરના પીઅર સુધી બહારની ટનલ દ્વારા પહોંચવું પડે. આવરી લીધેલ એપ્લિકેશનના ગંતવ્ય સુધી અંદરની ટનલ દ્વારા પહોંચવું પડે, જેનું પોતાનું પરિવહન બહારની ટનલ વહન કરે છે.

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

સરનામાંમાં ભૂમિકા હોય છે, ગણતરી નહીં

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

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

ip -4 addr show
ip -4 route show table all
ip rule show

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

સક્રિયકરણનો ક્રમ નિશ્ચિત ઊંઘને હરાવે છે

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

કર્નલ tun0 અને tun1 જેવા નામ બનાવટી ક્રમમાં આપે છે, અને તે ક્રમ રીબૂટ કે ફરી જોડાણ વચ્ચે બદલાઈ શકે છે. રૂપરેખાંકનને સાધન પૂરી પાડતી ઓળખ સાથે, અથવા તમે જાણી જોઈને આપેલા નામ સાથે બાંધો. તમે પસંદ કરેલું નામ કરાર છે; કર્નલ પસંદ કરેલું નામ અકસ્માત છે.

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

બહારનો હોપ મરે ત્યારે શું થાય છે

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

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

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

દરેક સ્તરને તમે બનાવ્યું તે ક્રમમાં સ્વીકારો

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

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