IPsec માં IPsec: બહારના ટનલે કયા સરનામાં વહન કરવા જોઈએ

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

ચાર-ગેટવે મોડેલ

બહારના ગેટવે A અને B બે સાઇટ વચ્ચે પ્રથમ ટનલ બનાવે છે. A પાછળ ટ્રાન્ઝિટ સરનામા 10.60.0.2 સાથે અંદરનું ગેટવે C છે; B પાછળ ટ્રાન્ઝિટ સરનામા 10.70.0.2 સાથે અંદરનું ગેટવે D છે. એપ્લિકેશન નેટવર્ક C અને D પાછળ રહે છે, અને ઉદાહરણનું દરેક સરનામું જાણી જોઈને અતિક્રમણ રહિત છે.

application net -> C -> A == outer IPsec == B -> D -> application net
                       \---------- inner IPsec ----------/

C transit: 10.60.0.2      D transit: 10.70.0.2
A and B:    underlay addresses only

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

દરેક સ્તર ફક્ત પોતાનું રક્ષણ દૂર કરે છે

C, D માટે એપ્લિકેશન પેકેટ એન્ક્રિપ્ટ કરે છે. પરિણામ C થી D સરનામું થાય છે, અને તે જ A સુધી પહોંચે છે. નીચેનું બધું તે ફરીથી લખાણ પર આધાર રાખે છે.

A તેને B માટે ફરી એન્ક્રિપ્ટ કરે છે. B બહારનું સ્તર ડિક્રિપ્ટ કરે છે, C થી D જતું પેકેટ જુએ છે અને તેને હજુ એન્ક્રિપ્ટેડ રહેતું ફોરવર્ડ કરે છે. D અંદરનું રક્ષણ દૂર કરે છે અને એપ્લિકેશન પેકેટ પહોંચાડે છે.

તેથી A અને B અંદરના અંત્યબિંદુઓ અને તેમનો મેટાડેટા જુએ છે, પણ એપ્લિકેશન પેલોડ ડિક્રિપ્ટ કરતા પક્ષો તેઓ નથી. તે ડિઝાઇનની વાસ્તવિક ગુણવત્તા છે, C, D કે એપ્લિકેશન હોસ્ટ વિશ્વસનીય છે એવો દાવો નહીં.

બહારના સિલેક્ટર અંદરના ગેટવેને નામ આપે છે

અહીં જ મોટાભાગના આવા બાંધકામો નિષ્ફળ જાય છે. નીતિ-આધારિત બહારના ટનલ માટે, તમે જે સિલેક્ટર પર વાટાઘાટ કરો છો તેમાં A અને B ખરેખર જે સરનામાં સંભાળે છે તે હોવા જોઈએ: 10.60.0.2/32 અને 10.70.0.2/32, યોગ્ય સ્થાનિક અને દૂરસ્થ ક્રમમાં.

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

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

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

ફોરવર્ડિંગ અને રિકર્ઝનની જાળ

સિલેક્ટર રૂટિંગનો વિકલ્પ નથી. A અને B એ C અને D વચ્ચે બંને દિશામાં ટ્રાફિક ફોરવર્ડ કરવો પડે, એટલે કે IP ફોરવર્ડિંગ સક્ષમ, ટનલ તરફ ઇશારો કરતા રૂટ અને બીજી બાજુ અસ્તિત્વમાં હોય તેવો પરત માર્ગ.

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

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

સ્તરો ઉમેરતા પહેલાં ટ્રાન્સલેશન તપાસો

બીજું કંઈ ટ્યુન કરતા પહેલાં A અને B પરનું કોઈપણ સોર્સ NAT જુઓ. IPsec નીતિ લાગુ થાય તે પહેલાં C નું સરનામું ફરીથી લખતો નિયમ સંમત સિલેક્ટર તોડી શકે છે, અને D બીજી બાજુ શું મેળવે છે તે પણ બદલી શકે છે.

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

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

fail-closed સાબિત કરો અને MTU ચકાસો

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

ત્રણ સ્થિતિ ચકાસો: બહારનું ટનલ નીચે, અંદરનું ટનલ નીચે, અને બંને પાછાં આવ્યા પછી પુનઃપ્રાપ્તિ. દરેક ગેટવે પર નીતિ કાઉન્ટર વાપરો, કારણ કે બે સ્થપાયેલ IKE સત્રો ફક્ત એ સાબિત કરે છે કે કંટ્રોલ પ્લેન વાટાઘાટ સફળ થઈ.

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