અનેક સબનેટવાળું IPsec પરત ટ્રાફિક ગુમાવે છે? reqid ગણો

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

કંઈપણ બદલતા પહેલાં લક્ષણને અલગ કરો

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

MTU થી શરૂ ન કરો. ખોટું MTU અટકી જવા અને ટુકડા થવાનાં લક્ષણો ઉત્પન્ન કરે છે, વધતા બહાર જતા કાઉન્ટર સાથે સ્વચ્છ દિશા વિભાજન નહીં.

નીતિ ડેટાબેઝ અને સ્થિતિ ડેટાબેઝ વાંચો

Linux માં એન્ક્રિપ્શન નક્કી કરે નીતિ એન્ટ્રીઓ, તેથી મળતી નીતિ, રૂટ નહીં, પેકેટને ટનલમાં મૂકે છે. ip xfrm policy ચલાવો જેથી દરેક એન્ટ્રીના પસંદગીકાર, દિશા, પ્રાથમિકતા અને ટેમ્પલેટ જોઈ શકો, અને ip xfrm state જેથી સ્થાપિત સંગઠનો તેમના reqid સાથે જોઈ શકો. નીતિ અને સંગઠન એ જ reqid દ્વારા જોડાય છે.

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

અભિજાત અસમાનતા: અનેક સબનેટ માટે એક reqid

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

સુધારો એ ગોઠવણીનો ફેરફાર છે, ફાયરવોલ નિયમ નહીં: generate_policy unique; દરેક નીતિને તેનું પોતાનું reqid આપે છે, જેથી સાથીના પ્રતિ-નીતિ સંગઠનોને મળતા સાથીઓ મળે. તેને લાગુ કરો, ફરી વાટાઘાટ કરો, અને સફળતા જાહેર કરતા પહેલાં અપેક્ષિત સબનેટ માટે અલગ reqid ગણો.

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

પસંદગીકાર વાટાઘાટમાંથી આવે છે, તમારી ગોઠવણીમાંથી નહીં

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

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

આ ક્રમમાં ચકાસો, અને જાણો કેવી રીતે પાછા હટવું

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

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