એક Linux હોસ્ટ પર બે OpenVPN ક્લાયન્ટ: રૂટ કોનો છે?

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

બીજી ટનલ શેના માટે છે તે પૂછીને શરૂ કરો

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

કોઈપણ રૂપરેખાંકન ફાઇલ ખોલતા પહેલાં કેસ લખી લો, કારણ કે તે જવાબ પછીનું બધું નક્કી કરે છે.

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

રૂટ પહેલાં પૂલ જુઓ

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

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

બે સરનામા કુટુંબ એટલે આ તપાસના બે રાઉન્ડ. IPv6 પૂલ IPv4 જેટલા જ શાંતિથી અથડાય છે.

દરેક પ્રોફાઇલને માલિક આપો

દરેક પ્રોફાઇલ માટે એક ઇન્સ્ટન્સ, દરેક ઇન્સ્ટન્સ માટે એક રૂપરેખાંકન ફાઇલ અને જોડીને ઓળખતું એક નામ. Debian શૈલીના પેકેજિંગમાં @ ચિહ્ન પછીનું નામ ફાઇલ પસંદ કરે છે, તેથી એક જ ઇન્સ્ટન્સ નામ શેર કરતી બે પ્રોફાઇલ કદી બંને કામ કરી શકતી નથી. મેપિંગ સ્થાપિત યુનિટમાંથી ખાતરી કરો, ટ્યુટોરિયલમાંથી નહીં.

systemctl cat [email protected]
ip -4 addr show

પછી નક્કી કરો કે રૂટ કોણ સ્થાપિત કરે છે, જે નીતિનો પ્રશ્ન છે, વાક્યરચનાનો નહીં.

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

દરેક ટનલ પ્રમાણે ચકાસો, પછી એક બંધ કરો

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

ip rule show
ip route get 203.0.113.9

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

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