IPsec સુરક્ષા નીતિ કેમ રૂટ ટેબલની એન્ટ્રી નથી

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

ટેબલથી નહીં, લુકઅપથી શરૂ કરો

કર્નલને પૂછો કે તે ખરેખર શું કરશે: ip route get 10.20.0.5 પસંદ કરેલ રૂટ, આઉટગોઇંગ ઇન્ટરફેસ અને તે જે સ્રોત સરનામું વાપરશે તે છાપે છે. પ્રીફિક્સ, નીતિ નિયમ, માર્ક અથવા પસંદગીનો સ્રોત એ જવાબ બદલી શકે છે, તેથી જીવંત લુકઅપ આંખે ટેબલ વાંચવા કરતાં ચડિયાતું છે.

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

બંને બાજુએ સિલેક્ટર મેળવો

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

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

નીતિનું મેળ ખાવું એ સ્થાપિત સ્થિતિ નથી

મેળ ખાતી નીતિ ફક્ત કહે છે કે પેકેટ સુરક્ષિત થવું જોઈએ; સુરક્ષા કરવા કર્નલને હજી પણ સુરક્ષા એસોસિએશનની જરૂર છે. તેમને ip xfrm state થી સૂચિબદ્ધ કરો, અથવા જ્યારે strongSwan વાટાઘાટ કરે ત્યારે swanctl --list-sas થી, અને દરેક એન્ટ્રીના સિલેક્ટર અને કાઉન્ટર વાંચો.

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

રૂટ-આધારિત ટનલને હજી શું જોઈએ

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

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

કંઈપણ સંપાદિત કરતાં પહેલાં માલિકી નક્કી કરો

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

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